> Theodore Y. Ts'o wrote:
> > Different people use LVM in different ways. Some people think of
> > LVM as something you can do by creating a fake block device "out of
> > bits of real devices", as you put it. Other people put stronger
> > requirements on "LVM", which effectively requires that the filesystem
> > be involved at a very real level.
>
> There are two levels of LVM on HP-UX:
>
> 1. The basic LVM functionality is to provide a virtual block device
> (logical volumes) and also provides some RAID levels. Resizing of
> filesystem requires unmounting and using the extendfs utility.
True.
> 2. The optional on-line LVM provides on-line resizing functionality.
> This requires tight integration with the fs code. IMO on HP-UX
> this requires usage of the vxfs (veritas) file system and is not
> possible with hfs. The fsadm utility is used to perform on-line
> operations on a file system.
Well, tight integration? Hmm, the fsadm util might have to tell the LVM
what PE were [un]allocated, but most of the functionality is still LVM
only.
> 3. Additional HA functionality (like shared volumes).
>
> The basic LVM functionality should be rather easy. The implementation
> of Heinz Mauelshausen does already include most of the functionality
> and the user space utilities. Merging the existing MD code (or the
> functionality) should get us there. All we'd need as a beginning
> is a tool per filesystem which allows offline fs resizing.
And maybe a derfagger whos main purpose is to bring allocation away from
the "end" of the fs to a selectable extent. This functionality could be
introduced into ext[23]resize.
> > In general, existing implementations either don't deal at all, or they
> > deal by having the filesystem use a structured block address scheme one
> > way or another. For example, when we add extent maps to ext2, I plan to
> > leave room for so that block numbers can be 8 bytes long, instead of 4
> > bytes. The low 4 bytes will be the original block address, as before.
> > The next 2 bytes will eventually contain the LVM index, where each
> > additional logical volume will contain its own superblock and UUID, plus
> > an indication that this is a subsidiary volume (and the UUID of the
> > master volume). The master volume is the first volume created in the
> > LVM set, and it will contain a table mapping LVM index numbers to UUIDs'
> > of each subsidary volume. (The last 2 bytes of the 8 byte address will
> > be reserved for future expansion.)
> >
> > This makes it easy to remove a LVM in the middle of the filesystem; you
> > simply move the blocks of that particular LVM to other LVM's, and then
> > remove the LVM from the master disk's LVM table.
>
> This still requires off-line resizing (as the re-sizing of ext2
> is not trivial to do safe)? For "online" functionality, ext2 would
> need to be able to use or free an extend on the fly. Otherwise
I think this is getting ahead of ourselves, but it IS something to be
planning for. Lets just leave room for desert at this point...
> using a logical volume should be fine.
I agree here!
-Shawn
> Michael
>
> --
> Michael Marxmeier Marxmeier Software GmbH
> E-Mail: mike@msede.com Besenbruchstrasse 9
> Voice : +49 202 2431440 42285 Wuppertal, Germany
> Fax : +49 202 2431420 http://www.msede.com/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu