Re: (reiserfs) Re: LVM / Filesystems / High availability

Florian Lohoff (flo@quit.mediaways.net)
Thu, 25 Jun 1998 11:49:23 +0200


On Wed, Jun 24, 1998 at 11:29:31AM -0400, Amsden, Zachary wrote:
> > > ... and fs resizing on Linux will need fs support too. Again, the
> > > question is, given that the fs needs to add support, do we need
> > resizing
> > > support at the block device layer TOO? Or is that just extra
> > > unnecessary complexity? I for one would be quite happy with a
> > scheme in
> > > which the filesystem could span multiple block devices; that would
> > allow
> > > shrinking and growing at will, without any complex interaction
> > > requirements between the filesystem and the block device layers.
> >
> > Yes. there must be some layer which maintains the available
> > block devices (and provides the user level tools). This should be
> > done in a file system independend manner.
> > All file systems could be used and with LVM and specifically adapted
> > file systems could even re-size online (at least enlarging a fs may
> > be possible).
> >
> Agreed. Any useful filesystem is resizeable
> offline and thus could benefit from LVM devices.
> This does require the developement of special
> tools for each FS type to do the resize. It
> doesn't require any change to FS kernel code.

Right ... this way it should be realy simple ...

> When you start talking about dynamically
> resizeable filesystems, then you need to change
> the kernel FS code, because the active FS needs
> to be aware of what changes are going to occur
> on the block level, may need to prepare for
> these changes and clean up when they are done.

Normally the LVM should do all things transparently
to the filesystem, presenting a linear-block-adressing
to the fs.

> It gets really complicated when you want to
> remove a block device from an LVM device. The
> LVM device needs to tell the filesystem to
> move all data out of logical blocks xxx-yyy,
> the filesystem needs to do that, and then
> afterwards patch the hole in the LVM address
> space by re-addressing nodes and metadata into
> the newly shrunken address space. The only
> way to avoid this extremely costly re-address
> process would be to implement something like
> paging block devices into the LVM device (at
> least that I can think of right now). That
> seems like a lot of trouble to go to just to
> get live shrinkable FS's. Live growable FS's
> wouldn't be too hard to do with LVMs and a
> simple message to the FS code saying that its
> block device just grew by X blocks.

The LVM has already got the ability to take PVs out of service
online without any filesystem interaction. All PE (physical extends)
get moved to other PVs with free PEs

Flo

-- 
Florian.Lohoff@mediaWays.net			+49-5241-80-7085
aka flo@mini.gt.owl.de			@HOME	+49-5241-470566

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu