Date: Fri, 08 Nov 2002 04:19:35 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: ticso@cicely.de Cc: Lukas Ertl <l.ertl@univie.ac.at>, freebsd-hackers@FreeBSD.ORG Subject: Re: resizing mounted filesystems Message-ID: <3DCBABD7.9DA79043@mindspring.com> References: <20021107154411.D210-100000@pcle2.cc.univie.ac.at> <3DCAE399.320D754@mindspring.com> <20021108103228.GE46686@cicely8.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Bernd Walter wrote:
> > Nearly impossible, without a JFS. You would need to be able to add
> > new PP's to an LP, as you can do on AIX, or assign PP's to a "hog"
> > partition, and them provide each LP with "hog limits", so that they
> > can allocate PP's to themselves automatically, as needed, up to some
> > high watermark.
>
> It is doable - just not done.
> E.g. Solstice Disksuite for Solaris does this.
Not quite. It supports growing FS's, but fails to defrag them; it
basically utilizes a version of the "growfs(1)" from the BSD world:
http://docs.sun.com/db/doc/806-3204/6jccb3g8l?a=view#ch1basics-ix63
> > The problem is that the allocation space is spread over all cylinder
> > groups, effectively as a hash. This is the same reason it is
> > recommended that you backup and restore to "defrag" when you run
> > "growfs".
>
> That's a performance reason.
No, it's an implementation problem. I've explained this before,
with nice ASCII-art diagrams.
There's an implicit expectation in the allocation policy that
allocations will be spread more or less evenly across all
cylinder groups. When you violate this expectation, you get
*internal fragmentation*, which simply can't happen any other
way, when using the FS normally. In a normal FFS, there is no
such thing as internal fragmentation.
If, instead of hashing allocations across cylinder groups, as
FFS does, you were to use a journal, log-structured storage,
or extents for storage, then the problem "goes away" (it is
then the problem for the "cleaner" to take care of, on FS's
that have "cleaners").
UFS (FFS) does not have a "cleaner" to unmess the disk.
A disk, fragmented this way, is not the same thing as a Windows
disk which has been fragmented due to poor intrinsic layout
policy, and thus merely results in slightly degraded performance,
or slightly less overall storage being available. A disk
fragmented this way is *broken* for future allocation attempts,
if the hashes happen to fall at the front of the disk enough
times to trigger the soft failure being treated as a hard failure.
We used to have this problem with the IDE drivers in UnixWare
when using VxFS: you would get several soft failures in a row,
and your /usr partition would disappear, and, with the way bad
sectoring was handled by issuing controller commands, only a
low level format would recover writeability for that section of
the disk (VxFS is UFS-derived, which is FFS-derived, in case the
connection isn't obvious).
Rather than snapshots, it would have been nice if we had the
ability to lock and unlock writeability on a per cylinder-group
basis, and used that instead of snapshots for background fsck;
it would also let us do things like background defragging, which
you simply can't implement, using snapshots.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DCBABD7.9DA79043>