Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp9621255ybl; Thu, 26 Dec 2019 02:25:36 -0800 (PST) X-Google-Smtp-Source: APXvYqyPQR0MRCV/uaZsiGrkuwcT1HJ5mdbFxE/SG2o2S3Nof1FFkOFcOczRaDBQOdBIUbvt9Emr X-Received: by 2002:a9d:664a:: with SMTP id q10mr39699134otm.99.1577355934594; Thu, 26 Dec 2019 02:25:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577355934; cv=none; d=google.com; s=arc-20160816; b=isTTO9PXzSFZtzWlIlo/i8bC8G0ZMCjH7hlTJbAoBJARB9Bha3gBiFYNOEBgCQwRat cLoXioA/jKu68VLqghlngLYMrAFVf0D4NcTnb8m1edqqT6ABQrP+4m4h0XH6485fk2XK offJm4MhQmPq8x++Pz/+1ImczmEQuvGa0S/bwtfoa9w2+1MTw7ylEXlU9xYnUQP9H3Kx san8fsrs8/jYCKGKPdciiRjuv/lI0ZX8jn8gbgwKOTzGAasuvw8MRLkGEcC19KGFtQWv ZG09U71bDEL4oQQGKrQyfykTAo57gnhqEeDDQXcW4SNTtnsFXRkBnURzEm4p8V55ULW4 +LtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:mime-version:dkim-signature; bh=xORsCmYUimkT0HwPyrDa3btDVAA2C/Dc6leiyByEhfA=; b=m3YElOowI6LIb5sc9ikXviuEbAjGYCIIO0+TthL9U5rKycotycPtVyTpzfZVJYCDjB xyvz9wBC2EDDYvZwIpBIqc6Fqm4Hwz3vvWkU6qPNHIVwuMBmjvdyHjEuxlDlEnmv4Tce uYlNH1hHwsSTQHQNpqTkmKO44zS6Td/V0jtToUSIXNazvBwvO5xs7UbnGZ1XX+qEn7XE wlz0fHtZHmF2zmGAh3zo6TQaMPE52aN8xbWZT+/MeEZX6CsZi7jlf6ourzTSd+NoARnz 6mVwt6PMdDTO1hteiH1h7AEeq8buLNvA10GNNPyr9uAslLzQtSS7TEeP/LRP2Zuqr952 VH0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=wOUF4n5g; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m20si15108036otq.35.2019.12.26.02.25.24; Thu, 26 Dec 2019 02:25:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=wOUF4n5g; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726074AbfLZKZY (ORCPT + 99 others); Thu, 26 Dec 2019 05:25:24 -0500 Received: from mail-wm1-f49.google.com ([209.85.128.49]:36855 "EHLO mail-wm1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726055AbfLZKZY (ORCPT ); Thu, 26 Dec 2019 05:25:24 -0500 Received: by mail-wm1-f49.google.com with SMTP id p17so5780400wma.1 for ; Thu, 26 Dec 2019 02:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=xORsCmYUimkT0HwPyrDa3btDVAA2C/Dc6leiyByEhfA=; b=wOUF4n5gCJhSe55G0X5NsdV/q/pE0tgq0VIECDjT9PHTPmRxtjwDCtcPwrVv3X3CEE mDi06AxB/5PcQtcfosPQrXV3qi26jJirXNQtI33VpC1PVFzUmsxjs325+40FDV1CAaOx 1yMzlxxodmrU905clJ0komQELAaaVhpLvAIi9BEq22ekaxho6PtYoyHCOj0S7osTT9e1 Ml/9PN4jC/dVvWMXZhAlS0exIcH5pqgsblk7MkQL+r796kv6fVpC9XJxo1dMg6sWwFV9 c5Irr7L5lPl47KmC9ahfYIuGALV/n/SceoeU5aZ2IwF986Hn9mT4jxkzWeLyfVM22+xv o5Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=xORsCmYUimkT0HwPyrDa3btDVAA2C/Dc6leiyByEhfA=; b=iBT2ds3jyXqXhVPVRSxhw6D9YgG7ipqJzRI8vLNpmou+9gEydtmYo75kyVZXPJPPRU i6PGIq8dIVZ8ugxFBw1CJdk7wBIRvoootT5W9kqwGRxryey67qFKws6rXIyD+PJYqd0y Q0UjT82Z2W9dBzXmDRDUC5tU/FAws0D9NWkYkg2RPYQjVOr7mHR07VZwkkLGXZwp3yjn HrvPrirryFHwEPwgtO6lcvZg+o5Efy+E+1EN4sZzAZhP20mD70WRnGn5H2DKjjjjgHRb Kp2NZQCKuM2UiJMYpWooBW/UBMj/bMgVAbJRS8JNFT32OJHxpNZB5rAIF2WTYO2QgY17 a0+g== X-Gm-Message-State: APjAAAUIFo2CcHQI00Se+vSTqFc7v4b2huvei8Z+0qVjVUj49Kb0t+Kg 5ONQMtvlIfYzethz8VlW3cAnErjokhJnpVnEOBjrZQhELv0BPw== X-Received: by 2002:a1c:f008:: with SMTP id a8mr13109401wmb.81.1577355921837; Thu, 26 Dec 2019 02:25:21 -0800 (PST) MIME-Version: 1.0 From: xiaohui li Date: Thu, 26 Dec 2019 18:25:01 +0800 Message-ID: Subject: the side effect of enlarger max mount count in ext4 superblock To: "Theodore Y. Ts'o" Cc: Ext4 Developers List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org hi ted: we have found the e2fsck full check cost-so-much-time problem in android booting phase, especially it will spend 120 seconds on doing this e2fsck full check in ext4 rw partition which has large storage capacity and serious fragmentation related with used extents. so we want to reduce the numbers of the called work of e2fsck full check. condition 1: and then we have find when encountering the metadata error or inconsistent problems, ext4 will has put an error flag in its superblock. when the next e2fsck data check begin, it will check if there is an error flag in partition superblock, and will do the full check work automatically if has this error flag. condition 2: meanwhile, in android code, when ext4 partition has been mounted unsuccessfully, it will also do e2fsck full check subsequently. according to above two showed conditions on which e2fsck full check can be called automatically, the e2fsck full check has not to be called periodically when the ext4 partition mount times is above max mount times we set in ext4 super block. when ext4 data or medata error has happened, e2fsck full check will be called automatically during next e2fsck data checking. so i wonder the reason why set EXT4_DFL_MAX_MNT_COUNT value to 20 in fs/ext4/ext4.h and not set a large value to it ? is there any reason or any condition when file system data error or stability problems happens and ext4 can't get this information, can't set the error flag in superblock, and so will not call the e2fsck full check during next e2fsck check=EF=BC=9F and because of this reason or condition, it will have to do periodic e2fsck full check. many thanks if you and any other people can give me advise on the above question.