Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [patch] delayed disk block allocation | Date | Mon, 4 Mar 2002 09:06:39 +0100 |
| |
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/
| |