On Thu, Jan 31, 2013 at 03:03:06PM +0200, Alex Lyakas wrote:
# umount may get delayed because of pending-for-deletion subvolumes:
btrfs_commit_super() locks the cleaner_mutex, so it will wait for the
cleaner to complete.
On the other hand, cleaner will not give up until it completes
Thanks for your comments, Josef.
Another thing that confuses me is that there are some cases, in which
btrfs_drop_snapshot() has a failure, but still returns 0, like for
example, if btrfs_del_root() fails. (For cases when
btrfs_drop_snapshot() returns non-zero there is a BUG_ON).
So in this case
Can anyone please comment on below?
On Thu, Jan 31, 2013 at 3:03 PM, Alex Lyakas
alex.bt...@zadarastorage.com wrote:
Hi,
I want to check if any of the below issues are worth/should be fixed:
# btrfs_ioctl_snap_destroy() does not commit a transaction. As a
result, user can ask to delete a
On Thu, Jan 31, 2013 at 06:03:06AM -0700, Alex Lyakas wrote:
Hi,
I want to check if any of the below issues are worth/should be fixed:
# btrfs_ioctl_snap_destroy() does not commit a transaction. As a
result, user can ask to delete a subvol, he receives ok back. Even
if user does btrfs sub
Hi,
I want to check if any of the below issues are worth/should be fixed:
# btrfs_ioctl_snap_destroy() does not commit a transaction. As a
result, user can ask to delete a subvol, he receives ok back. Even
if user does btrfs sub list,
he will not see the deleted subvol (even though the
