On Tue, 2009-02-03 at 19:02 +0530, debian developer wrote: > On Mon, Feb 2, 2009 at 9:28 PM, Steven Pratt <slpratt@xxxxxxxxxxxxxx> wrote: > > > > Finally cleared out a backlog of results to upload. Main performance page is updated with all the links. (http://btrfs.boxacle.net/) Most recent results are on 2.6.29-rc2. As usual see analysis directory of results for oprofile, including call graphs. > > > > Single disk results are not too bad. Raid still falls apart on any write heavy workload. > > Would you please mind explaining how bad the results are and > how much more this needs to be improved for Btrfs to be perfomance > wise acceptable? > > I see that Btrfs almost everywhere lacks XFS and others in some cases. These benchmarks are great because they hammer on some of the worst cases code in btrfs. The mail-server benchmark for example isn't quite a mail server workload because it doesn't fsync the files to disk. But what it does do is hammer on a mixed file read/write/delete workload, which hits btree concurrency and file layout. In my testing here, the big difference between ext4 and btrfs isn't writing to files, it is actually the unlinks. If I take them out of the run, btrfs is very close to ext4 times. So, I'm working on that. The random write workload is probably just a file allocation problem. Btrfs should be perform very well in that workload. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
