On Sun, Dec 13, 2009 at 12:29:03AM +, Jason White wrote:
> I am testing a Btrfs root file system with Debian (kernel 2.6.32) under KVM.
>
> ja...@vrtl:~$ touch testfile
> ja...@vrtl:~$ cp --reflink testfile /tmp
> cp: failed to clone `/tmp/testfile': Invalid argument
>
> This is with GNU Core
[cc: Chris -- This, or something like it, should probably go to
stable, but it needs to make it to upstream somewhere first.]
On Sun, Dec 13, 2009 at 6:42 PM, TARUISI Hiroaki
wrote:
> Hi,
>
> We can see the patch in ML archive or at 'Patchwork' site.
>
> http://patchwork.kernel.org/patch/59519/
With slab poisoning on you could panic the box simply by running btrfsctl -l
multiple times in a row on the same volume. This patch fixes up the ioctl stuff
to be a bit cleaner, makes sure we always call btrfs_free_path() instead of
kfree(path) and make sure we do not kfree() our work names before
Since theres not a good way to make sure the user sees the original default root
tree id, and not to mention it's 5 so is way different than any other volume,
just make subvol=0 mount the original default root. This makes it a bit easier
for users to handle in the long run. Thanks,
Signed-off-by
Christoph's patch e244a0aeb6a599c19a7c802cda6e2d67c847b154 doesn't display
the discard option in /proc/mounts, leading to some confusion for me.
Here's the missing bit.
Signed-off-by: Matthew Wilcox
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 752a546..5e5bd29 100644
--- a/fs/btrfs/su
On Mon, Dec 14, 2009 at 03:01:12PM -0700, Matthew Wilcox wrote:
>
> Christoph's patch e244a0aeb6a599c19a7c802cda6e2d67c847b154 doesn't display
> the discard option in /proc/mounts, leading to some confusion for me.
> Here's the missing bit.
>
> Signed-off-by: Matthew Wilcox
Looks good, sorry fo
Hi,
I think message:'Operation not permitted' is more
proper for this problem than 'Invalid cross-device
link' simply because this link is not cross-device
link.
Of course, this operation is prohibited not by security
policy but by inner limitation of btrfs, this usage of
EPERM may be a kind of a
(2009/12/15 4:17), Josef Bacik wrote:
> With slab poisoning on you could panic the box simply by running btrfsctl -l
> multiple times in a row on the same volume. This patch fixes up the ioctl
> stuff
> to be a bit cleaner, makes sure we always call btrfs_free_path() instead of
> kfree(path) and
TARUISI Hiroaki wrote:
Hi,
I think message:'Operation not permitted' is more
proper for this problem than 'Invalid cross-device
link' simply because this link is not cross-device
link.
Of course, this operation is prohibited not by security
policy but by inner limitation of btrfs, this usage of
__tree_search() returns the reverse result about the prev node and the next
node. And we can
get the prev node and the next node directly by rb_prev() and rb_next(), so it
is unnecessary
to use while loop to get them.
This patch fixes this bug of the wrong result.
Signed-off-by: Miao Xie
---
It is unnecessary to check whether the range intersects the prev extent, because
the end of the prev extent must be less than or equal the start of the range to
search.
This patch cleanups those unnecessary check code in lookup_extent_mapping()
Signed-off-by: Miao Xie
---
fs/btrfs/extent_map.c
It is unnecessary to get the prev node by getting the next node first, because
we can get the prev node directly by rb_prev(). And it is also unnecessary to
use
while loop to get the prev node.
This patch cleanups those unnecessary code in __tree_search() in ordered-data.c
Signed-off-by: Miao Xi
This patch removes tree_search() in extent_map.c because it is not called by
anything.
Signed-off-by: Miao Xie
---
fs/btrfs/extent_map.c | 14 --
1 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/fs/btrfs/extent_map.c b/fs/btrfs/extent_map.c
index 07ec673..fe4bb5e 100
13 matches
Mail list logo
