linux-ext4 - Re: [PATCH] tune2fs: remove dire warning about check intervals

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Jul 2017 16:28:16 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Eric Sandeen <sandeen@...hat.com>
Cc:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        Lukáš Czerner <lczerner@...hat.com>
Subject: Re: [PATCH] tune2fs: remove dire warning about check intervals

On Jul 18, 2017, at 3:10 PM, Eric Sandeen <sandeen@...hat.com> 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@...hat.com>
> ---
> 
> 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

Download attachment "lvcheck" of type "application/octet-stream" (13644 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)