From owner-freebsd-hackers Fri Nov 8 4:21:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FD1437B401 for ; Fri, 8 Nov 2002 04:21:19 -0800 (PST) Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9605943E3B for ; Fri, 8 Nov 2002 04:21:13 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from dialup-209.247.142.245.dial1.sanjose1.level3.net ([209.247.142.245] helo=mindspring.com) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18A88A-0006vW-00; Fri, 08 Nov 2002 04:20:59 -0800 Message-ID: <3DCBABD7.9DA79043@mindspring.com> Date: Fri, 08 Nov 2002 04:19:35 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ticso@cicely.de Cc: Lukas Ertl , freebsd-hackers@FreeBSD.ORG Subject: Re: resizing mounted filesystems References: <20021107154411.D210-100000@pcle2.cc.univie.ac.at> <3DCAE399.320D754@mindspring.com> <20021108103228.GE46686@cicely8.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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