Messages in this thread | | | Date | Sat, 22 May 1999 13:23:32 -0500 (EST) | From | "Mark H. Wood" <> | Subject | Re: 2.3.x wish list? |
| |
On Thu, 20 May 1999, Kevin M. Bealer wrote: [snippage] > We see an archetectural problem (FSCK takes to long to run), and > are considering fixing it by making really big blocks. Now, I > know there are other advantages, but every time the block size > doubles, the fragmentation loss doubles. If we could stand the > complexity, a buddy system for pieces over a small limit and under > page-size might work, but I think we are fixing the wrong thing.
Assuming for a moment that we are *not* fixing the wrong thing: Novell did something like this in Netware 4 with their "block suballocation". You can set up a volume to be based on 4K, 16K, 32K, or 64K blocks, but if you enable suballocation then tiny files get stuffed into the unused tail-ends of the final blocks of large files. No, I don't know the details of how they do it. It seems to work pretty well. I always set up a Netware server for 64K blocks with suballocation unless I can think of a specific reason why it won't perform well given the server's specific tasks.
But I agree that taking a broader view of the problem is worthwhile.
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu Specializing in unusual perspectives for more than twenty years.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |