From: Zdenek Kabelac <zkabelac@redhat.com>
To: dm-devel@redhat.com
Subject: Re: generic wrappers for multi-device FS operations
Date: Tue, 08 Mar 2011 23:23:00 +0100 [thread overview]
Message-ID: <4D76AC44.9090206@redhat.com> (raw)
In-Reply-To: <4D76988E.7010400@gmail.com>
Dne 8.3.2011 21:58, Ric Wheeler napsal(a):
> On 03/08/2011 03:54 PM, Andreas Dilger wrote:
>> On 2011-03-08, at 10:04 AM, Ric Wheeler wrote:
>>> After seeing some of the feedback and confusion that happened in the fedora
>>> community after Josef suggestion that we default to btrfs in an upcoming
>>> Fedora release, it became clear to me that many users are incredibly
>>> unaware of the common features that we have across file systems today given
>>> LVM/device mapper support.
>>>
>>> btrfs will make multi-volume/multi-disk operations common place and easy to
>>> do, but there is no reason not to do most/all of this today with ext4, xfs,
>>> etc on top of lvm.
>>>
>>> To make this trivial to do for users, I think that it would be really nice
>>> to have a two-level wrappers for things like resize, add a volume, shrink,
>>> etc. Similar to the way we have mount or fsck invoke file system specific
>>> bits.
>> I definitely think this makes sense. However, taking a quick look at fsadm,
>> I don't think it is the right starting point for this work. It is essentially
>> a single script that is special-casing each filesystem it is touching, which
>> makes it a maintenance nightmare to add in support for different filesystems.
>>
>> A better structure is the mkfs.* and fsck.* tools that extend the basic
>> mkfs/fsck functionality for each new filesystem. That allows new filesystems
>> to be added without the requirement to modify the upstream fsadm script.
>
> I do like the two level scheme that mkfs.* and fsck.* use - same interface
> largely regardless of the file system and the ability to customize the fs
> specific command as needed.
>
>>
>> Another tool similar to this that I've been trying to push upstream for some
>> time is the "lvcheck" script, which is essentially a wrapper for online
>> filesystem checking. It is currently structured as an extension to the LVM
>> tools, since it depends on creating a snapshot of an LV and does a check on
>> the snapshot. If the snapshot is clean the original filesystem is marked
>> checked as well, which avoids the "slow ext* check on boot" problem, while
>> still ensuring that periodic filesystem checks will catch latent errors.
>>
>> It wouldn't be unreasonable to have a new wrapper for online filesystem
>> checking (e.g. ofsck) or just an extension to fsck that does this in a more
>> "plug-in" manner like fsck.* does today. It would naturally progress into
>> real online checking for filesystems that support this (e.g. btrfs, and I
>> think XFS is going in this direction as well).
>>
>> Cheers, Andreas
>
> Online fsck would certainly be a win & would make a lot of users happy,
>
Can I ask for creating RH bugzillas for missing fsadm functionality.
(Support for btrfs (Bug 643907) is already there thought other more prio task
are currently resolved).
Zdenek
next prev parent reply other threads:[~2011-03-08 22:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-08 17:04 generic wrappers for multi-device FS operations Ric Wheeler
2011-03-08 17:43 ` [dm-devel] " Alasdair G Kergon
2011-03-08 18:05 ` Wendy Cheng
2011-03-08 18:13 ` Ric Wheeler
2011-03-08 18:34 ` James Bottomley
2011-03-08 18:51 ` Ric Wheeler
2011-03-08 20:16 ` Lars Marowsky-Bree
2011-03-08 18:37 ` Josef Bacik
2011-03-08 18:51 ` Ric Wheeler
2011-03-09 14:23 ` Alasdair G Kergon
2011-03-09 15:13 ` Ric Wheeler
2011-03-10 15:28 ` Hannes Reinecke
2011-03-10 15:30 ` Ric Wheeler
2011-03-09 21:36 ` Dave Chinner
2011-03-09 21:49 ` Alasdair G Kergon
2011-03-10 5:04 ` Dave Chinner
2011-03-08 20:54 ` Andreas Dilger
2011-03-08 20:58 ` Ric Wheeler
2011-03-08 22:23 ` Zdenek Kabelac [this message]
2011-03-09 2:11 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D76AC44.9090206@redhat.com \
--to=zkabelac@redhat.com \
--cc=dm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox