[Btrfs-devel] [RFC] wait for more writers to join the transaction

[Chris Mason]

On Tue, 7 Aug 2007 21:01:27 -0400
Josef Bacik <jwhiter at redhat.com> wrote:

> On Tue, Aug 07, 2007 at 07:34:42PM -0400, Chris Mason wrote:
> > On Tue, 7 Aug 2007 18:11:54 -0400
> > Josef Bacik <jwhiter at redhat.com> wrote:
> > 
> > > Hello,
> > > 
> > > Sorry for my long silence, getting all situated took longer than I
> > > expected.  I just wrote something very quickly to try and make
> > > btrfs sleep longer if there were writers while we were sleeping
> > > during an fsync.  Running the fs_mark test, btrfs by itself gets
> > > walloped by ext3, so I'm ignoring that for now.  With btrfs+my
> > > patch we seem to get about the same performance, except in the
> > > -S2 and -S5 cases, which are
> > 
> > fs_mark can test lots of different things.  In the multi-threaded
> > tests, the big fat fs_mutex in btrfs is going to hurt us quite a
> > lot, so that part isn't horribly surprising (this is very high on
> > my list to fix).
> > 
> > How did you mount ext3?  If you're running on sata or IDE drives,
> > make sure to use mount -o barrier=1.  btrfs does write barriers by
> > default, so to be fair you have to turn them on in ext3 as well.
> > 
> 
> Yeah I mounted with barrier=1 and ran single threaded tests to try
> and make everything as even as possible.

What speeds did ext3 get?  Anything over ~150 files/s is probably not
getting barriers.  (you can check the kernel dmesg for ext3 saying
barriers are disabled too).

> Yeah my logic is a little flawed in a few other places too I will
> rework this, but glad the overall approach is acceptable.  Thanks
> much for your feedback,

Sounds good, thanks.  Trying things here, it looks like we'll also have
to make something to limit the size of the dead roots list waiting to
be reclaimed via drop_snapshot.

I'm also hitting a problem where the preallocation pool for cow in the
extent tree isn't quite big enough.  So I'll push out that fix at least.

-chris