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
optimally.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:31 EST