From owner-freebsd-hackers Thu May 27 2: 8:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hera.webcom.com (hera.webcom.com [209.1.28.42]) by hub.freebsd.org (Postfix) with ESMTP id 4EBC21525C for ; Thu, 27 May 1999 02:08:38 -0700 (PDT) (envelope-from graeme@echidna.com) Received: from eresh.webcom.com (eresh.webcom.com [209.1.28.49]) by hera.webcom.com (8.9.1/8.9.1) with SMTP id CAA03449; Thu, 27 May 1999 02:07:37 -0700 Received: from [204.143.69.53] by inanna.webcom.com (WebCom SMTP 1.2.1) with SMTP id 28202863; Thu May 27 02:03 PDT 1999 Message-Id: <374D356F.80E@echidna.com> Date: Thu, 27 May 1999 05:07:11 -0700 From: Graeme Tait Organization: Echidna X-Mailer: Mozilla 2.02 (Win16; I) Mime-Version: 1.0 To: David Scheidt Cc: freebsd-hackers@freebsd.org, info@boatbooks.com Subject: Re: File system gets too fragmented ??? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Scheidt wrote: > > On Wed, 26 May 1999, Graeme Tait wrote: > > > It contains about 900,000 files, most of which are small, occupying > > around 2-5 fragments. The small files are updated monthly from a tar > > > > > However, I don't understand how the FFS works, so I'm just probing and > > guessing as to what's going on here. > > > > Could someone please shed a little light on this? Is FreeBSD not able to > > self-manage a filesystem operated in this way? Is there some way of > > preventing the problem, or of periodically cleaning things up (rebuilding > > the whole filesystem from backup means being down for over an hour on a > > 24x7 server)? > > The problem you have is that a file on FFS file system can have at most one > fragmented block. With the number of small files that you have, it isn't > terribly suprising that you are running out of full blocks when there is > still space free on the disk. I don't think there is a whole lot you can do > about the problem. A 1024B frag size might mask the problem of having space > free, but with no aligned blocks, not allocatable. You should also think > hard about why you need a million 1536 byte files on the same filesystem. I > don't know what you are doing, but you might consider a real database. I've received several answers along this direction, but I want to emphasize one point that I think is being overlooked. When the filesystem is fresh and a new archive is expanded to create ~900,000 small files each of 2-5 512 byte frags in size, the filesystem appears quite well-behaved, and space seems to be efficiently utilized. The problem seems to be that with successive updates that slightly change the size of files, or add or delete files, that a large number of unallocated fragments are created. I don't understand how the FFS stores files of sub-block size. Do the fragments used need to be contiguous, or entirely within a single block? The choice of 512 byte frags is based on average wastage per file of half a frag, or about 230MB with 900,000 files. It's quite possible that a 2k frag/16k blocksize would improve utilization of fragments, as the vast majority of files would then fit in a single fragment, but in this case there would be of order 800MB wastage, and the files would not fit the existing disk. BTW, I realize there is probably a better way to do this (database, etc.), and we are thinking in that direction, but for the moment we have a legacy setup and not much time to rework it. Also, I would have thought that having many tiny files was not that unusual (e.g., a news spool). -- Graeme Tait - Echidna To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message