lkml.org 
[lkml]   [1999]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

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