Btrfs devel - Jul 2007 - list of things to do

> Here are a few ideas of things that won't conflict too much with my
> current enospc work.  But, if you have other ideas or bits you would
> like to improve, please feel free to suggest them, I'm happy to get all
> the help I can.
> 
> 1) On fsync, ext3 and reiserfs have code to let more writers try and
> come into the current transaction before a commit is forced (this is
> called let_transaction_grow in reiserfs).  btrfs needs something
> similar.  It's fairly simple, you look at the count of procs currently
> in the transaction, and if it is non-zero you sleep for a bit before
> forcing the commit.
> 
> It's important to sleep without any locks held and without being in the
> transaction.  Once coded, you can benchmark with Ric Wheeler's fs_mark:
> 
> http://developer.osdl.org/dev/doubt/fs_mark/index.html
> 
> If you're comparing btrfs to ext3 on a sata or ide drive, make sure to
> mount ext3 with -o barrier=1
>
Ok I started looking into this, and I figured the best place to do this would be
in btrfs_commit_transaction, but it appears it already does something like this,
where we check trans->transaction->num_writers > 1, and if it is we
declare a
watiqueue  and sleep for a bit, and keep doing this until we have only 1 or 0
writers.  So it appears you've already done this.  Now I'm getting ready
for my
wedding so its entirely possible that I've lost my mind, and if so please
let me
know :).  If it is the case that you've already done this then I will run
the
fs_mark test to make sure everything is working well.
 
> 2) The in ram portion of the inode needs a field to indicate which
> transaction number last changed the inode.  This field can be checked by
> fsync to decide if a commit is actually required.
> 
> You would have to an index (use a radix tree) of the in memory
> transaction structs so that you can check to make sure a given
> transaction is actually done.
> 
> 3) struct btrfs_root_item has fields for block use accounting, but they
> currently don't get updated.  When blocks are allocated for a given
> root, we need to reflect that in struct btrfs_root_item and send it down
> to disk when the transaction commits.
> 
> The in memory struct btrfs_root has a duplicate of the root item, so the
> updates can be stored in the in memory version and then put into the
> tree once right before commit.
>
I will look into these other things as I get time, but you probably won't
hear
anything out of me for about a week.  If you manage to do these yourself while
I'm out let me know and I'll start tackling things on the TODO list. 
Thanks
much,

Josef

On Tue, 3 Jul 2007 21:00:05 -0400
Josef Bacik <jwhiter@redhat.com> wrote:
> > Here are a few ideas of things that won't conflict too much with
my
> > current enospc work.  But, if you have other ideas or bits you would
> > like to improve, please feel free to suggest them, I'm happy to
get
> > all the help I can.
> > 
> > 1) On fsync, ext3 and reiserfs have code to let more writers try and
> > come into the current transaction before a commit is forced (this is
> > called let_transaction_grow in reiserfs).  btrfs needs something
> > similar.  It's fairly simple, you look at the count of procs
> > currently in the transaction, and if it is non-zero you sleep for a
> > bit before forcing the commit.
> > 
> > It's important to sleep without any locks held and without being
in
> > the transaction.  Once coded, you can benchmark with Ric Wheeler's
> > fs_mark:
> > 
> > http://developer.osdl.org/dev/doubt/fs_mark/index.html
> > 
> > If you're comparing btrfs to ext3 on a sata or ide drive, make
sure
> > to mount ext3 with -o barrier=1
> >
> 
> Ok I started looking into this, and I figured the best place to do
> this would be in btrfs_commit_transaction, but it appears it already
> does something like this, where we check
> trans->transaction->num_writers > 1, and if it is we declare a
> watiqueue  and sleep for a bit, and keep doing this until we have
> only 1 or 0 writers.  So it appears you've already done this.  Now
> I'm getting ready for my wedding so its entirely possible that I've
> lost my mind, and if so please let me know :).
Congrats on the wedding ;)  I'm sure it will be far more fun than
filesystem hacking.  btrfs_commit_transaction does check for more than
one writer, but reiserfs (and I think ext3) also has a check to see if
anyone did work while we were sleeping.  This is something of a gray
area because we're increasing fsync latency slightly in hopes of
increasing overall system throughput.  It's a tradeoff and you don't
always make the right choice.

So, I think the case we're missing is the writer count has gone down to
one (the proc running btrfs_commit_transaction is the only writer), but
while we were sleeping other procs came in and did work.  If we haven't
been waiting too horribly long, we want to sleep again and give more
procs the chance to do something useful.  And, we probably want to
always sleep at least once.

(I'm being intentionally vague in the description because I'm not sure
what will work best on btrfs ;)
> I will look into these other things as I get time, but you probably
> won't hear anything out of me for about a week.  If you manage to do
> these yourself while I'm out let me know and I'll start tackling
> things on the TODO list.  Thanks much,
Enjoy the wedding, best wishes to you and your family.

-chris