1. 21 11月, 2013 8 次提交
    • L
      Btrfs: fix lockdep error in async commit · b1a06a4b
      Liu Bo 提交于
      Lockdep complains about btrfs's async commit:
      
      [ 2372.462171] [ BUG: bad unlock balance detected! ]
      [ 2372.462191] 3.12.0+ #32 Tainted: G        W
      [ 2372.462209] -------------------------------------
      [ 2372.462228] ceph-osd/14048 is trying to release lock (sb_internal) at:
      [ 2372.462275] [<ffffffffa022cb10>] btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs]
      [ 2372.462305] but there are no more locks to release!
      [ 2372.462324]
      [ 2372.462324] other info that might help us debug this:
      [ 2372.462349] no locks held by ceph-osd/14048.
      [ 2372.462367]
      [ 2372.462367] stack backtrace:
      [ 2372.462386] CPU: 2 PID: 14048 Comm: ceph-osd Tainted: G        W    3.12.0+ #32
      [ 2372.462414] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015  11/09/2011
      [ 2372.462455]  ffffffffa022cb10 ffff88007490fd28 ffffffff816f094a ffff8800378aa320
      [ 2372.462491]  ffff88007490fd50 ffffffff810adf4c ffff8800378aa320 ffff88009af97650
      [ 2372.462526]  ffffffffa022cb10 ffff88007490fd88 ffffffff810b01ee ffff8800898c0000
      [ 2372.462562] Call Trace:
      [ 2372.462584]  [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs]
      [ 2372.462619]  [<ffffffff816f094a>] dump_stack+0x45/0x56
      [ 2372.462642]  [<ffffffff810adf4c>] print_unlock_imbalance_bug+0xec/0x100
      [ 2372.462677]  [<ffffffffa022cb10>] ? btrfs_commit_transaction_async+0x1b0/0x2a0 [btrfs]
      [ 2372.462710]  [<ffffffff810b01ee>] lock_release+0x18e/0x210
      [ 2372.462742]  [<ffffffffa022cb36>] btrfs_commit_transaction_async+0x1d6/0x2a0 [btrfs]
      [ 2372.462783]  [<ffffffffa025a7ce>] btrfs_ioctl_start_sync+0x3e/0xc0 [btrfs]
      [ 2372.462822]  [<ffffffffa025f1d3>] btrfs_ioctl+0x4c3/0x1f70 [btrfs]
      [ 2372.462849]  [<ffffffff812c0321>] ? avc_has_perm+0x121/0x1b0
      [ 2372.462873]  [<ffffffff812c0224>] ? avc_has_perm+0x24/0x1b0
      [ 2372.462897]  [<ffffffff8107ecc8>] ? sched_clock_cpu+0xa8/0x100
      [ 2372.462922]  [<ffffffff8117b145>] do_vfs_ioctl+0x2e5/0x4e0
      [ 2372.462946]  [<ffffffff812c19e6>] ? file_has_perm+0x86/0xa0
      [ 2372.462969]  [<ffffffff8117b3c1>] SyS_ioctl+0x81/0xa0
      [ 2372.462991]  [<ffffffff817045a4>] tracesys+0xdd/0xe2
      
      ====================================================
      
      It's because that we don't do the right thing when checking if it's ok to
      tell lockdep that we're trying to release the rwsem.
      
      If the trans handle's type is TRANS_ATTACH, we won't acquire the freeze rwsem, but
      as TRANS_ATTACH fits the check (trans < TRANS_JOIN_NOLOCK), we'll release the freeze
      rwsem, which makes lockdep complains a lot.
      Reported-by: NMa Jianpeng <majianpeng@gmail.com>
      Signed-off-by: NLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      b1a06a4b
    • L
      Btrfs: avoid heavy operations in btrfs_commit_super · d52c1bcc
      Liu Bo 提交于
      The 'git blame' history shows that, the old transaction commit code has to do
      twice to ensure roots are updated and we have to flush metadata and super block
      manually, however, right now all of these can be handled well inside
      the transaction commit code without extra efforts.
      
      And the error handling part remains same with the current code, -- 'return to
      caller once we get error'.
      
      This saves us a transaction commit and a flush of super block, which are both
      heavy operations according to ftrace output analysis.
      Signed-off-by: NLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      d52c1bcc
    • I
      Btrfs: fix __btrfs_start_workers retval · ba69994a
      Ilya Dryomov 提交于
      __btrfs_start_workers returns 0 in case it raced with
      btrfs_stop_workers and lost the race.  This is wrong because worker in
      this case is not allowed to start and is in fact destroyed.  Return
      -EINVAL instead.
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      ba69994a
    • I
      Btrfs: disable online raid-repair on ro mounts · 908960c6
      Ilya Dryomov 提交于
      This disables the "if needed, write the good copy back before the read
      is completed" part of the read sequence for read-only mounts.
      
      Cc: Jan Schmidt <list.btrfs@jan-o-sch.net>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      908960c6
    • I
      Btrfs: do not inc uncorrectable_errors counter on ro scrubs · 33ef30ad
      Ilya Dryomov 提交于
      Currently if we discover an error when scrubbing in ro mode we a)
      blindly increment the uncorrectable_errors counter, and b) spam the
      dmesg with the 'unable to fixup (regular) error at ...' message, even
      though a) we haven't tried to determine if the error is correctable or
      not, and b) we haven't tried to fixup anything.  Fix this.
      
      Cc: Stefan Behrens <sbehrens@giantdisaster.de>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      33ef30ad
    • J
      Btrfs: only drop modified extents if we logged the whole inode · d006a048
      Josef Bacik 提交于
      If we fsync, seek and write, rename and then fsync again we will lose the
      modified hole extent because the rename will drop all of the modified extents
      since we didn't do the fast search.  We need to only drop the modified extents
      if we didn't do the fast search and we were logging the entire inode as we don't
      need them anymore, otherwise this is being premature.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      d006a048
    • J
      Btrfs: make sure to copy everything if we rename · 6cfab851
      Josef Bacik 提交于
      If we rename a file that is already in the log and we fsync again we will lose
      the new name.  This is because we just log the inode update and not the new ref.
      To fix this we just need to check if we are logging the new name of the inode
      and copy all the metadata instead of just updating the inode itself.  With this
      patch my testcase now passes.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      6cfab851
    • J
      Btrfs: don't BUG_ON() if we get an error walking backrefs · 4724b106
      Josef Bacik 提交于
      We can just return false for this so we stop doing the snapshot aware defrag
      stuff.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      4724b106
  2. 15 11月, 2013 2 次提交
  3. 12 11月, 2013 30 次提交