Re: growfs(8) for FreeBSD
Thus spake The Hermit Hacker ([EMAIL PROTECTED]): Stripe'd file systems (or concat ones) ... what growfs allows is someone to add an n+1 drive to their RAID/Stripe and increase the size of the file No, vinum can do this alone. But you couldn't grow the _fs_ after that, so there was no use for this vinum feature. Now you can, not only on vinum volumes but also on usual harddisks and ccd devices. At least this is, what Christoph told me. A shrinking utility would be VERY nice, too. I would have use for this :) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs(8) for FreeBSD
On Fri, 8 Dec 2000, Alexander Langer wrote: Thus spake The Hermit Hacker ([EMAIL PROTECTED]): Stripe'd file systems (or concat ones) ... what growfs allows is someone to add an n+1 drive to their RAID/Stripe and increase the size of the file No, vinum can do this alone. But you couldn't grow the _fs_ after that, so there was no use for this vinum feature. Okay, that is what I said ... "add an n+1 drive to ... and increase the size of the file system" ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs(8) for FreeBSD
Stripe'd file systems (or concat ones) ... what growfs allows is someone to add an n+1 drive to their RAID/Stripe and increase the size of the file No, vinum can do this alone. But you couldn't grow the _fs_ after that, so there was no use for this vinum feature. Okay, that is what I said ... "add an n+1 drive to ... and increase the size of the file system" ... I still don't see why growfs wouldn't work on a non-vinum volume. It's just a manipulation of the FS, not of the underlying device. But let's leave this for the makers of growfs to answer shall we =) And yes I know about Vinum, and I know what it can do. =) DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs(8) for FreeBSD
I can certainly see where "cat /dev/1GBdevice /dev/10GBdevice" situations would make a growfs useful w/out vinum... And, removing a failing disk from the end of a a vinum concat volume would make shrinkfs really nice. On 12/08, Rogier R. Mulhuijzen rearranged the electrons to read: Stripe'd file systems (or concat ones) ... what growfs allows is someone to add an n+1 drive to their RAID/Stripe and increase the size of the file No, vinum can do this alone. But you couldn't grow the _fs_ after that, so there was no use for this vinum feature. Okay, that is what I said ... "add an n+1 drive to ... and increase the size of the file system" ... I still don't see why growfs wouldn't work on a non-vinum volume. It's just a manipulation of the FS, not of the underlying device. But let's leave this for the makers of growfs to answer shall we =) And yes I know about Vinum, and I know what it can do. =) DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs(8) for FreeBSD
Hi, In an attempt to resolve that discussion: No, vinum can do this alone. But you couldn't grow the _fs_ after that, so there was no use for this vinum feature. Exactly that was the motivation for writing that utility Okay, that is what I said ... "add an n+1 drive to ... and increase the size of the file system" ... ... which means basically the same :-) I still don't see why growfs wouldn't work on a non-vinum volume. It's just a manipulation of the FS, not of the underlying device. But let's leave this for the makers of growfs to answer shall we =) again correct, technically it is possible to use growfs on ANY object which has a ufs filesystem structure: vinum volume, a partition on a disk, ccd device, even a flat file provided, that there is some space on the end(!) of that medium which is not yet taken by the ufs structures. So you can use it either with hardware RAID controllers which allow for non destructive extending of the size of existing volumes at the end(!). As well you can use it for vinum volumes. Currently this is only possible for mirrored plexes of any kind, or unmirrored concatenated plexes. All other devices cant be changed without destroying the contents. And you can just give some space in the partition table (disklabel) to an existing partition (at its end) and let the filesystem grow within that bound. A shrinkfs is NOT written. The design allows for writing it, but we currently consider other features much more important, like * growing a mounted filesystem * handling file systems with active snapshots is in * grow in a way that we are always safe to loose the power during the growing (softdep concept) * handle byteorder correct on non intel platform (we don't have any alpha hardware but think ufs on alpha is not ufs on intel) * provide the current funktionality on FreeBSD-4 at least, maybe FreeBSD-3 Thomas -- Th.-H.v.Kamptz Die Netz-Werker GmbH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs(8) for FreeBSD
So you can use it either with hardware RAID controllers which allow for non destructive extending of the size of existing volumes at the end(!). Cool. We support the FlexRAID Virtual Sizing stuff on the AMI controllers already, and I bet that the Mylex MORE stuff would work too. * handle byteorder correct on non intel platform (we don't have any alpha hardware but think ufs on alpha is not ufs on intel) Actually, I believe they're the same; as long as you have used explicitly-sized types everywhere, you should be fine. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs(8) for FreeBSD
In message [EMAIL PROTECTED] Goblin writes: : I can certainly see where "cat /dev/1GBdevice /dev/10GBdevice" : situations would make a growfs useful w/out vinum... : : And, removing a failing disk from the end of a a vinum concat volume : would make shrinkfs really nice. I recently did that to "upgrade" my laptop hard disk. Execpt I had to also do dump/restore for the FreeBSD partitions. growfs would have been sweet. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs(8) for FreeBSD
Is it also capable of shrinking filesystems? I've sometimes wanted to grow my /var or / slice using space freed by shrinking /usr (on a default partitioned disk). Up to now I've solved it through symlinks, but that doesn't really deserve the beauty award. I'd imagine a lot of new users wouldn't mind being able to change partition size on a fully configured machine without having to resort to backup, reslice, restore Anyways, sounds like a very handy tool already! Just my $0,02 DocWilco At 10:34 7-12-00 -0800, you wrote: Hi, Due to vinum it is no problem to add disks and grow your volumes but up to now you couldn't easily make use of that new space for a file system, except using sequence of ufsdump/newfs/ufsrestore or something similar. Thomas ([EMAIL PROTECTED]) and me ([EMAIL PROTECTED]) have written a growfs(8) for FreeBSD. Currently we can only grow unmounted file systems (in a clean state) without any active snapshots inside. It is foreseen to enhance growfs to grow mounted file systems as well, and handle active snapshots correctly. This requires some infrastructure which is then only available in FreeBSD-5, whilst the current design runs also happily on FreeBSD-4 and FreeBSD-3 (tested) and possibly even on FreeBSD-2 (untested). To help us gathering the needed data for fixing bugs in growfs we additionally wrote ffsinfo(8), a (very) extended version of dumpfs. We've sent a couple of snapshots of our code to Kirk McKusick and to Greg Lehey. Greg also volunteered :-) for reviewing the code. We also maintain some sort of (for some contractual reasons unilaterally) contact with Don Coleman who is doing the same thing for BSD/OS. -- Ciao Christoph :-) M$: Where do you want to go today? Linux:Where do you want to go tomorrow? FreeBSD: Are you guys comming, or what? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs(8) for FreeBSD
It seems Christoph Herrmann wrote: Sounds very cool, but there is no URL :) Due to vinum it is no problem to add disks and grow your volumes but up to now you couldn't easily make use of that new space for a file system, except using sequence of ufsdump/newfs/ufsrestore or something similar. Thomas ([EMAIL PROTECTED]) and me ([EMAIL PROTECTED]) have written a growfs(8) for FreeBSD. Currently we can only grow unmounted file systems (in a clean state) without any active snapshots inside. It is foreseen to enhance growfs to grow mounted file systems as well, and handle active snapshots correctly. This requires some infrastructure which is then only available in FreeBSD-5, whilst the current design runs also happily on FreeBSD-4 and FreeBSD-3 (tested) and possibly even on FreeBSD-2 (untested). To help us gathering the needed data for fixing bugs in growfs we additionally wrote ffsinfo(8), a (very) extended version of dumpfs. We've sent a couple of snapshots of our code to Kirk McKusick and to Greg Lehey. Greg also volunteered :-) for reviewing the code. We also maintain some sort of (for some contractual reasons unilaterally) contact with Don Coleman who is doing the same thing for BSD/OS. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: growfs(8) for FreeBSD
Erk, I fear you mis-understand ... FreeBSD has a feature called 'VINUM',
which is a volume manager ... basically, it allows you to create RAID or
Stripe'd file systems (or concat ones) ... what growfs allows is someone
to add an n+1 drive to their RAID/Stripe and increase the size of the file
system by that drive, without having to backup the drive, re-format and
then restore ...
I've used Solaris' version and have been much waiting for it to become
available under FreeBSD ...
On Thu, 7 Dec 2000, Rogier R. Mulhuijzen wrote:
Is it also capable of shrinking filesystems? I've sometimes wanted to grow
my /var or / slice using space freed by shrinking /usr (on a default
partitioned disk). Up to now I've solved it through symlinks, but that
doesn't really deserve the beauty award. I'd imagine a lot of new users
wouldn't mind being able to change partition size on a fully configured
machine without having to resort to backup, reslice, restore
Anyways, sounds like a very handy tool already!
Just my $0,02
DocWilco
At 10:34 7-12-00 -0800, you wrote:
Hi,
Due to vinum it is no problem to add disks and grow your volumes but up to
now you couldn't easily make use of that new space for a file system, except
using sequence of ufsdump/newfs/ufsrestore or something similar.
Thomas ([EMAIL PROTECTED]) and me ([EMAIL PROTECTED]) have written a growfs(8)
for FreeBSD. Currently we can only grow unmounted file systems (in a clean
state) without any active snapshots inside. It is foreseen to enhance
growfs to
grow mounted file systems as well, and handle active snapshots correctly.
This requires some infrastructure which is then only available in FreeBSD-5,
whilst the current design runs also happily on FreeBSD-4 and FreeBSD-3
(tested) and possibly even on FreeBSD-2 (untested).
To help us gathering the needed data for fixing bugs in growfs we additionally
wrote ffsinfo(8), a (very) extended version of dumpfs.
We've sent a couple of snapshots of our code to Kirk McKusick and to Greg
Lehey. Greg also volunteered :-) for reviewing the code. We also maintain
some sort of (for some contractual reasons unilaterally) contact with Don
Coleman who is doing the same thing for BSD/OS.
--
Ciao
Christoph :-)
M$: Where do you want to go today?
Linux:Where do you want to go tomorrow?
FreeBSD: Are you guys comming, or what?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: growfs(8) for FreeBSD
On Thu, Dec 07, 2000 at 10:34:44AM -0800, Christoph Herrmann scribbled: | Due to vinum it is no problem to add disks and grow your volumes but up to | now you couldn't easily make use of that new space for a file system, except | using sequence of ufsdump/newfs/ufsrestore or something similar. | | Thomas ([EMAIL PROTECTED]) and me ([EMAIL PROTECTED]) have written a growfs(8) | for FreeBSD. Currently we can only grow unmounted file systems (in a clean | state) without any active snapshots inside. It is foreseen to enhance growfs to | grow mounted file systems as well, and handle active snapshots correctly. | This requires some infrastructure which is then only available in FreeBSD-5, | whilst the current design runs also happily on FreeBSD-4 and FreeBSD-3 | (tested) and possibly even on FreeBSD-2 (untested). | | To help us gathering the needed data for fixing bugs in growfs we additionally | wrote ffsinfo(8), a (very) extended version of dumpfs. Could you please put the code up somewhere that we can also look at? -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
