Permanent uncancellable balance

2013-03-02 Thread Gabriel de Perthuis
Hello,
I have a filesystem that has become unusable because of a balance I can't 
stop. It is very close to full, and the balance is preventing me from 
growing it.

It was started like this:
sudo btrfs filesystem balance start -v -musage=60 -dusage=60 /srv/backups

It has been stuck at 0% across reboots and kernel upgrades (currently on 
3.8.1), and cancelling it had no effect:

Balance on '/srv/backups' is running
0 out of about 5 chunks balanced (95 considered), 100% left

According to atop it is writing but not reading anything.
Unmounting never terminates, so does remounting ro, the only way to 
temporarilly kill it is to reboot. SIGKILL has no effect either. Is there 
*any* way I can get rid of it?

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Permanent uncancellable balance

2013-03-02 Thread Roman Mamedov
On Sat, 2 Mar 2013 10:07:45 + (UTC)
Gabriel de Perthuis g2p.c...@gmail.com wrote:

 Hello,
 I have a filesystem that has become unusable because of a balance I can't 
 stop. It is very close to full, and the balance is preventing me from 
 growing it.
 
 It was started like this:
 sudo btrfs filesystem balance start -v -musage=60 -dusage=60 /srv/backups
 
 It has been stuck at 0% across reboots and kernel upgrades (currently on 
 3.8.1), and cancelling it had no effect:
 
 Balance on '/srv/backups' is running
 0 out of about 5 chunks balanced (95 considered), 100% left
 
 According to atop it is writing but not reading anything.
 Unmounting never terminates, so does remounting ro, the only way to 
 temporarilly kill it is to reboot. SIGKILL has no effect either. Is there 
 *any* way I can get rid of it?
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mount with the skip_balance option
https://btrfs.wiki.kernel.org/index.php/Mount_options
then you can issue btrfs fi balance cancel and it will succeed.

-- 
With respect,
Roman


signature.asc
Description: PGP signature


Re: Permanent uncancellable balance

2013-03-02 Thread Gabriel de Perthuis
On Sat, 02 Mar 2013 17:12:37 +0600, Roman Mamedov wrote:
 Mount with the skip_balance option
 https://btrfs.wiki.kernel.org/index.php/Mount_options then you can issue
 btrfs fi balance cancel and it will succeed.

Excellent, thank you.
I had just thought of doing the same thing with ro and it worked.

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PULL] Btrfs

2013-03-02 Thread Chris Mason
Hi everyone,

Our set of btrfs features, fixes and cleanups are in my for-linus
branch:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus

There is a conflict in fs/btrfs/extent-tree.c, which I merged here:

git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git 
for-linus-merged

The merge is basically combining da633a42170165cbf20a2d3886c7480ccc832ec3 from
my tree with the new writeback_inodes_sb function from the writeback
tree.

The biggest feature in the pull is the new (and still experimental)
raid56 code that David Woodhouse started long ago.  I'm still working
on the parity logging setup that will avoid inconsistent parity after a
crash, so this is only for testing right now.  But, I'd really like to
get it out to a broader audience to hammer out any performance issues or
other problems.

scrub does not yet correct errors on raid5/6 either.

Josef has another pass at fsync performance.  The big change here is to
combine waiting for metadata with waiting for data, which is a big
latency win.  It is also step one toward using atomics from the hardware
during a commit.

Mark Fasheh has a new way to use btrfs send/receive to send only the
metadata changes.  SUSE is using this to make snapper more efficient at
finding changes between snapshosts.

Otherwise we have a large number of fixes and cleanups.  Eric Sandeen
wins the award for removing the most lines, and I'm hoping we steal this
idea from XFS over and over again.

