--------------421CA3B4928008C26D0F750
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
-- Lance Dillon | "Not in the face, UNIX/NT Sysadmin | not in the face!" Booz-Allen & Hamilton, Inc. | -- Arthur http://home1.gte.net/riffraff/ |--------------421CA3B4928008C26D0F750 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Message-ID: <34313CEA.92ABB76@gte.net> Date: Tue, 30 Sep 1997 13:54:50 -0400 From: Lance Dillon <riffraff@gte.net> X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.30 i486) MIME-Version: 1.0 To: linux-kernel@vger.rutgers.edu Subject: Re: Logical Volume Manager References: <9709301537.AA25225@mailgate2.telekom.de> <s8bu1avhkv.fsf@luthien.nuclecu.unam.mx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
Miguel de Icaza wrote: > > > It should work like this: > > ------------------------- > > AFTER extending a LV the contained filesystem should be linear > > extentable (superblocks etc.) beyond the old FS limit. > > > > BEFORE reduction of the LV the FS should be shrinkable (moving user data > > and reducing metadata) from its actual end to the new LV size. > > This sure can be done by ext2 if you do not need to do these tasks at > runtime. If you want to grow and shrink an ext2 file system at > runtime, that can prove to be far from a trivial hack. > > In that regard, probably the easier to implement and less disturbing > approach would be to use an approach similar to my patch. But in that > case, I am not sure it makes much sense to use the logical volume > approach. > > If people like the idea (specially, the ext2 maintainers), I could add > the missing bits to the multi-device ext2 patchs (like having the code > be an optional compilation feature and the shrink-fs option, which is > pretty easy to do). > > Best wishes, > Miguel.
we use sequent machines at work, with Dynix/ptx 4.0.1 (i know, really old, but they wont upgrade because we are migrating to nt <even worse, but it was our clients decision>)...
the svm (sequent volume manager) does that sort of thing, but you cant resize a volume at runtime (meaning, not while everything is online)...
first you have to take the relevant volumes offline (which could mean multiple partitions, or even disks, and could be even more involved if you have more than one plex per volume <a plex is one copy of the entire volume....multiple plexes implement mirroring, one copy per plex>)...
then add/delete disks (subdisks, partitions, plexes, whatever), then recreate the volume....which also involves reformatting (newfs on the volume to recreate a filesystem).....as far as i know, there is know what to preserve the filesystem already there, except by performing a backup beforehand...
i just might be easier to implement it that way....
-- Lance Dillon | "Not in the face, UNIX/NT Sysadmin | not in the face!" Booz-Allen & Hamilton, Inc. | -- Arthur http://home1.gte.net/riffraff/ |--------------421CA3B4928008C26D0F750--