Hi Chris,
These are a few critical bug fixes for the clone ioctl. We've been
hitting these on a number of different systems, so getting these into
2.6.37 would be much appreciated.
Thanks!
sage
--
Sage Weil (1):
Btrfs: fix lockdep warning on clone ioctl
Yehuda Sadeh (2):
Btrfs: fix
From: Yehuda Sadeh yeh...@hq.newdream.net
The lookup_first_ordered_extent() was done on the wrong inode, and the
-delalloc_bytes test was wrong, as the following
btrfs_wait_ordered_range() would only invoke a range write and wouldn't
write the entire file data range. Also, a bad parameter was
From: Yehuda Sadeh yeh...@hq.newdream.net
We had an edge case issue where the requested range was just
following an existing extent. Instead of skipping to the next
extent, we used the previous one which lead to having zero
sized extents.
Signed-off-by: Yehuda Sadeh yeh...@hq.newdream.net
---
I'm no lockdep expert, but this appears to make the lockdep warning go
away for the i_mutex locking in the clone ioctl.
Signed-off-by: Sage Weil s...@newdream.net
---
fs/btrfs/ioctl.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ioctl.c
On Mon, 18 Oct 2010, Goffredo Baroncelli wrote:
Hi all
like my previous patch, this one allow to remove a subvolume by an ordinary
user. Instead of adding this capability to the rmdir(2) syscall, I update the
BTRFS_IOC_SNAP_DESTROY ioctl, relaxing the rules to be execute.
The checks are
One of my drives on my six drive btrfs setup recently died. I
initially wasn't too worried about it, since both my data and metadata
are raid1. However, I have so far not been able to remove the missing
drive after several attempts.
After discussing my problem on IRC, Chris Mason asked me to
On Wednesday, 20 October, 2010, Sage Weil wrote:
On Mon, 18 Oct 2010, Goffredo Baroncelli wrote:
Hi all
like my previous patch, this one allow to remove a subvolume by an
ordinary
user. Instead of adding this capability to the rmdir(2) syscall, I update
the
BTRFS_IOC_SNAP_DESTROY
