1. 09 Oct, 2012 17 commits
    • Josef Bacik's avatar
      Btrfs: be smarter about dropping things from the tree log · 18ec90d6
      Josef Bacik authored
      When we truncate existing items in the tree log we've been searching for
      each individual item and removing them.  This is unnecessary churn and
      searching, just keep track of the slot we are on and how many items we need
      to delete and delete them all at once.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      18ec90d6
    • Josef Bacik's avatar
      Btrfs: don't lookup csums for prealloc extents · 6f1fed77
      Josef Bacik authored
      The tree logging stuff was looking up csums to copy over for prealloc
      extents which is just work we don't need to be doing.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      6f1fed77
    • Josef Bacik's avatar
      Btrfs: cache extent state when writing out dirty metadata pages · e6138876
      Josef Bacik authored
      Everytime we write out dirty pages we search for an offset in the tree,
      convert the bits in the state, and then when we wait we search for the
      offset again and clear the bits.  So for every dirty range in the io tree we
      are doing 4 rb searches, which is suboptimal.  With this patch we are only
      doing 2 searches for every cycle (modulo weird things happening).  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      e6138876
    • Josef Bacik's avatar
      Btrfs: do not hold the file extent leaf locked when adding extent item · ce195332
      Josef Bacik authored
      For some reason we unlock everything except the leaf we are on, set the path
      blocking and then add the extent item for the extent we just finished
      writing.  I can't for the life of me figure out why we would want to do
      this, and the history doesn't really indicate that there was a real reason
      for it, so just remove it.  This will reduce our tree lock contention on
      heavy writes.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      ce195332
    • Josef Bacik's avatar
      Btrfs: do not async metadata csumming in certain situations · de0022b9
      Josef Bacik authored
      There are a coule scenarios where farming metadata csumming off to an async
      thread doesn't help.  The first is if our processor supports crc32c, in
      which case the csumming will be fast and so the overhead of the async model
      is not worth the cost.  The other case is for our tree log.  We will be
      making that stuff dirty and writing it out and waiting for it immediately.
      Even with software crc32c this gives me a ~15% increase in speed with O_SYNC
      workloads.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      de0022b9
    • Zach Brown's avatar
      btrfs: fix min csum item size warnings in 32bit · 221b8318
      Zach Brown authored
      commit 7ca4be45 limited csum items to
      PAGE_CACHE_SIZE.  It used min() with incompatible types in 32bit which
      generates warnings:
      
      fs/btrfs/file-item.c: In function ‘btrfs_csum_file_blocks’:
      fs/btrfs/file-item.c:717: warning: comparison of distinct pointer types lacks a cast
      
      This uses min_t(u32,) to fix the warnings.  u32 seemed reasonable
      because btrfs_root->leafsize is u32 and PAGE_CACHE_SIZE is unsigned
      long.
      Signed-off-by: default avatarZach Brown <zab@zabbo.net>
      221b8318
    • Josef Bacik's avatar
      Btrfs: run delayed refs first when out of space · 67b0fd63
      Josef Bacik authored
      Running delayed refs is faster than running delalloc, so lets do that first
      to try and reclaim space.  This makes my fs_mark test about 20% faster.
      Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      67b0fd63
    • Miao Xie's avatar
      Btrfs: fix orphan transaction on the freezed filesystem · 354aa0fb
      Miao Xie authored
      With the following debug patch:
      
       static int btrfs_freeze(struct super_block *sb)
       {
      + 	struct btrfs_fs_info *fs_info = btrfs_sb(sb);
      +	struct btrfs_transaction *trans;
      +
      +	spin_lock(&fs_info->trans_lock);
      +	trans = fs_info->running_transaction;
      +	if (trans) {
      +		printk("Transid %llu, use_count %d, num_writer %d\n",
      +			trans->transid, atomic_read(&trans->use_count),
      +			atomic_read(&trans->num_writers));
      +	}
      +	spin_unlock(&fs_info->trans_lock);
       	return 0;
       }
      
      I found there was a orphan transaction after the freeze operation was done.
      
      It is because the transaction may not be committed when the transaction handle
      end even though it is the last handle of the current transaction. This design
      avoid committing the transaction frequently, but also introduce the above
      problem.
      
      So I add btrfs_attach_transaction() which can catch the current transaction
      and commit it. If there is no transaction, it will return ENOENT, and do not
      anything.
      
      This function also can be used to instead of btrfs_join_transaction_freeze()
      because it don't increase the writer counter and don't start a new transaction,
      so it also can fix the deadlock between sync and freeze.
      
      Besides that, it is used to instead of btrfs_join_transaction() in
      transaction_kthread(), because if there is no transaction, the transaction
      kthread needn't anything.
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      354aa0fb
    • Miao Xie's avatar
      Btrfs: add a type field for the transaction handle · a698d075
      Miao Xie authored
      This patch add a type field into the transaction handle structure,
      in this way, we needn't implement various end-transaction functions
      and can make the code more simple and readable.
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      a698d075
    • Miao Xie's avatar
      Btrfs: fix memory leak in start_transaction() · e8830e60
      Miao Xie authored
      This patch fixes memory leak of the transaction handle which happened
      when starting transaction failed on a freezed fs.
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      e8830e60
    • Mark Fasheh's avatar
      btrfs: extended inode ref iteration · d24bec3a
      Mark Fasheh authored
      The iterate_irefs in backref.c is used to build path components from inode
      refs. This patch adds code to iterate extended refs as well.
      
      I had modify the callback function signature to abstract out some of the
      differences between ref structures. iref_to_path() also needed similar
      changes.
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.de>
      d24bec3a
    • Mark Fasheh's avatar
      btrfs: extended inode refs · f186373f
      Mark Fasheh authored
      This patch adds basic support for extended inode refs. This includes support
      for link and unlink of the refs, which basically gets us support for rename
      as well.
      
      Inode creation does not need changing - extended refs are only added after
      the ref array is full.
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.de>
      f186373f
    • Jan Schmidt's avatar
      btrfs: improved readablity for add_inode_ref · 5a1d7843
      Jan Schmidt authored
      Moved part of the code into a sub function and replaced most of the gotos
      by ifs, hoping that it will be easier to read now.
      Signed-off-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.de>
      5a1d7843
    • Josef Bacik's avatar
      Btrfs: handle not finding the extent exactly when logging changed extents · 0aa4a17d
      Josef Bacik authored
      I started hitting warnings when running xfstest 68 in a loop because there
      were EM's that were not lined up properly with the physical extents.  This
      is ok, if we do something like punch a hole or write to a preallocated space
      or something like that we can have an EM that doesn't cover the entire
      physical extent.  So fix the tree logging stuff to cope with this case so we
      don't just commit the transaction.  With this patch I no longer see the
      warnings from the tree logging code.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      0aa4a17d
    • David Sterba's avatar
      btrfs: move transaction aborts to the point of failure · 005d6427
      David Sterba authored
      Call btrfs_abort_transaction as early as possible when an error
      condition is detected, that way the line number reported is useful
      and we're not clueless anymore which error path led to the abort.
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.cz>
      005d6427
    • Miao Xie's avatar
      Btrfs: fix the missing error information in create_pending_snapshot() · 8732d44f
      Miao Xie authored
      The macro btrfs_abort_transaction() can get the line number of the code
      where the problem happens, so we should invoke it in the place that the
      error occurs, or we will lose the line number.
      Reported-by: default avatarDavid Sterba <dave@jikos.cz>
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      8732d44f
    • Liu Bo's avatar
      Btrfs: fix off-by-one in file clone · aa42ffd9
      Liu Bo authored
      Btrfs uses inclusive range end for lock_extent(), unlock_extent() and
      related functions, so we made off-by-one errors in file clone.
      
      This fixes it and also fixes some style problems.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      aa42ffd9
  2. 04 Oct, 2012 16 commits
    • David Sterba's avatar
      btrfs: allow setting NOCOW for a zero sized file via ioctl · 7e97b8da
      David Sterba authored
      Hi,
      
      the patch si simple, but it has user visible impact and I'm not quite sure how
      to resolve it.
      
      In short, $subj says it, chattr -C supports it and we want to use it.
      
      The conditions that acutally allow to change the NOCOW flag are clear. What if
      I try to set the flag on a file that is not empty? Options:
      
      1) whole ioctl will fail, EINVAL
      2.1) ioctl will succeed, the NOCOW flag will be silently removed, but the file
           will stay COW-ed and checksummed
      2.2) ioctl will succeed, flag will not be removed and a syslog message will
           warn that the COW flag has not been changed
      2.2.1) dtto, no syslog message
      
      Man page of chattr states that
      
       "If it is set on a file which already has data blocks, it is undefined when
       the blocks assigned to the file will be fully stable."
      
      Yes, it's undefined and with current implementation it'll never happen. So from
      this end, the user cannot expect anything. I'm trying to find a reasonable
      behaviour, so that a command like 'chattr -R -aijS +C' to tweak a broad set of
      flags in a deep directory does not fail unnecessarily and does not pollute the
      log.
      
      My personal preference is 2.2.1, but my dev's oppinion is skewed, not counting
      the fact that I know the code and otherwise would look there before consulting
      the documentation.
      
      The patch implements 2.2.1.
      
      david
      
      -------------8<-------------------
      From: David Sterba <dsterba@suse.cz>
      
      It's safe to turn off checksums for a zero sized file.
      
      http://thread.gmane.org/gmane.comp.file-systems.btrfs/18030
      
      "We cannot switch on NODATASUM for a file that already has extents that
      are checksummed. The invariant here is that either all the extents or
      none are checksummed.
      
      Theoretically it's possible to add/remove all checksums from a given
      file, but it's a potentially longtime operation, the file has to be in
      some intermediate state where the checksums partially exist but have to
      be ignored (for the csum->nocsum) until the file is fully converted,
      this brings more special cases to extent handling, it has to survive
      power failure and remain consistent, and probably needs to be restarted
      after next mount."
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.cz>
      7e97b8da
    • Josef Bacik's avatar
      Btrfs: fix punch hole when no extent exists · c3308f84
      Josef Bacik authored
      I saw the warning in btrfs_drop_extent_cache where our end is less than our
      start while running xfstests 68 in a loop.  This is because we
      unconditionally do drop_end = min(end, extent_end) in
      __btrfs_drop_extents(), even though we may not have found an extent in the
      range we were looking to drop.  So keep track of wether or not we found
      something, and if we didn't just use our end.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      c3308f84
    • Josef Bacik's avatar
      Btrfs: don't do anything in our ->freeze_fs and ->unfreeze_fs · 926ced12
      Josef Bacik authored
      We do not need to do anything special to freeze or unfreeze, it's all taken
      care of by the generic work, and what we currently have is wrong anyway
      since we shouldn't be returnning to userspace with mutexes held anyway.
      Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      926ced12
    • Josef Bacik's avatar
      Btrfs: remove unused write cache pages hook · 892951a9
      Josef Bacik authored
      The btree inode has it's own write cache pages so we can remove this write
      cache pages hook as it's not used.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      892951a9
    • Josef Bacik's avatar
      Btrfs: fix race when getting the eb out of page->private · b5bae261
      Josef Bacik authored
      We can race when checking wether PagePrivate is set on a page and we
      actually have an eb saved in the pages private pointer.  We could have
      easily written out this page and released it in the time that we did the
      pagevec lookup and actually got around to looking at this page.  So use
      mapping->private_lock to ensure we get a consistent view of the
      page->private pointer.  This is inline with the alloc and releasepage paths
      which use private_lock when manipulating page->private.  Thanks,
      Reported-by: default avatarDavid Sterba <dave@jikos.cz>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      b5bae261
    • Josef Bacik's avatar
      Btrfs: do not hold the write_lock on the extent tree while logging · ff44c6e3
      Josef Bacik authored
      Dave Sterba pointed out a sleeping while atomic bug while doing fsync.  This
      is because I'm an idiot and didn't realize that rwlock's were spin locks, so
      we've been holding this thing while doing allocations and such which is not
      good.  This patch fixes this by dropping the write lock before we do
      anything heavy and re-acquire it when it is done.  We also need to take a
      ref on the em's in case their corresponding pages are evicted and mark them
      as being logged so that releasepage does not remove them and doesn't remove
      them from our local list.  Thanks,
      Reported-by: default avatarDave Sterba <dave@jikos.cz>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      ff44c6e3
    • Josef Bacik's avatar
      Btrfs: fix race with freeze and free space inodes · 98114659
      Josef Bacik authored
      So we start our freeze, somebody comes in and does an fsync() on a file
      where we have to commit a transaction for whatever reason, and we will
      deadlock because the freeze is waiting on FS_FREEZE people to stop writing
      to the file system, but the transaction is waiting for its free space inodes
      to be written out, which are in turn waiting on sb_start_intwrite while
      trying to write the file extents.  To fix this we'll just skip the
      sb_start_intwrite() if we TRANS_JOIN_NOLOCK since we're being waited on by a
      transaction commit so we're safe wrt to freeze and this will keep us from
      deadlocking.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      98114659
    • Liu Bo's avatar
      Btrfs: kill obsolete arguments in btrfs_wait_ordered_extents · 6bbe3a9c
      Liu Bo authored
      nocow_only is now an obsolete argument.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      6bbe3a9c
    • Liu Bo's avatar
      Btrfs: cleanup fs_info->hashers · 2e90cf85
      Liu Bo authored
      fs_info->hashers is now an obsolete one.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      2e90cf85
    • Liu Bo's avatar
      Btrfs: cleanup for duplicated code in find_free_extent · ab26e9d6
      Liu Bo authored
      There is already an 'add free space' phrase in front of this one, we
      needn't to redo it.
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      ab26e9d6
    • Josef Bacik's avatar
      Btrfs: fix race in sync and freeze again · 60376ce4
      Josef Bacik authored
      I screwed this up, there is a race between checking if there is a running
      transaction and actually starting a transaction in sync where we could race
      with a freezer and get ourselves into trouble.  To fix this we need to make
      a new join type to only do the try lock on the freeze stuff.  If it fails
      we'll return EPERM and just return from sync.  This fixes a hang Liu Bo
      reported when running xfstest 68 in a loop.  Thanks,
      Reported-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      60376ce4
    • David Sterba's avatar
      btrfs: return EPERM upon rmdir on a subvolume · b3ae244e
      David Sterba authored
      A subvolume cannot be deleted via rmdir, but the error code ENOTEMPTY
      is confusing. Return EPERM instead, as this is not permitted.
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.cz>
      b3ae244e
    • Wei Yongjun's avatar
      Btrfs: using for_each_set_bit_from to simplify the code · ebb3dad4
      Wei Yongjun authored
      Using for_each_set_bit_from() to simplify the code.
      
      spatch with a semantic match is used to found this.
      (http://coccinelle.lip6.fr/)
      Signed-off-by: default avatarWei Yongjun <yongjun_wei@trendmicro.com.cn>
      ebb3dad4
    • Anand Jain's avatar
      Btrfs: write_buf is now callable outside send.c · 1bcea355
      Anand Jain authored
      Developing service cmds needs it.
      Signed-off-by: default avatarAnand Jain <anand.jain@oracle.com>
      1bcea355
    • Tsutomu Itoh's avatar
      Btrfs: remove unnecessary code in btree_get_extent() · b4f359ab
      Tsutomu Itoh authored
      Unnecessary lookup_extent_mapping() is removed because an error is
      returned to the caller.
      This patch was made based on the advice from Stefan Behrens, thanks.
      Signed-off-by: default avatarTsutomu Itoh <t-itoh@jp.fujitsu.com>
      b4f359ab
    • Tsutomu Itoh's avatar
      Btrfs: cleanup of error processing in btree_get_extent() · 0433f20d
      Tsutomu Itoh authored
      This patch simplifies a little complex error processing in
      btree_get_extent().
      Signed-off-by: default avatarTsutomu Itoh <t-itoh@jp.fujitsu.com>
      0433f20d
  3. 01 Oct, 2012 7 commits
    • Miao Xie's avatar
      Revert "Btrfs: do not do filemap_write_and_wait_range in fsync" · 90abccf2
      Miao Xie authored
      This reverts commit 0885ef5b
      
      After applying the above patch, the performance slowed down because the dirty
      page flush can only be done by one task, so revert it.
      
      The following is the test result of sysbench:
      	Before		After
      	24MB/s		39MB/s
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      90abccf2
    • Josef Bacik's avatar
      Btrfs: remove bytes argument from do_chunk_alloc · 698d0082
      Josef Bacik authored
      Everybody is just making stuff up, and it's just used to see if we really do
      need to alloc a chunk, and since we do this when we already know we really
      do it's just a waste of space.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      698d0082
    • Josef Bacik's avatar
      Btrfs: delay block group item insertion · ea658bad
      Josef Bacik authored
      So we have lots of places where we try to preallocate chunks in order to
      make sure we have enough space as we make our allocations.  This has
      historically meant that we're constantly tweaking when we should allocate a
      new chunk, and historically we have gotten this horribly wrong so we way
      over allocate either metadata or data.  To try and keep this from happening
      we are going to make it so that the block group item insertion is done out
      of band at the end of a transaction.  This will allow us to create chunks
      even if we are trying to make an allocation for the extent tree.  With this
      patch my enospc tests run faster (didn't expect this) and more efficiently
      use the disk space (this is what I wanted).  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      ea658bad
    • Kent Overstreet's avatar
      btrfs: Kill some bi_idx references · be3940c0
      Kent Overstreet authored
      For immutable bio vecs, I've been auditing and removing bi_idx
      references. These were harmless, but removing them will make auditing
      easier.
      
      scrub_bio_end_io_worker() was open coding a bio_reset() - but this
      doesn't appear to have been needed for anything as right after it does a
      bio_put(), and perusing the code it doesn't appear anything else was
      holding a reference to the bio.
      
      The other use end_bio_extent_readpage() was just for a pr_debug() -
      changed it to something that might be a bit more useful.
      Signed-off-by: default avatarKent Overstreet <koverstreet@google.com>
      CC: Chris Mason <chris.mason@oracle.com>
      CC: Stefan Behrens <sbehrens@giantdisaster.de>
      be3940c0
    • Miao Xie's avatar
      Btrfs: fix unnecessary warning when the fragments make the space alloc fail · 962197ba
      Miao Xie authored
      When we wrote some data by compress mode into a btrfs filesystem which was full
      of the fragments, the kernel will report:
      	BTRFS warning (device xxx): Aborting unused transaction.
      
      The reason is:
      We can not find a long enough free space to store the compressed data because
      of the fragmentary free space, and the compressed data can not be splited,
      so the kernel outputed the above message.
      
      In fact, btrfs can deal with this problem very well: it fall back to
      uncompressed IO, split the uncompressed data into small ones, and then
      store them into to the fragmentary free space. So we shouldn't output the
      above warning message.
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      962197ba
    • Josef Bacik's avatar
      Btrfs: create a pinned em when writing to a prealloc range in DIO · 69ffb543
      Josef Bacik authored
      Wade Cline reported a problem where he was getting garbage and warnings when
      writing to a preallocated range via O_DIRECT.  This is because we weren't
      creating our normal pinned extent_map for the range we were writing to,
      which was causing all sorts of issues.  This patch fixes the problem and
      makes his testcase much happier.  Thanks,
      Reported-by: default avatarWade Cline <clinew@linux.vnet.ibm.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      69ffb543
    • Josef Bacik's avatar
      Btrfs: move the sb_end_intwrite until after the throttle logic · 6df7881a
      Josef Bacik authored
      Sage reported the following lockdep backtrace
      
      =====================================
      [ BUG: bad unlock balance detected! ]
      3.6.0-rc2-ceph-00171-gc7ed62d #1 Not tainted
      -------------------------------------
      btrfs-cleaner/7607 is trying to release lock (sb_internal) at:
      [<ffffffffa00422ae>] btrfs_commit_transaction+0xa6e/0xb20 [btrfs]
      but there are no more locks to release!
      
      other info that might help us debug this:
      1 lock held by btrfs-cleaner/7607:
       #0:  (&fs_info->cleaner_mutex){+.+...}, at: [<ffffffffa003b405>] cleaner_kthread+0x95/0x120 [btrfs]
      
      stack backtrace:
      Pid: 7607, comm: btrfs-cleaner Not tainted 3.6.0-rc2-ceph-00171-gc7ed62d #1
      Call Trace:
       [<ffffffffa00422ae>] ? btrfs_commit_transaction+0xa6e/0xb20 [btrfs]
       [<ffffffff810afa9e>] print_unlock_inbalance_bug+0xfe/0x110
       [<ffffffff810b289e>] lock_release_non_nested+0x1ee/0x310
       [<ffffffff81172f9b>] ? kmem_cache_free+0x7b/0x160
       [<ffffffffa004106c>] ? put_transaction+0x8c/0x130 [btrfs]
       [<ffffffffa00422ae>] ? btrfs_commit_transaction+0xa6e/0xb20 [btrfs]
       [<ffffffff810b2a95>] lock_release+0xd5/0x220
       [<ffffffff81173071>] ? kmem_cache_free+0x151/0x160
       [<ffffffff8117d9ed>] __sb_end_write+0x7d/0x90
       [<ffffffffa00422ae>] btrfs_commit_transaction+0xa6e/0xb20 [btrfs]
       [<ffffffff81079850>] ? __init_waitqueue_head+0x60/0x60
       [<ffffffff81634c6b>] ? _raw_spin_unlock+0x2b/0x40
       [<ffffffffa0042758>] __btrfs_end_transaction+0x368/0x3c0 [btrfs]
       [<ffffffffa0042808>] btrfs_end_transaction_throttle+0x18/0x20 [btrfs]
       [<ffffffffa00318f0>] btrfs_drop_snapshot+0x410/0x600 [btrfs]
       [<ffffffff8132babd>] ? do_raw_spin_unlock+0x5d/0xb0
       [<ffffffffa00430ef>] btrfs_clean_old_snapshots+0xaf/0x150 [btrfs]
       [<ffffffffa003b405>] ? cleaner_kthread+0x95/0x120 [btrfs]
       [<ffffffffa003b419>] cleaner_kthread+0xa9/0x120 [btrfs]
       [<ffffffffa003b370>] ? btrfs_destroy_delayed_refs.isra.102+0x220/0x220 [btrfs]
       [<ffffffff810791ee>] kthread+0xae/0xc0
       [<ffffffff810b379d>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff8163e744>] kernel_thread_helper+0x4/0x10
       [<ffffffff81635430>] ? retint_restore_args+0x13/0x13
       [<ffffffff81079140>] ? flush_kthread_work+0x1a0/0x1a0
       [<ffffffff8163e740>] ? gs_change+0x13/0x13
      
      This is because the throttle stuff can commit the transaction, which expects to
      be the one stopping the intwrite stuff, but we've already done it in the
      __btrfs_end_transaction.  Moving the sb_end_intewrite after this logic makes the
      lockdep go away.  Thanks,
      Tested-by: default avatarSage Weil <sage@inktank.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      6df7881a