On Wed, Sep 14, 2011 at 01:25:21PM +0800, Li Zefan wrote:
It's because part of the file is checksummed and the other part is not,
and then btrfs will complain checksum is not found when we read the file.
Disallow file clone if src and dst file have different checksum flag,
so we ensure a
On Wed, Sep 14, 2011 at 01:25:36PM +0800, Li Zefan wrote:
The dst file will have the same inode flags with dst file after
file clone, and I think it's unexpected.
For example, the dst file will suddenly become immutable after
getting some share of data with src file, if the src is immutable.
On Wed, Sep 14, 2011 at 02:11:21PM +0800, Jeff Liu wrote:
On 09/14/2011 01:40 PM, Li Zefan wrote:
14:06, Jeff Liu wrote:
Signed-off-by: Jie Liu jeff@oracle.com
---
fs/btrfs/super.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git
Signed-off-by: Jie Liu jeff@oracle.com
---
fs/btrfs/super.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 15634d4..16f31e1 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -406,7 +406,7 @@ static int
Le Mercredi 7 Septembre 2011 00:11:25 vous avez écrit :
Reading your post, at this point I'd actually recommend you stick with
ext4.
I actually shifted back from BTRFS to ext4 and fell like having offered myself
a brand new computer, about 20 times faster, me happy ;-)
Both btrfs and zfs
Hi,
The following are assorted fixes to error handling from all parts of the
Btrfs code. I included in this series an uncommited patch from Tsutomu Itoh
which was a better version of a patch I had written. He should be cc'd on
that mail.
Some of the patches (the first 8) were previously sent
From: Mark Fasheh mfas...@suse.com
This is called from only one place - create_subvol() which passes errors
safely back out to it's caller, btrfs_mksubvol where they are handled.
Additionally, btrfs_create_subvol_root() itself bug's needlessly from error
return of btrfs_update_inode(). Since
From: Mark Fasheh mfas...@suse.com
insert_ptr() always returns zero, so all the exta error handling can go
away. This makes it trivial to also make copy_for_split() a void function
as it's only return was from insert_ptr(). Finally, this all makes the
BUG_ON(ret) in split_leaf() meaningless so I
From: Mark Fasheh mfas...@suse.com
The only caller of update_ref_for_cow() is __btrfs_cow_block() which was
originally ignoring any return values. update_ref_for_cow() however doesn't
look like a candidate to become a void function - there are a few places
where errors can occur.
So instead I
From: Tsutomu Itoh t-i...@jp.fujitsu.com
Clean up btrfs_lookup_dentry() to never return NULL, but PTR_ERR(-ENOENT)
instead. This keeps the return value convention consistent.
Callers who pass to d_instatiate() require a trivial update.
create_snapshot() in particular looks like it can also lose
From: Mark Fasheh mfas...@suse.com
Since fixup_low_keys() has been made void, del_ptr() always returns zero. We
can then make it void as well. This allows us in turn to make
btrfs_del_leaf() void as the only return value it was previously catching
was from del_ptr(). This winds up removing a
From: Mark Fasheh mfas...@suse.com
In btrfs_add_root_ref() we BUG if an error is encountered during
REF/BACKREF insertion. This does not look like a logic error, thus the BUG
is not called for. However, I don't think there's a simple way to recover
from such an error at that point, so we mark the
From: Mark Fasheh mfas...@suse.com
We BUG_ON a nonzero, non -EAGAIN ret from lock_delalloc_range(). As it turns
out there is no other possible return value that makes sense anyway. The
bare BUG_ON(ret) was a bit confusing and looked like something that needed
fixing. This patch documents the
From: Mark Fasheh mfas...@suse.com
btrfs_get_parent() searches the btree for a ref to the current object. From
there it can compute the parent objectid from which it can return a dentry.
if the reference is not found in the tree however, we BUG(). I believe a
more appropriate response would be to
The only caller of btrfs_alloc_dev_extent() is __btrfs_alloc_chunk() which
already bugs on any error returned. We can remove the BUG_ON's in
btrfs_alloc_dev_extent() then since __btrfs_alloc_chunk() will catch them
anyway.
Signed-off-by: Mark Fasheh mfas...@suse.de
---
fs/btrfs/volumes.c |4
btrfs_alloc_chunk() unconditionally BUGs on any error returned from
__finish_chunk_alloc() so there's no need for two BUG_ON lines. Remove the
one from __finish_chunk_alloc().
Signed-off-by: Mark Fasheh mfas...@suse.de
---
fs/btrfs/volumes.c |4 +++-
1 files changed, 3 insertions(+), 1
From: Mark Fasheh mfas...@suse.com
This is trivial as the function always returns success. We can remove 3
BUG_ON(ret) lines as a result.
Signed-off-by: Mark Fasheh mfas...@suse.com
---
fs/btrfs/delayed-ref.c | 26 ++
1 files changed, 10 insertions(+), 16 deletions(-)
We BUG_ON() error from add_extent_mapping(), but that error looks pretty
easy to bubble back up - as far as I can tell there have not been any
permanent modifications to fs state at that point.
Signed-off-by: Mark Fasheh mfas...@suse.de
---
fs/btrfs/volumes.c |3 ++-
1 files changed, 2
From: Mark Fasheh mfas...@suse.com
add_delayed_tree_ref() unconditionally returns 0. This makes it trivial to
turn into a void function. This kills another BUG_ON().
Signed-off-by: Mark Fasheh mfas...@suse.com
---
fs/btrfs/delayed-ref.c | 16 +++-
1 files changed, 7 insertions(+),
From: Mark Fasheh mfas...@suse.com
update_ref_for_cow() will BUG_ON() after it's call to
btrfs_lookup_extent_info() if no existing references are found. Since refs
are computed directly from disk, this should be treated as a corruption
instead of a logic error.
Signed-off-by: Mark Fasheh
From: Mark Fasheh mfas...@suse.com
balace_level() seems to deal with missing tree nodes by BUG_ON(). Instead,
we can easily just set the file system readonly and bubble -EROFS back up
the stack.
Signed-off-by: Mark Fasheh mfas...@suse.com
---
fs/btrfs/ctree.c | 13 +++--
1 files
From: Mark Fasheh mfas...@suse.com
__btrfs_cow_block(), the only caller of update_ref_for_cow() will BUG_ON()
any error return. Instead, we can go read-only fs as update_ref_for_cow()
manipulates disk data in a way which doesn't look like it's easily rolled
back.
Signed-off-by: Mark Fasheh
From: Mark Fasheh mfas...@suse.com
This is trivial - fixup_low_keys always returns zero so we can make it void.
As a result, we can then make setup_items_for_insert() void too which lets
us cut out a couple of BUG_ON(ret) lines.
Signed-off-by: Mark Fasheh mfas...@suse.de
---
fs/btrfs/ctree.c
From: Mark Fasheh mfas...@suse.com
This is very easy - we can just pass an error from btrfs_find_last_root()
back out to the callers - all of them have proper error handling.
Signed-off-by: Mark Fasheh mfas...@suse.de
---
fs/btrfs/disk-io.c |3 ++-
1 files changed, 2 insertions(+), 1
From: Mark Fasheh mfas...@suse.com
All callers of __finish_chunk_alloc() BUG_ON() return value, so it's trivial
for us to always bubble up any errors caught in __finish_chunk_alloc() to be
caught there.
Signed-off-by: Mark Fasheh mfas...@suse.de
---
fs/btrfs/volumes.c |7 ++-
1 files
Hi,
On Thu, Sep 15, 2011 at 10:34:39AM -0700, Mark Fasheh wrote:
Some of the patches (the first 8) were previously sent to this list but got
no comments so I'm resending them with this set. Changes from last time are
that I also started setting the file system readonly on errors which look
On Thu, Sep 15, 2011 at 11:01:28PM +0800, Jeff Liu wrote:
Signed-off-by: Jie Liu jeff@oracle.com
Reviewed-by: David Sterba dste...@suse.cz
---
fs/btrfs/super.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index
On Tue, 13 Sep 2011, Liu Bo wrote:
On 09/11/2011 05:47 AM, Martin Mailand wrote:
Hi
I am hitting this Warning reproducible, the workload is a ceph osd,
kernel ist 3.1.0-rc5.
Have posted a patch for this:
http://marc.info/?l=linux-btrfsm=131547325515336w=2
We're still seeing this
I'm using btrfs since one year now and it's quite fast. I don't feel any
differences to other filesystems. Never tried a benchmark but for my
daily work it's nice. I also never had any issues with the memory. Imho
nowadays memory isn't a problem at all in desktop computers. I bought
8gb of
On Thu, Sep 15, 2011 at 11:44:09AM -0700, Sage Weil wrote:
On Tue, 13 Sep 2011, Liu Bo wrote:
On 09/11/2011 05:47 AM, Martin Mailand wrote:
Hi
I am hitting this Warning reproducible, the workload is a ceph osd,
kernel ist 3.1.0-rc5.
Have posted a patch for this:
On Thu, Sep 15, 2011 at 11:44:09AM -0700, Sage Weil wrote:
On Tue, 13 Sep 2011, Liu Bo wrote:
On 09/11/2011 05:47 AM, Martin Mailand wrote:
Hi
I am hitting this Warning reproducible, the workload is a ceph osd,
kernel ist 3.1.0-rc5.
Have posted a patch for this:
On Thu, Sep 15, 2011 at 03:50:29PM -0400, Josef Bacik wrote:
We're still seeing this with -rc6, which includes 98c9942 and 65450aa.
I haven't looked at the reservation code in much detail. Is there
anything I can do to help track this down?
This should be taken care of with all my
On Thu, 15 Sep 2011, David Sterba wrote:
On Thu, Sep 15, 2011 at 03:50:29PM -0400, Josef Bacik wrote:
We're still seeing this with -rc6, which includes 98c9942 and 65450aa.
I haven't looked at the reservation code in much detail. Is there
anything I can do to help track this down?
David Sterba wrote:
On Wed, Sep 14, 2011 at 01:25:21PM +0800, Li Zefan wrote:
It's because part of the file is checksummed and the other part is not,
and then btrfs will complain checksum is not found when we read the file.
Disallow file clone if src and dst file have different checksum flag,
Add CC to Coreutils, cp --reflink performs btrfs clone operation.
Thanks,
-Jeff
On 09/15/2011 07:43 PM, David Sterba wrote:
On Wed, Sep 14, 2011 at 01:25:36PM +0800, Li Zefan wrote:
The dst file will have the same inode flags with dst file after
file clone, and I think it's unexpected.
For
35 matches
Mail list logo
