On Mar 13, 2018, at 11:11 AM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
>
>
> Am 13.03.2018 um 18:08 schrieb Andreas Dilger:
>> On Mar 13, 2018, at 10:36 AM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP
