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