extending volumes [ was growfs + stripes]

Dimitar Vasilev dimitar.vassilev at gmail.com
Mon Oct 24 14:40:51 PDT 2005


2005/10/24, Joerg Wunsch <j at uriah.heep.sax.de>:

> Nope.  Extending a striped volume by another stripe is impossible in
> about any system I've seen so far.  (Extending a striped volume by
> concatenating another set of stripes is something different, and I
> guess GEOM's architecture would allow for that.)

> Extending file systems is something different.  AIX can do it, yes,
> and can even shrink them (which is much more work), albeit it might
> take forever, depending on the load.  Solaris' growfs isn't that much
> more capable than FreeBSD's growfs is, except Solaris has got the
> lockfs(2) syscall so they can grow a filesystem online, while FreeBSD
> requires the filesystem to be unmounted.  Solaris with vxfs is about
> the same as AIX is (but you gotta pay a lot of bucks for that).
>
> I think vinum could be tricked into extending a stripe set by another
> stripe set (so a concetanation will result), but I'm not sure about
> it, and would generally be very careful with that.  (Not sure about
> gvinum here, perhaps it can do it as well.)  But that doesn't seem to
> be Dimitar's intention.  See above, inserting another stripe row will
> completely change the topology, so the file system on top of the
> volume will become invalid.
>
> (I've seen a feature like that being announced in some hardware RAID
> array quite some time ago, but when we tried, it took forever due to
> the massive amount of copy operations needed, and then it crashed
> anyway.)
>
> ISTR someone once analyzed that striping doesn't make much sense with
> modern UFSes at all, as the UFS itself distributes the data already
> well enough, so a concatenation yields the same overall performance.
> Concetanetions are way easier to handle in any respect, and see above,
> once you've added something to the concat, you could use growfs to
> tell the file system to pick up the volume's new size.  I've done this
> a number of times with FreeBSD (albeit with [g]vinum-based volumes),
> but I've also seen it fail occasionally. :-/  But then, I've also
> seen Solaris' growfs getting stuck, and trashing a volume, as well
> as vxvm trashing several hundred Megabytes of data.  To quote a
> signature my colleague is using: ``Failure is not an option.  It comes
> bundled with the software.''
Thanks Joerg!
I prefer keeping corporate toys away from my FreeBSD.
They tend to be intolerant and shape everything in their way.
Google just showed it is possible. With large data and no means of
backup one should become careful.
It's nice that these whole discussions will help someone else
searching for such a solution.
As previously mentioned, we have a resource and 99% will use it to
make a new stripe and
move the data there with loop back rsync. We will have a closed
discussion again soon, as the time to act will come very soon.
With 0,5TB for FTP we will be serving it for about a year.
Then I'm planning to enlarge the storage again and bring also spare
disks for bzipped backups.
To be honest, the real fuss is about that I'm taking up a project that
will require frequent travelling and will be near the ftp-master in
Brno.
I  won't have the same free time as now to commit to the mirror -
especially for hardware upgrades, that's why I tend to "pour disks
until happy".
The effort  is  to concentrate the admin team  on common tasks, not on
rebooting every 2-3 months for an upgrade.
On the other side, I will be close to Rudolf and can be held
personally accountable ;-)
Apologies for the personal off topic, but I'm excited about all this
big coincidence.
Regards,

--
Димитър Василев
Dimitar Vassilev

GnuPG key ID: 0x4B8DB525
Keyserver: pgp.mit.edu
Key fingerprint: D88A 3B92 DED5 917E 341E D62F 8C51 5FC4 4B8D B525


More information about the freebsd-questions mailing list