Miao Xie (35) commits (+958/-427):
Btrfs: use seqlock to protect fs_info-avail_{data, metadata, 
system}_alloc_bits (+49/-32)
Btrfs: remove unnecessary dget_parent/dput when creating the pending 
snapshot (+8/-8)
Btrfs: cleanup unnecessary clear when freeing a transaction or a trans 
handle (+0/-2)
Btrfs: fix missing release of qgroup reservation in commit_transaction() 
(+8/-0)
Btrfs: fix the deadlock between the transaction start/attach and commit 
(+16/-1)
Btrfs: fix wrong reserved space in qgroup during snap/subv creation 
(+105/-36)
Btrfs: fix wrong reserved space when deleting a snapshot/subvolume (+19/-2)
Btrfs: check the return value of btrfs_run_ordered_operations() (+2/-2)
Btrfs: fix lots of orphan inodes when the space is not enough (+85/-17)
Btrfs: check the return value of btrfs_start_delalloc_inodes() (+8/-2)
Btrfs: use the inode own lock to protect its delalloc_bytes (+37/-13)
Btrfs: fix the qgroup reserved space is released prematurely (+2/-1)
Btrfs: don't traverse the ordered operation list repeatedly (+5/-14)
Btrfs: fix wrong outstanding_extents when doing DIO write (+9/-11)
Btrfs: flush all dirty inodes if writeback can not start (+31/-9)
Btrfs: use percpu counter for fs_info-delalloc_bytes (+26/-11)
Btrfs: fix the race between bio and btrfs_stop_workers (+1/-2)
Btrfs: fix memory leak of pending_snapshot-inherit (+7/-11)
Btrfs: use percpu counter for dirty metadata count (+42/-40)
Btrfs: use slabs for delayed reference allocation (+115/-21)
Btrfs: serialize unlocked dio reads with truncate (+40/-2)
Btrfs: traverse and flush the delalloc inodes once (+1/-8)
Btrfs: make delayed ref lock logic more readable (+38/-18)
Btrfs: fix trivial error in btrfs_ioctl_resize() (+7/-6)
Btrfs: cleanup similar code in delayed inode (+37/-46)
Btrfs: use common work instead of delayed work (+4/-4)
Btrfs: add a comment for fs_info-max_inline (+6/-0)
Btrfs: make raid attr array more readable (+59/-20)
Btrfs: use bit operation for -fs_state (+14/-12)
Btrfs: fix deadlock due to unsubmitted (+43/-41)
Btrfs: implement unlocked dio write (+23/-12)
Btrfs: protect fs_info-alloc_start (+14/-0)
Btrfs: fix uncompleted transaction (+37/-3)
Btrfs: fix remount vs autodefrag (+45/-2)
Btrfs: use wrapper page_offset (+15/-18)

Josef Bacik (21) commits (+480/-135):
Btrfs: if we aren't committing just end the transaction if we error out 
(+12/-6)
Btrfs: do not overcommit if we don't have enough space for global rsv 
(+19/-2)
Revert Btrfs: fix permissions of empty files not affected by umask (+0/-6)
Btrfs: rework the overcommit logic to be based on the total size (+12/-3)
Btrfs: fix freeing delayed ref head while still holding its mutex (+5/-3)
Btrfs: steal from global reserve if we are cleaning up orphans (+16/-5)
Btrfs: fix how we discard outstanding ordered extents on abort (+7/-26)
Btrfs: delete inline extents when we find them during logging (+18/-0)
Btrfs: wait on ordered extents at the last possible moment (+247/-9)
Btrfs: place ordered operations on a per transaction list (+34/-21)
Btrfs: unreserve space if our ordered extent fails to work (+13/-1)
Btrfs: copy everything if we've created an inline extent (+1/-0)
Btrfs: account for orphan inodes properly during cleanup (+1/-0)
Btrfs: handle errors in compression submission path (+28/-10)
Btrfs: remove extent 

Re: [GIT PULL] Btrfs

2013-03-02 Thread Liu Bo
On Sat, Mar 02, 2013 at 10:15:35AM -0500, Chris Mason wrote:
 Hi everyone,
 
 Our set of btrfs features, fixes and cleanups are in my for-linus
 branch:
 
 git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
 
 There is a conflict in fs/btrfs/extent-tree.c, which I merged here:
 
 git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git 
 for-linus-merged
 
 The merge is basically combining da633a42170165cbf20a2d3886c7480ccc832ec3 from
 my tree with the new writeback_inodes_sb function from the writeback
 tree.
 
 The biggest feature in the pull is the new (and still experimental)
 raid56 code that David Woodhouse started long ago.  I'm still working
 on the parity logging setup that will avoid inconsistent parity after a
 crash, so this is only for testing right now.  But, I'd really like to
 get it out to a broader audience to hammer out any performance issues or
 other problems.
 
 scrub does not yet correct errors on raid5/6 either.
 
 Josef has another pass at fsync performance.  The big change here is to
 combine waiting for metadata with waiting for data, which is a big
 latency win.  It is also step one toward using atomics from the hardware
 during a commit.
 
 Mark Fasheh has a new way to use btrfs send/receive to send only the
 metadata changes.  SUSE is using this to make snapper more efficient at
 finding changes between snapshosts.
 
 Otherwise we have a large number of fixes and cleanups.  Eric Sandeen
 wins the award for removing the most lines, and I'm hoping we steal this
 idea from XFS over and over again.

