FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 03-08-2011, 04:04 PM
Ric Wheeler
 
Default generic wrappers for multi-device FS operations

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.


Good idea? Bad idea?

Thanks!

Ric

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-08-2011, 04:43 PM
Alasdair G Kergon
 
Default generic wrappers for multi-device FS operations

On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:
> 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.
> Good idea? Bad idea?

We began this within LVM some time ago with a script we called 'fsadm'.

http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/LVM2/scripts/fsadm.sh?rev=1.24&content-type=text/plain&cvsroot=lvm2&f=h

Alasdair


fsadm: Utility to resize or check the filesystem on a device

fsadm [options] check device
- Check the filesystem on device using fsck

fsadm [options] resize device [new_size[BKMGTPE]]
- Change the size of the filesystem on device to new_size

Options:
-h | --help Show this help message
-v | --verbose Be verbose
-e | --ext-offline unmount filesystem before ext2/ext3/ext4 resize
-f | --force Bypass sanity checks
-n | --dry-run Print commands without running them
-l | --lvresize Resize given device (if it is LVM device)
-y | --yes Answer "yes" at any prompts

new_size - Absolute number of filesystem blocks to be in the filesystem,
or an absolute size using a suffix (in powers of 1024).
If new_size is not supplied, the whole device is used.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-08-2011, 05:05 PM
Wendy Cheng
 
Default generic wrappers for multi-device FS operations

> On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:
>> 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.
>> Good idea? Bad idea?
>

So the "resize" is on the filesystem, not the volume ? The "grow" part
is probably easy. Unfortunately, the "shrink" may not be easy for some
of the filesystems:

-- Wendy

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-08-2011, 05:13 PM
Ric Wheeler
 
Default generic wrappers for multi-device FS operations

On 03/08/2011 01:05 PM, Wendy Cheng wrote:

On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:

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.
Good idea? Bad idea?

So the "resize" is on the filesystem, not the volume ? The "grow" part
is probably easy. Unfortunately, the "shrink" may not be easy for some
of the filesystems:

-- Wendy


I think any "standard" operation would be allowed to fail with "notsupported"
effectively. Shrink is definitely a challenge & even when it works, it often has
performance implications.


I think that adding support to fsadm might be the easy path forward, but we
would need to be able to do at least a handful of more advanced things (add a
whole device for example).


Ric

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-08-2011, 05:34 PM
James Bottomley
 
Default generic wrappers for multi-device FS operations

On Tue, 2011-03-08 at 13:13 -0500, Ric Wheeler wrote:
> On 03/08/2011 01:05 PM, Wendy Cheng wrote:
> >> On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:
> >>> 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.
> >>> Good idea? Bad idea?
> > So the "resize" is on the filesystem, not the volume ? The "grow" part
> > is probably easy. Unfortunately, the "shrink" may not be easy for some
> > of the filesystems:
> >
> > -- Wendy
>
> I think any "standard" operation would be allowed to fail with "notsupported"
> effectively. Shrink is definitely a challenge & even when it works, it often has
> performance implications.
>
> I think that adding support to fsadm might be the easy path forward, but we
> would need to be able to do at least a handful of more advanced things (add a
> whole device for example).

There's still the problem of moving the underlying device from being a
plain block device to being a dm one ... what happened to the idea of
presenting all devices as dm ones to solve this?

James


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-08-2011, 05:37 PM
Josef Bacik
 
Default generic wrappers for multi-device FS operations

On Tue, Mar 08, 2011 at 10:05:40AM -0800, Wendy Cheng wrote:
> > On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:
> >> 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.
> >> Good idea? Bad idea?
> >
>
> So the "resize" is on the filesystem, not the volume ? The "grow" part
> is probably easy. Unfortunately, the "shrink" may not be easy for some
> of the filesystems:
>

Who wants to make their fs smaller anyway?

Josef

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-08-2011, 05:51 PM
Ric Wheeler
 
Default generic wrappers for multi-device FS operations

On 03/08/2011 01:37 PM, Josef Bacik wrote:

On Tue, Mar 08, 2011 at 10:05:40AM -0800, Wendy Cheng wrote:

On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:

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.
Good idea? Bad idea?

So the "resize" is on the filesystem, not the volume ? The "grow" part
is probably easy. Unfortunately, the "shrink" may not be easy for some
of the filesystems:


Who wants to make their fs smaller anyway?

Josef


I have been surprised more than once by customers who do this on a regular basis

Ric

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-08-2011, 05:51 PM
Ric Wheeler
 
Default generic wrappers for multi-device FS operations

On 03/08/2011 01:34 PM, James Bottomley wrote:

On Tue, 2011-03-08 at 13:13 -0500, Ric Wheeler wrote:

On 03/08/2011 01:05 PM, Wendy Cheng wrote:

On Tue, Mar 08, 2011 at 12:04:25PM -0500, Ric Wheeler wrote:

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.
Good idea? Bad idea?

So the "resize" is on the filesystem, not the volume ? The "grow" part
is probably easy. Unfortunately, the "shrink" may not be easy for some
of the filesystems:

-- Wendy

I think any "standard" operation would be allowed to fail with "notsupported"
effectively. Shrink is definitely a challenge& even when it works, it often has
performance implications.

I think that adding support to fsadm might be the easy path forward, but we
would need to be able to do at least a handful of more advanced things (add a
whole device for example).

There's still the problem of moving the underlying device from being a
plain block device to being a dm one ... what happened to the idea of
presenting all devices as dm ones to solve this?

James


I think that would certainly be a nice start, but we could do something short
term that did not require that.


Ric

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-08-2011, 07:16 PM
Lars Marowsky-Bree
 
Default generic wrappers for multi-device FS operations

On 2011-03-08T12:34:34, James Bottomley <James.Bottomley@suse.de> wrote:

> There's still the problem of moving the underlying device from being a
> plain block device to being a dm one ... what happened to the idea of
> presenting all devices as dm ones to solve this?

Giving remapping abilities to every block device certainly would be
extremly useful.


Regards,
Lars

--
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-08-2011, 07:54 PM
Andreas Dilger
 
Default generic wrappers for multi-device FS operations

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.


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






--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 10:09 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org