Linux-kernel mailing list archive 1998-25,: RE: (reiserfs) Re: LVM / Filesystems / High availability

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

Shawn Leas (sleas@ixion.honeywell.com)
Wed, 24 Jun 1998 15:50:34 -0500 (CDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Rik van Riel: "Re: Again: Just wondering: any AI kernel/system optimization cq. control projects?"
- Previous message: Krzysztof G. Baranowski: "Re: Secure-linux and standard kernel"
- In reply to: : ""
- Next in thread: Florian Lohoff: "Re: (reiserfs) Re: LVM / Filesystems / High availability"

On Wed, 24 Jun 1998, 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.
>
> 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.

When you move an alocated PE on an LV to another PV, it is transparent to
the FS using the LV... Any questions?

-Shawn

> 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.
>
> Zach Amsden
> amsden@andrew.cmu.edu
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>

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

- Next message: Rik van Riel: "Re: Again: Just wondering: any AI kernel/system optimization cq. control projects?"
- Previous message: Krzysztof G. Baranowski: "Re: Secure-linux and standard kernel"
- In reply to: : ""
- Next in thread: Florian Lohoff: "Re: (reiserfs) Re: LVM / Filesystems / High availability"