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  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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