Jeff Mahoney wrote:
When a file system becomes fragmented (using MythTV, for example), the bigalloc window searching ends up causing huge performance problems. In a file system presented by a user experiencing this bug, the file system was 90% free, but no 32-block free windows existed on the entire file system. This causes the allocator to scan the entire file system for each 128k write before backing down to searching for individual blocks.
Question: Would it be better to take that performance hit once, then cache the result for awhile? If we can't find enough consecutive space, such space isn't likely to appear until a lot of space is freed or a repacker is run.
In the end, finding a contiguous window for all the blocks in a write is an advantageous special case, but one that can be found naturally when such a window exists anyway.
Hmm. Ok, I don't understand how this works, so I'll shut up.
