Re: ufs/ffs resize?
On Sunday, 27 June 1999 at 9:33:09 +0200, [EMAIL PROTECTED] wrote: Another datapoint ot consider, it seems that Linux (at least the derivative version maintained by Alan Cox -- the other one :) ) has now grown an LVM system (probably à la HP or AIX). That's what I've been told yesterday during a small conference about Linux and free software in France (and where I did a talk about FreeBSD *grin*). Hmmm. It might be from SGI. SGI has donated XFS to Linux and is actively marketing it on their Intel based systems. http://www.news.com/News/Item/0,4,36807,00.html?st.ne.fd.tohhed.ni As far as I know it's way too early for the Linux LVM to based on XFS, since SGI hasn't even released the source code yet (just stated that they intend to do so). There's another reason: XFS is a file system, not a volume manager. A volume manager is more like a disk than a file system. In fact, I've seen the Linux LVM before; it's been around for a while, but last time I looked at it I wasn't very interesting. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
Another datapoint ot consider, it seems that Linux (at least the derivative version maintained by Alan Cox -- the other one :) ) has now grown an LVM system (probably à la HP or AIX). That's what I've been told yesterday during a small conference about Linux and free software in France (and where I did a talk about FreeBSD *grin*). Hmmm. It might be from SGI. SGI has donated XFS to Linux and is actively marketing it on their Intel based systems. http://www.news.com/News/Item/0,4,36807,00.html?st.ne.fd.tohhed.ni As far as I know it's way too early for the Linux LVM to based on XFS, since SGI hasn't even released the source code yet (just stated that they intend to do so). Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
On Sunday, 27 June 1999 at 9:33:09 +0200, sth...@nethelp.no wrote: Another datapoint ot consider, it seems that Linux (at least the derivative version maintained by Alan Cox -- the other one :) ) has now grown an LVM system (probably à la HP or AIX). That's what I've been told yesterday during a small conference about Linux and free software in France (and where I did a talk about FreeBSD *grin*). Hmmm. It might be from SGI. SGI has donated XFS to Linux and is actively marketing it on their Intel based systems. http://www.news.com/News/Item/0,4,36807,00.html?st.ne.fd.tohhed.ni As far as I know it's way too early for the Linux LVM to based on XFS, since SGI hasn't even released the source code yet (just stated that they intend to do so). There's another reason: XFS is a file system, not a volume manager. A volume manager is more like a disk than a file system. In fact, I've seen the Linux LVM before; it's been around for a while, but last time I looked at it I wasn't very interesting. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
On Fri, Jun 25, 1999 at 02:00:41PM -0700, Aaron Smith wrote: anybody done any work on a utility for growing ufs filesystems? I wrote one. It is place on ftp://ftp.cosmo-project.de/pub/growfs My tool will grow a UFS filesystem to the current size of the partition. There is still one big problem left when the number of cylindergroups went over a usually 512 align. I hope to free enough time during the next weeks to remove some blocks and add some warnings in this case. With this problem you should check manualy for that condition because it will break the fs in such cases. All bugs should have been documented in the man-page. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
On Fri, Jun 25, 1999 at 02:15:01PM -0700, Matthew Dillon wrote: :anybody done any work on a utility for growing ufs filesystems? : :aaron It has been brought up a couple of times but nobody has tried to do actually it. Personally, I think it would be a doable project if someone wanted to have a go at it - to allow a filesystem to be grown or shrunk on a cylinder-by-cylinder basis. The only real complexity occurs when you are shrinking a filesystem - you have to locate the inodes indirect blocks associated with allocated data blocks in the cylinder you are trying to remove in order to move the blocks. Thats a point you still have to do if you grow a fs - but you don't need to relocate inode but only data-blocks. That's because each cg has a summary information of some bytes which are duplicated at the beginning of the fs in the first cg. In some cases you will need one or more additional blocks in the first cg. unfortunately these are garantied to allocated in case of the first use for the /-dir. Depeneding on what Kirk McKusik wrote this summary information must be of full size. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
On Sun, Jun 27, 1999 at 12:35:54AM +0200, Ollivier Robert wrote: Another datapoint ot consider, it seems that Linux (at least the derivative version maintained by Alan Cox -- the other one :) ) has now grown an LVM system (probably à la HP or AIX). That's what I've been told yesterday during a small conference about Linux and free software in France (and where I did a talk about FreeBSD *grin*). Hmmm. It might be from SGI. SGI has donated XFS to Linux and is actively marketing it on their Intel based systems. http://www.news.com/News/Item/0,4,36807,00.html?st.ne.fd.tohhed.ni Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
I agree with the approach. But why write a simplistic volume manager when we already have vinum? vinum is far from simplistic, but I suppose it might also do. :) Still, it would someday be nice if you could use vinum as the very powerful swiss-army knife that it currently is OR as a dull axe to simply concatenate, ala ccd, n partitions together in some extremely straight-forward fashion. That is to say, instead of having to think about subdisks on plexes on foxes on clockses (sorry Dr. Seuss) when all you wanted to do is whack some space together in a simple and obvious way, you could say something like vinum -C /dev/wd0s1a /dev/sd1s2 /dev/sd2 in order to concatenate wd0/slice 1/partition a, sd1/all of slice 2, and all of drive sd2 together. vinum would choose the volume name itself and return it, from this it being possible to contrive the device pathname for newfs and mount. One might then logically assume the next step would be trivial insertion and deletion options, like: vinum -i /dev/something volumename to insert a new partition into existing volume volumename and vinum -d /dev/something volumename to delete /dev/something from volumename, assuming that it's found in that volume. I guess while I'm dreaming, you could use -M to also create trivial mirror sets and -i and -d could act on those as well. :) Lest anyone get the wrong idea, let me also hastily note here that I'm not trying to suggest that vinum should shed functionality or become dumbed-down - the current amount of flexibility is good and probably in full accord with the unix way insofar as I understand vinum's operation. :) It's also more than a little indimidating to new users, however, many of whom only want to use it for the most simplistic scenarios anyway. Some big dials to go with all the small dials can't hurt, can it? :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
On Fri, Jun 25, 1999 at 02:00:41PM -0700, Aaron Smith wrote: anybody done any work on a utility for growing ufs filesystems? I wrote one. It is place on ftp://ftp.cosmo-project.de/pub/growfs My tool will grow a UFS filesystem to the current size of the partition. There is still one big problem left when the number of cylindergroups went over a usually 512 align. I hope to free enough time during the next weeks to remove some blocks and add some warnings in this case. With this problem you should check manualy for that condition because it will break the fs in such cases. All bugs should have been documented in the man-page. -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de i...@cosmo-project.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
On Fri, Jun 25, 1999 at 02:15:01PM -0700, Matthew Dillon wrote: :anybody done any work on a utility for growing ufs filesystems? : :aaron It has been brought up a couple of times but nobody has tried to do actually it. Personally, I think it would be a doable project if someone wanted to have a go at it - to allow a filesystem to be grown or shrunk on a cylinder-by-cylinder basis. The only real complexity occurs when you are shrinking a filesystem - you have to locate the inodes indirect blocks associated with allocated data blocks in the cylinder you are trying to remove in order to move the blocks. Thats a point you still have to do if you grow a fs - but you don't need to relocate inode but only data-blocks. That's because each cg has a summary information of some bytes which are duplicated at the beginning of the fs in the first cg. In some cases you will need one or more additional blocks in the first cg. unfortunately these are garantied to allocated in case of the first use for the /-dir. Depeneding on what Kirk McKusik wrote this summary information must be of full size. -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de i...@cosmo-project.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
According to Bernd Walter: I wrote one. It is place on ftp://ftp.cosmo-project.de/pub/growfs My tool will grow a UFS filesystem to the current size of the partition. Another datapoint ot consider, it seems that Linux (at least the derivative version maintained by Alan Cox -- the other one :) ) has now grown an LVM system (probably à la HP or AIX). That's what I've been told yesterday during a small conference about Linux and free software in France (and where I did a talk about FreeBSD *grin*). I think one of the difficulty of growing a FS is that you have to choose whether you need the FS to be contiguous or not. The latter case makes it much more difficult... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May 9 20:16:32 CEST 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
On Sun, Jun 27, 1999 at 12:35:54AM +0200, Ollivier Robert wrote: Another datapoint ot consider, it seems that Linux (at least the derivative version maintained by Alan Cox -- the other one :) ) has now grown an LVM system (probably à la HP or AIX). That's what I've been told yesterday during a small conference about Linux and free software in France (and where I did a talk about FreeBSD *grin*). Hmmm. It might be from SGI. SGI has donated XFS to Linux and is actively marketing it on their Intel based systems. http://www.news.com/News/Item/0,4,36807,00.html?st.ne.fd.tohhed.ni Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
there are several greg lehey has been collecting them. julian On Fri, 25 Jun 1999, Aaron Smith wrote: anybody done any work on a utility for growing ufs filesystems? aaron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ufs/ffs resize?
there are several greg lehey has been collecting them. julian On Fri, 25 Jun 1999, Aaron Smith wrote: anybody done any work on a utility for growing ufs filesystems? aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
:anybody done any work on a utility for growing ufs filesystems? : :aaron It has been brought up a couple of times but nobody has tried to do actually it. Personally, I think it would be a doable project if someone wanted to have a go at it - to allow a filesystem to be grown or shrunk on a cylinder-by-cylinder basis. The only real complexity occurs when you are shrinking a filesystem - you have to locate the inodes indirect blocks associated with allocated data blocks in the cylinder you are trying to remove in order to move the blocks. -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
:anybody done any work on a utility for growing ufs filesystems? : :aaron It has been brought up a couple of times but nobody has tried to do actually it. Personally, I think it would be a doable project if someone wanted to have a go at it - to allow a filesystem to be grown or shrunk on a cylinder-by-cylinder basis. The only real complexity occurs when you are shrinking a filesystem - you have to locate the inodes indirect blocks associated with allocated data blocks in the cylinder you are trying to remove in order to move the blocks. the latter would be the task for a packer utility. Myself, I have desired more often to be able to shring a FS than extend one (i mean, barring black magic that would put on a disk more stuff than its capacity). cheers luigi ---+- Luigi RIZZO, lu...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
to do actually it. Personally, I think it would be a doable project if someone wanted to have a go at it - to allow a filesystem to be grown or shrunk on a cylinder-by-cylinder basis. The only real complexity occurs when you are shrinking a filesystem - you have to locat e the inodes indirect blocks associated with allocated data blocks in the cylinder you are trying to remove in order to move the blocks. To add to this, I'd also be inclined to see this done in the larger context of writing at least a simplistic volume manager to contain arbitrary filesystems, then extending UFS to support the concept of dynamic resizing. That way you could extend (the most common request) a ufs partition much more flexibly across multiple partitions or disks, that being what people are *really* asking for when they cry for a resizable UFS. :-) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ufs/ffs resize?
[Format recovered--see http://www.lemis.com/email/email-format.html] On Friday, 25 June 1999 at 18:22:19 -0700, Jordan K. Hubbard wrote: to do actually it. Personally, I think it would be a doable project if someone wanted to have a go at it - to allow a filesystem to be grown or shrunk on a cylinder-by-cylinder basis. The only real complexity occurs when you are shrinking a filesystem - you have to locate the inodes indirect blocks associated with allocated data blocks in the cylinder you are trying to remove in order to move the blocks. To add to this, I'd also be inclined to see this done in the larger context of writing at least a simplistic volume manager to contain arbitrary filesystems, then extending UFS to support the concept of dynamic resizing. I agree with the approach. But why write a simplistic volume manager when we already have vinum? That way you could extend (the most common request) a ufs partition much more flexibly across multiple partitions or disks, that being what people are *really* asking for when they cry for a resizable UFS. :-) Correct. That's why, as Julian observes, I'm collecting code. If somebody else wants to work on this, feel free to contact me. I don't see myself doing it in the very near future. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