To people who cares about snapshot-aware defrag, this feature is also included
in the pull.

thanks,
liubo

 
 Miao Xie (35) commits (+958/-427):
 Btrfs: use seqlock to protect fs_info-avail_{data, metadata, 
 system}_alloc_bits (+49/-32)
 Btrfs: remove unnecessary dget_parent/dput when creating the pending 
 snapshot (+8/-8)
 Btrfs: cleanup unnecessary clear when freeing a transaction or a trans 
 handle (+0/-2)
 Btrfs: fix missing release of qgroup reservation in commit_transaction() 
 (+8/-0)
 Btrfs: fix the deadlock between the transaction start/attach and commit 
 (+16/-1)
 Btrfs: fix wrong reserved space in qgroup during snap/subv creation 
 (+105/-36)
 Btrfs: fix wrong reserved space when deleting a snapshot/subvolume 
 (+19/-2)
 Btrfs: check the return value of btrfs_run_ordered_operations() (+2/-2)
 Btrfs: fix lots of orphan inodes when the space is not enough (+85/-17)
 Btrfs: check the return value of btrfs_start_delalloc_inodes() (+8/-2)
 Btrfs: use the inode own lock to protect its delalloc_bytes (+37/-13)
 Btrfs: fix the qgroup reserved space is released prematurely (+2/-1)
 Btrfs: don't traverse the ordered operation list repeatedly (+5/-14)
 Btrfs: fix wrong outstanding_extents when doing DIO write (+9/-11)
 Btrfs: flush all dirty inodes if writeback can not start (+31/-9)
 Btrfs: use percpu counter for fs_info-delalloc_bytes (+26/-11)
 Btrfs: fix the race between bio and btrfs_stop_workers (+1/-2)
 Btrfs: fix memory leak of pending_snapshot-inherit (+7/-11)
 Btrfs: use percpu counter for dirty metadata count (+42/-40)
 Btrfs: use slabs for delayed reference allocation (+115/-21)
 Btrfs: serialize unlocked dio reads with truncate (+40/-2)
 Btrfs: traverse and flush the delalloc inodes once (+1/-8)
 Btrfs: make delayed ref lock logic more readable (+38/-18)
 Btrfs: fix trivial error in btrfs_ioctl_resize() (+7/-6)
 Btrfs: cleanup similar code in delayed inode (+37/-46)
 Btrfs: use common work instead of delayed work (+4/-4)
 Btrfs: add a comment for fs_info-max_inline (+6/-0)
 Btrfs: make raid attr array more readable (+59/-20)
 Btrfs: use bit operation for -fs_state (+14/-12)
 Btrfs: fix deadlock due to unsubmitted (+43/-41)
 Btrfs: implement unlocked dio write (+23/-12)
 Btrfs: protect fs_info-alloc_start (+14/-0)
 Btrfs: fix uncompleted transaction (+37/-3)
 Btrfs: fix remount vs autodefrag (+45/-2)
 Btrfs: use wrapper page_offset (+15/-18)
 
 Josef Bacik (21) commits (+480/-135):
 Btrfs: if we aren't committing just end the transaction if we error out 
 (+12/-6)
 Btrfs: do not overcommit if we don't have enough space for global rsv 
 (+19/-2)
 Revert Btrfs: fix permissions of empty files not affected by umask 
 (+0/-6)
 Btrfs: rework the overcommit logic to be based on the total size (+12/-3)
 Btrfs: fix freeing delayed ref head while still holding its mutex (+5/-3)
 Btrfs: steal from global reserve if we are cleaning up orphans (+16/-5)
 Btrfs: fix how we discard outstanding ordered extents on abort (+7/-26)
 Btrfs: delete inline extents when we find them during logging (+18/-0)
 Btrfs: wait on ordered extents at the last possible moment (+247/-9)
 Btrfs: place ordered operations on a per transaction list (+34/-21)
 Btrfs: unreserve space if our 

