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 > <snip> > > > > 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
