On Thu, 27 May 1999, Graeme Tait wrote:
> > 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. imagine: [A][A][B][B][B][C][C][C] <-- 8 frags in 3 files delete a bunch of small files.. (position A or B) Get a bunch of fractionally larger files They aint going to fit.. need a new block... of course it Is posible that where could be a bug where we don't reallocate frags that are early in a block, but I find it a bit hard to believe.. julian > > 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 excess over an integral number of blocks (at the tail of the file) is sized, and a single block with that number of contiguous frag blocks free is sought and allocated. up to 8 files may use frags in the same block, but each can only have 1 contiguous range of frags at it's end. julian > > > 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. sounds a fair tradeoff to me.. a 4GB disk is what? $200? > > > 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 > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