Re: [PATCH] btrfs: return EPERM in btrfs_rm_device()

2013-03-02 Thread Ilya Dryomov
On Sat, Mar 02, 2013 at 12:13:59AM -0700, Jerry Snitselaar wrote:
 Currently there are error paths in btrfs_rm_device() where EINVAL is
 returned telling the user they passed an invalid argument even though
 they passed a valid device. Change to return EPERM instead as the
 operation is not permitted.
 
 Signed-off-by: Jerry Snitselaar jerry.snitsel...@oracle.com
 ---
  fs/btrfs/volumes.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
 index 5cbb7f4..3e1586c 100644
 --- a/fs/btrfs/volumes.c
 +++ b/fs/btrfs/volumes.c
 @@ -1392,14 +1392,14 @@ int btrfs_rm_device(struct btrfs_root *root, char 
 *device_path)
   if ((all_avail  BTRFS_BLOCK_GROUP_RAID10)  num_devices = 4) {
   printk(KERN_ERR btrfs: unable to go below four devices 
  on raid10\n);
 - ret = -EINVAL;
 + ret = -EPERM;
   goto out;
   }
  
   if ((all_avail  BTRFS_BLOCK_GROUP_RAID1)  num_devices = 2) {
   printk(KERN_ERR btrfs: unable to go below two 
  devices on raid1\n);
 - ret = -EINVAL;
 + ret = -EPERM;
   goto out;
   }
  
 @@ -1449,14 +1449,14 @@ int btrfs_rm_device(struct btrfs_root *root, char 
 *device_path)
  
   if (device-is_tgtdev_for_dev_replace) {
   pr_err(btrfs: unable to remove the dev_replace target dev\n);
 - ret = -EINVAL;
 + ret = -EPERM;
   goto error_brelse;
   }
  
   if (device-writeable  root-fs_info-fs_devices-rw_devices == 1) {
   printk(KERN_ERR btrfs: unable to remove the only writeable 
  device\n);
 - ret = -EINVAL;
 + ret = -EPERM;

I don't think returning EPERM in these cases is any better than EINVAL.
FWIW, many other btrfs ioctls, especially balance, suffer from this as
well.  What we really need is some kind of error message delivery
system, but that's not going to happen any time soon...

Thanks,

Ilya
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


BTRFS quota support

2013-03-02 Thread Swâmi Petaramesh
Hi folks,

Finaly following general advice received here, I could manage to upgrade
all of my BTRFS boxes to the next Ubuntu Raring kernel (3.8.0-9), so I
assume I now have something decently new ;-)

I'm now looking for quota support, but, even though the wiki page and
Wikipedia english page says BTRFS now has quota support, I couldn't find
any documentation or specific information about it.

If such documentation exists, I would appreciate a pointer...

TIA.

-- 
Swâmi Petaramesh sw...@petaramesh.org http://petaramesh.org PGP 9076E32E
Ne cherchez pas : Je ne suis pas sur Facebook.

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: basic questions regarding COW in Btrfs

2013-03-02 Thread Alex Lyakas
Hi Josef,
I hope it's ok to piggy back on this thread for the following question:

I see that in btrfs_cross_ref_exist()=check_committed_ref() path,
there is the following check:

if (btrfs_extent_generation(leaf, ei) =
btrfs_root_last_snapshot(root-root_item))
goto out;

So this basically means that after we have taken a snap of a subvol,
then all subvol's extents must be COW'ed, even if we delete the snap a
minute later.
I wonder, why is that so?
Is this because file extents can be shared indirectly, like when we
create a snap, we only COW the root and only mark all root's
*immediate* children shared in the extent tree?
Can the new backref walking code be used here to check more
accurately, if the extent is shared by anybody else?

Thanks,
Alex.



