On Thu, Jun 14, 2007 at 08:29:10PM +0200, Florian D. wrote: > Chris Mason wrote: > > The basic list of features looks like this: > [amazing stuff snipped] > > > The current status is a very early alpha state, and the kernel code > > weighs in at a sparsely commented 10,547 lines. I'm releasing now in > > hopes of finding people interested in testing, benchmarking, > > documenting, and contributing to the code. > ok, what kind of benchmarks would help you most? bonnie? compilebench? > sth. other? Thanks! Lets start with a list of the things I know will go badly: O_SYNC (not implemented) O_DIRECT (not implemented) aio (not implemented) multi-threaded (brain dead tree locking) things that fill the drive (will oops) mmap() writes (not supported, mmap reads are ok) Also, overlapping writes are not that well supported. For example, tar by default will write in 10k chunks, and btrfs_file_write currently cows on every single write. So, if your tar file has a bunch of 16k files, it'll go much faster if you tell tar to use 16k (or 8k) buffers. In general, I was hoping for a generic delayed allocation facility to magically appear in the kernel, and so I haven't spent a lot of time tuning btrfs_file_write for this yet. Any other workload is fair game, and I'm especially interested in seeing how badly the COW hurts. For example, on a big file, I'd like to see how much slower big sequential reads are after small random writes (fio is good for this). Or, writing to every file on the FS in random order and then seeing how much slower we are at reading. Benchmarks that stress the directory structure are interesting too, huge numbers of files + directories etc. Ric Wheeler's fs_mark has a lot of options and output. But, that's just my list, you can pick anything that you find interesting ;) Please try btrfsck after the run to see how well it keeps up. If you use blktrace to generate io traces, graphs can be generated: http://oss.oracle.com/~mason/seekwatcher/ Not that well documented, but drop me a line if you need help running it. btt is a good alternative to the graphs too, and easier to run. > > is it possible to test it on top of LVM2 on RAID at this stage? Yes, I haven't done much multi-spindle testing yet, so I'm definitely interested in these numbers. -chris - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
