Sonny Rao wrote:
On Mon, Aug 09, 2004 at 04:30:51PM -0400, Chris Mason wrote:
On Mon, 2004-08-09 at 16:19, Sonny Rao wrote:
Hi, I'm investigating filesystem performance on sequential read
patterns of large files, and I discovered an odd pattern of block
allocation and subsequent re-allocation after overwrite under reiser3:
Exactly which kernel is this? The block allocator in v3 has changed
recently.
2.6.7 stock
This was done on a newly created filesystem with plenty of available
space and no other files. I tried this test several times and saw the
number of extents for the file vary from 5,6,7 and 134 extents, but it
is always different after each over-write.
You've hit a "feature" of the journal. When you delete a file, the data
blocks aren't available for reuse until the transaction that allocated
them is committed to the log. If you were to put a sync in between each
run of dd, you should get roughly the same blocks allocated each time.
ext3 does the same things, although somewhat differently. The
asynchronous commit is probably just finishing a little sooner on ext3.
First, I expect that an extent-based filesystem like reiserfs
reiser4 is extent based, reiser3 is not.
Ah, I didn't know that. I'm still confused as to why on the first
allocation/create we get such bad fragmentation, you can see that even
though the file is fragmented into 134 blocks, the blocks are very
close together. Most of the extents are only 2 blocks apart.
Sonny
Interesting.What happens without overwrite, that is, if you write more
files without deleting the old ones?
