Re: Squid performance wish-list

Hi Stephen,

        Sorry for getting a little frustrated.

> Yes. Only that in reality, the numbers will not be so bad, as long
> as fragmentation is not at it's maximum. I.e. if the 16MB is in one
> chunk, then it will take only one disk access to delete it.

        True, but as we all know, fragmentation will set in pretty quickly
once the disk is full and you'll never find 16MB chunks again once you
delete a few files and allocate a few in place of the 16MB file.

> Yes, you have, but apparently you misunderstood the properties of the
> chunk in my proposal.

        I think my confusion arose from how you thought that fragmentation
would not occur over time such that there wouldn't be a whole series of
fragment everywhere. I was stating the worst case scenario for both.

> Let's just say that I see the merits of your approach, and I'm 97% convinced
> that your approach is better than what I proposed.

        Consider the effects of ongoing fragmentation over time. The BSD
FFS does make assumptions that fragmentation won't get too severe if it
keeps 10% of the disk space free. With a 4K frag and 8K chunk strategy
you'd probably only need to keep 1% free to guarantee you'll find free 8K
chunks about. The higher the ratio between fragsize and chunksize, the
less chance you'll have (once disks get full) of finding large chunks.
Fragmentation sucks but all we can do is minimalise it to a level where it's
not intrusive.

        Stew.
Received on Tue Jul 29 2003 - 13:15:52 MDT