linux-ext4 - Re: [PATCH 3/4] e2scrub: create a script to scrub all ext* filesystems

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 13 Mar 2018 11:16:20 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Reindl Harald <h.reindl@...lounge.net>
Cc:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        Lukas Czerner <lczerner@...hat.com>, tytso@....edu,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH 3/4] e2scrub: create a script to scrub all ext*
 filesystems

On Mar 13, 2018, at 11:11 AM, Reindl Harald <h.reindl@...lounge.net> wrote:
> 
> 
> Am 13.03.2018 um 18:08 schrieb Andreas Dilger:
>> On Mar 13, 2018, at 10:36 AM, Darrick J. Wong <darrick.wong@...cle.com> wrote:
>>> 
>>> I'd rather have two simple tools that each do one thing ("scrub this
>>> ext4 lvm volume") ("find all ext4 lvm volumes and run scrub") than
>>> combine them into one less cohesive tool.  There's precedence here with
>>> fsck.$fstype and fsck, where the first one performs an offline check of a
>>> single filesystem and the second one (if you fsck -A) finds all the
>>> individual filesystems and feeds them through fsck.$fstype.  In the
>>> longer term it probably makes sense to set up a fsscrub wrapper to
>>> invoke the fs-specific scrub tools.
>>> 
>>> Though now that I think about that, e2scrub probably ought to take a
>>> mount point and translate that into a lvm volume, which makes
>>> e2scrub_all mostly a dumb iterator of /proc/mounts.
>> Except that won't scrub offline volumes, nor will all mounted ext4
>> filesystems be LVs that can be scrubbed, so I don't think that is
>> an improvement
> 
> why is that at all limited to ext4 on top of LVM?
> 
> both layers should not need to know from each other - feels not that good for the long term having different paths of code depending on the underlying block layer (raw-disk, mdraid, lvm, lvm-on-mdraid...)

Because LVM can create snapshots of the block device, which is required for
running e2fsck while the filesystem is "mounted" (though the check is done
on the unmounted snapshot device and not the actual in-use block device).

Cheers, Andreas






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