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>