[lkml]   [2002]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] delayed disk block allocation
On March 4, 2002 08:53 am, Andrew Morton wrote:
> Andreas Dilger wrote:
> >
> > Actually, there are a whole bunch of performance issues with 1kB block
> > ext2 filesystems.
> I don't see any new problems with file tails here. They're catered for
> OK. What I have not catered for is file holes. With the delalloc
> patches, whole pages are always written out (except for at eof). So
> if your file has lots of very small non-holes in it, these will become
> larger non-holes.
> If we're serious about 64k PAGE_CACHE_SIZE then this becomes more of
> a problem. In the worst case, a file which used to consist of
> 4k block | (1 meg - 4k) hole | 4k block | (1 meg - 4k) hole | ...
> will become:
> 64k block | (1 meg - 64k) hole | 64k block | (1 meg - 64k hole) | ...
> Which is a *lot* more disk space. It'll happen right now, if the
> file is written via mmap. But with no-buffer-head delayed allocate,
> it'll happen with write(2) as well.
> Is such space wastage on sparse files a showstopper? Maybe,
> but probably not if there is always at least one filesystem
> which handles this scenario well, because it _is_ a specialised
> scenario.

I guess 4K PAGE_CACHE_SIZE will serve us well for another couple of years,
and in that time I hope to produce a patch that generalizes the notion of
page size so we can use the size that works best for each address_space,
i.e., the same as the filesystem blocksize.

By the way, have you ever seen a sparse 1K blocksize file? I haven't, I
wouldn't get too worked up about treating the holes a little less than

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.065 / U:6.792 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site