Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Jun 1997 11:23:52 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        gpalmer@FreeBSD.ORG (Gary Palmer)
Cc:        jkh@time.cdrom.com, current@FreeBSD.ORG
Subject:   Re: overclocking
Message-ID:  <199706101823.LAA02815@phaeton.artisoft.com>
In-Reply-To: <18340.865926916@orion.webspan.net> from "Gary Palmer" at Jun 10, 97 03:15:16 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > Most importantly, I'd like to be able to migrate off and dismount a
> > drive from a ccd or add one dynamically, automagically resizing the
> > filesystem on it in either case, before I could ever consider it close
> > to mission critical safe.
> 
> Question: How do you plan to dynamically resize a UFS filesystem? I
> think it'd take a LOT of work, as you'd have to ensure that your
> filesystem had all the data (i.e. inode blocks, cylinder groups, etc)
> associated with each file, on the same drive as the file, and that the
> file would basically have to fit on the drive (this is assuming you
> don't want to write a new filesystem).

You write a fragger and a defragger, and frag the heck out of it when
shrinking (pack it at the front of the disk) and "defrag" it back to
a wide dispersion after setting the new size.

You can also add cylinder groups, but you need to "defrag" after that
as well to get a uniform hash dispersion.

It's relatively brain-damaged.  If you plan on doing this, it's better
to define a "PP" and "LP" aware FS instead of one that relies on hashing
over the entire space.  This is a complex task.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706101823.LAA02815>