[lkml]   [1999]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.3.x wish list?
    On Thu, 20 May 1999, Kevin M. Bealer wrote:
    > 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

    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:51    [W:0.019 / U:28.816 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site