On Mon, Feb 25, 2013 at 9:00 PM, Aastha Mehta aasth...@gmail.com wrote:
 Ah okay, I now see how it works. Thanks a lot for your response.

 Regards,
 Aastha.


 On 25 February 2013 18:27, Josef Bacik jba...@fusionio.com wrote:
 On Mon, Feb 25, 2013 at 08:15:40AM -0700, Aastha Mehta wrote:
 Thanks again Josef.

 I understood that cow_file_range is called for a regular file. Just to
 clarify, in cow_file_range is cow done at the time of reserving
 extents in the extent btree for the io to be done in this delalloc? I
 see the following comment above find_free_extent() which is called
 while trying to reserve extents:

 /*
  * walks the btree of allocated extents and find a hole of a given size.
  * The key ins is changed to record the hole:
  * ins-objectid == block start
  * ins-flags = BTRFS_EXTENT_ITEM_KEY
  * ins-offset == number of blocks
  * Any available blocks before search_start are skipped.
  */

 This seems to be the only place where a cow might be done, because a
 key is being inserted into an extent which modifies it.


 The key isn't inserted at this time, it's just returned with those values 
 for us
 to do as we please.  There is no update of the btree until
 insert_reserved_extent/btrfs_mark_extent_written in btrfs_finish_ordered_io.
 Thanks,

 Josef
 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3] Btrfs: fix the deadlock between the transaction start/attach and commit

2013-03-02 Thread Alex Lyakas
Hi Miao,
thanks for the great ASCII graphics and detailed explanation!

Alex.


