[lkml]   [1999]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.3.x wish list?

    ----- Original Message -----
    From: Mark H. Wood <mwood@IUPUI.Edu>
    To: <unlisted-recipients:; (no To-header on input)>
    Cc: Linux Kernel <>
    Sent: Saturday, May 22, 1999 2:23 PM
    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.

    Just had a wacky idea on how they >could< have done it. Suppose you had a
    bit in the inode that indicated the file was in a sub-allocated block. Only
    small files would get combined in a sub-allocated block. Since all inodes
    pointing to the same block would be for sub-allocated block files, we could
    safely assume that this normal data block can have a special format. Say a
    small header table that lists the files inodes and their specific offsets in
    the block (the thought being that there is not enough room in the "regular"
    inode to hold the offset information - and that if any changes needed to be
    made to the sub-allocation, it could all be done in the block itself. There
    would be no need to go back and pull all the inodes for the files that are
    contained in the sub-allocated block). This would only be useful for large
    block sizes (>= 16K ?), but I'm guessing that the overhead should not be too

    Does this make sense, or do I need to explain in more detail?


    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.024 / U:8.344 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site