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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