On Mon, Feb 25, 2013 at 12:20 PM, Miao Xie mi...@cn.fujitsu.com wrote:
 On sun, 24 Feb 2013 21:49:55 +0200, Alex Lyakas wrote:
 Hi Miao,
 can you please explain your solution a bit more.

 On Wed, Feb 20, 2013 at 11:16 AM, Miao Xie mi...@cn.fujitsu.com wrote:
 Now btrfs_commit_transaction() does this

 ret = btrfs_run_ordered_operations(root, 0)

 which async flushes all inodes on the ordered operations list, it introduced
 a deadlock that transaction-start task, transaction-commit task and the 
 flush
 workers waited for each other.
 (See the following URL to get the detail
  http://marc.info/?l=linux-btrfsm=136070705732646w=2)

 As we know, if -in_commit is set, it means someone is committing the
 current transaction, we should not try to join it if we are not JOIN
 or JOIN_NOLOCK, wait is the best choice for it. In this way, we can avoid
 the above problem. In this way, there is another benefit: there is no new
 transaction handle to block the transaction which is on the way of commit,
 once we set -in_commit.

 Signed-off-by: Miao Xie mi...@cn.fujitsu.com
 ---
  fs/btrfs/transaction.c |   17 -
  1 files changed, 16 insertions(+), 1 deletions(-)

 diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
 index bc2f2d1..71b7e2e 100644
 --- a/fs/btrfs/transaction.c
 +++ b/fs/btrfs/transaction.c
 @@ -51,6 +51,14 @@ static noinline void switch_commit_root(struct 
 btrfs_root *root)
 root-commit_root = btrfs_root_node(root);
  }

 +static inline int can_join_transaction(struct btrfs_transaction *trans,
 +  int type)
 +{
 +   return !(trans-in_commit 
 +type != TRANS_JOIN 
 +type != TRANS_JOIN_NOLOCK);
 +}
 +
  /*
   * either allocate a new transaction or hop into the existing one
   */
 @@ -86,6 +94,10 @@ loop:
 spin_unlock(fs_info-trans_lock);
 return cur_trans-aborted;
 }
 +   if (!can_join_transaction(cur_trans, type)) {
 +   spin_unlock(fs_info-trans_lock);
 +   return -EBUSY;
 +   }
 atomic_inc(cur_trans-use_count);
 atomic_inc(cur_trans-num_writers);
 cur_trans-num_joined++;
 @@ -360,8 +372,11 @@ again:

 do {
 ret = join_transaction(root, type);
 -   if (ret == -EBUSY)
 +   if (ret == -EBUSY) {
 wait_current_trans(root);
 +   if (unlikely(type == TRANS_ATTACH))
 +   ret = -ENOENT;
 +   }

 So I understand that instead of incrementing num_writes and joining
 the current transaction, you do not join and wait for the current
 transaction to unblock.

 More specifically,TRANS_START、TRANS_USERSPACE and TRANS_ATTACH can not
 join and just wait for the current transaction to unblock if -in_commit
 is set.

 Which task in Josef's example
 http://marc.info/?l=linux-btrfsm=136070705732646w=2
 task 1, task 2 or task 3 is the one that will not join the
 transaction, but instead wait?

 Task1 will not join the transaction, in this way, async inode flush
 won't run, and then task3 won't do anything.

 Before applying the patch:
 Start/Attach_Trans_Task Commit_Task 
 Flush_Worker
 (Task1) (Task2) 
 (Task3) -- the name in Josef's example
 btrfs_start_transaction()
  |-may_wait_transaction()
  |  (return 0)
  |  btrfs_commit_transaction()
  |   |-set -in_commit and
  |   |  blocked to 1
  |   |-wait writers to be 1
  |   |  (writers is 1)
  |-join_transaction()   |
  |  (writers is 2)   |
  |-btrfs_commit_transaction()   |
  |   |-set trans_no_join to 1
  |   |  (close join transaction)
  |-btrfs_run_ordered_operations |
 (Those ordered operations|
  are added when releasing|
  file)   |
  |-async inode flush()  |
  |-wait_flush_comlete() |
  |  
 work_loop()
  |   
 |-run_work()
  |   
 |-btrfs_join_transaction()
  |
|-wait_current_trans()
  |-wait writers to be 1

 This three tasks waited for each other.

 After applying 

Re: [PATCH v2] btrfs: clean snapshots one by one

2013-03-02 Thread Alex Lyakas
Hi David,

On Fri, Mar 1, 2013 at 6:17 PM, David Sterba dste...@suse.cz wrote:
 Each time pick one dead root from the list and let the caller know if
 it's needed to continue. This should improve responsiveness during
 umount and balance which at some point wait for cleaning all currently
 queued dead roots.

 A new dead root is added to the end of the list, so the snapshots
 disappear in the order of deletion.

 Process snapshot cleaning is now done only from the cleaner thread and
 the others wake it if needed.

 Signed-off-by: David Sterba dste...@suse.cz
 ---

 v1-v2:
 - added s_umount trylock in cleaner thread
 - added exit into drop_snapshot if fs is going down

 patch based on cmason/integration

  fs/btrfs/disk-io.c |   10 ++--
  fs/btrfs/extent-tree.c |8 ++
  fs/btrfs/relocation.c  |3 --
  fs/btrfs/transaction.c |   57 
 
  fs/btrfs/transaction.h |2 +-
  5 files changed, 54 insertions(+), 26 deletions(-)

 diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
 index eb7c143..cc85fc7 100644
 --- a/fs/btrfs/disk-io.c
 +++ b/fs/btrfs/disk-io.c
 @@ -1652,15 +1652,19 @@ static int cleaner_kthread(void *arg)
 struct btrfs_root *root = arg;

 do {
 +   int again = 0;
 +
 if (!(root-fs_info-sb-s_flags  MS_RDONLY) 
 +   down_read_trylock(root-fs_info-sb-s_umount) 
 mutex_trylock(root-fs_info-cleaner_mutex)) {
 btrfs_run_delayed_iputs(root);
 -   btrfs_clean_old_snapshots(root);
 +   again = btrfs_clean_one_deleted_snapshot(root);
 mutex_unlock(root-fs_info-cleaner_mutex);
 btrfs_run_defrag_inodes(root-fs_info);
 +   up_read(root-fs_info-sb-s_umount);
 }

 -   if (!try_to_freeze()) {
 +   if (!try_to_freeze()  !again) {
 set_current_state(TASK_INTERRUPTIBLE);
 if (!kthread_should_stop())
 schedule();
 @@ -3338,8 +3342,8 @@ int btrfs_commit_super(struct btrfs_root *root)

 mutex_lock(root-fs_info-cleaner_mutex);
 btrfs_run_delayed_iputs(root);
 -   btrfs_clean_old_snapshots(root);
 mutex_unlock(root-fs_info-cleaner_mutex);
 +   wake_up_process(root-fs_info-cleaner_kthread);

 /* wait until ongoing cleanup work done */
 down_write(root-fs_info-cleanup_work_sem);
 diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
 index d2b3a5e..0119ae7 100644
 --- a/fs/btrfs/extent-tree.c
 +++ b/fs/btrfs/extent-tree.c
 @@ -7078,6 +7078,8 @@ static noinline int walk_up_tree(struct 
 btrfs_trans_handle *trans,
   * reference count by one. if update_ref is true, this function
   * also make sure backrefs for the shared block and all lower level
   * blocks are properly updated.
 + *
 + * If called with for_reloc == 0, may exit early with -EAGAIN
   */
  int btrfs_drop_snapshot(struct btrfs_root *root,
  struct btrfs_block_rsv *block_rsv, int update_ref,
 @@ -7179,6 +7181,12 @@ int btrfs_drop_snapshot(struct btrfs_root *root,
 wc-reada_count = BTRFS_NODEPTRS_PER_BLOCK(root);

 while (1) {
 +   if (!for_reloc  btrfs_fs_closing(root-fs_info)) {
 +   pr_debug(btrfs: drop snapshot early exit\n);
 +   err = -EAGAIN;
 +   goto out_end_trans;
 +   }
 +
 ret = walk_down_tree(trans, root, path, wc);
 if (ret  0) {
 err = ret;
 diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
 index ba5a321..ab6a718 100644
 --- a/fs/btrfs/relocation.c
 +++ b/fs/btrfs/relocation.c
 @@ -4060,10 +4060,7 @@ int btrfs_relocate_block_group(struct btrfs_root 
 *extent_root, u64 group_start)

 while (1) {
 mutex_lock(fs_info-cleaner_mutex);
 -
 -   btrfs_clean_old_snapshots(fs_info-tree_root);
 ret = relocate_block_group(rc);
 -
 mutex_unlock(fs_info-cleaner_mutex);
 if (ret  0) {
 err = ret;
 diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
 index a83d486..6b233c15 100644
 --- a/fs/btrfs/transaction.c
 +++ b/fs/btrfs/transaction.c
 @@ -950,7 +950,7 @@ static noinline int commit_cowonly_roots(struct 
 btrfs_trans_handle *trans,
  int btrfs_add_dead_root(struct btrfs_root *root)
  {
 spin_lock(root-fs_info-trans_lock);
 -   list_add(root-root_list, root-fs_info-dead_roots);
 +   list_add_tail(root-root_list, root-fs_info-dead_roots);
 spin_unlock(root-fs_info-trans_lock);
 return 0;
  }
 @@ -1858,31 +1858,50 @@ cleanup_transaction:
  }

  /*
 - * interface function to delete all the snapshots we have scheduled for 
 deletion
 + * return  0 if error
 + * 0 if there are no more 

Re: [GIT PULL] Btrfs

2013-03-02 Thread Linus Torvalds
On Sat, Mar 2, 2013 at 7:15 AM, Chris Mason chris.ma...@fusionio.com wrote:

 Our set of btrfs features, fixes and cleanups are in my for-linus
 branch:

I *really* wish that big pull requests like this would come in earlier
in the merge window. I hate seeing them the day before I close the
window - really.  A number of the latter commits are done in the last
few days, which also smells bad.

   Linus
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] Btrfs

2013-03-02 Thread Chris Mason
On Sat, Mar 02, 2013 at 05:45:41PM -0700, Linus Torvalds wrote:
 On Sat, Mar 2, 2013 at 7:15 AM, Chris Mason chris.ma...@fusionio.com wrote:
 
  Our set of btrfs features, fixes and cleanups are in my for-linus
  branch:
 
 I *really* wish that big pull requests like this would come in earlier
 in the merge window. I hate seeing them the day before I close the
 window - really.  A number of the latter commits are done in the last
 few days, which also smells bad.

Definitely, I wanted to send this earlier in the merge window.  But I
was out last week and also didn't want to send the big stuff (raid 5/6
and the fsync work) to you right before I left on vacation.

So instead I sent things off to linux-next, and everyone on the btrfs
list collected fixes while I was gone.

-chris
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html