[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.057 / U:4.920 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site