On Jul 18, 2017, at 3:10 PM, Eric Sandeen <sandeen@xxxxxxxxxx> wrote: > > Time & mount-count based checks have been off by default for quite some > time now, but the dire warning about disabling them remains in the > tune2fs manpage, which is confusing. We did "strongly consider > the consequences" and disabled it by default, no need to scare the > user about it now. Sigh, I still think this is going in the wrong direction. I'm happily running a weekly e2fsck on a snapshot of the filesystem, and then reset the time and mount-count fields in the superblock with tune2fs. That way I never see any warnings, or have slow boots because of a scan, but I'm also notified if there are ever problems on the filesystem (which happens occasionally, since I'm sometimes running experimental code). Since virtually everyone is using MD/LVM devices these days, I don't think that is hard to do. I offered up my "lvcheck" script a few times, but nobody at RH or on the DM team seemed interested at the time... I'd also be happy if there was some other similar mechanism included with the distro to do periodic background checks of the filesystem, rather than letting them find any problem at some random time. This is pretty standard for RAID systems, I think it makes sense for the filesystem too. Cheers, Andreas > Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> > --- > > diff --git a/misc/tune2fs.8.in b/misc/tune2fs.8.in > index 5c885f9..a8cacc7 100644 > --- a/misc/tune2fs.8.in > +++ b/misc/tune2fs.8.in > @@ -134,17 +134,6 @@ Staggering the mount-counts at which filesystems are forcibly > checked will avoid all filesystems being checked at one time > when using journaled filesystems. > .sp > -You should strongly consider the consequences of disabling > -mount-count-dependent checking entirely. Bad disk drives, cables, > -memory, and kernel bugs could all corrupt a filesystem without > -marking the filesystem dirty or in error. If you are using > -journaling on your filesystem, your filesystem will > -.B never > -be marked dirty, so it will not normally be checked. A > -filesystem error detected by the kernel will still force > -an fsck on the next reboot, but it may already be too late > -to prevent data loss at that point. > -.sp > See also the > .B \-i > option for time-dependent checking. > Cheers, Andreas
Attachment:
lvcheck
Description: Binary data
Attachment:
signature.asc
Description: Message signed with OpenPGP
