Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

[Chris Mason <chris.mason@oracle.com>]

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