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