On 01.08.2011 20:51, Goffredo Baroncelli wrote:
On 08/01/2011 02:22 PM, Jan Schmidt wrote:
I furthermore realized that the term subvolume is omitted in favor
of the term snapshot. This is because I tend to think of snapshots
being read-only (though I very much appreciate they are not).
From: Julia Lawall ju...@diku.dk
Use BUG_ON(x) rather than if(x) BUG();
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@ identifier x; @@
-if (x) BUG();
+BUG_ON(x);
@@ identifier x; @@
-if (!x) BUG();
+BUG_ON(!x);
// /smpl
Signed-off-by: Julia
On 08/01/2011 09:43 PM, liubo wrote:
On 08/02/2011 09:32 AM, liubo wrote:
On 08/02/2011 12:11 AM, Josef Bacik wrote:
We always look for delalloc bytes in our io_tree so we can fill in delalloc.
This is fine in most cases, but if we're writing out the btree_inode this is
just a superfluous
I'm running into a significant slowdown in Btrfs ( 10x slower than
normal) that appears to be due to some issue between how Btrfs is
allocating memory, and how the kernel is expecting Btrfs to allocate
memory.
The problem does seem to be somewhat hardware specific. I can
reproduce on two of my
A power failure has left me with a broken btrfs. Trying to mount the filesystem
with Kernel 3.0 gives me an unrecognized superblock error. btrfs-debug-tree
spits out the folowing:
parent transid verify failed on 349129785344 wanted 120602 found 120627
parent transid verify failed on
Hi all,
[...]
Furthermore, receiving should not need kernel support at all (except for
an optional interface to create a file with a certain inode, we'll see).
Thus, replicating metadata corruptions should be very unlikely.
I think that for receiving we can have three level, which may
OK so on further investigation, I can see that btrfs-debug-tree is failing on:
ret = find_and_setup_root(tree_root, fs_info, BTRFS_CSUM_TREE_OBJECTID,
csum_root);
(line 750 or so)
But the same call with extent_root and dev_root as arguments are successful.
Would this indicate that some branch on
We were only releasing our metadata reservations when doing inline extents,
which isn't correct since we don't need our data reservation either. So call
btrfs_delalloc_release_space() instead of btrfs_delalloc_release_metadata().
This would have been caught earlier but we don't check for
Hi everyone,
This has the rest of the btrfs cleanups for 3.1. The bulk of this is
error handing fixes from SUSE and cleanups from Fujitsu.
Josef figured out that my attempts to optimize writepage were
actually doing much more IO than we needed to, so this simplifies our
writepage code to only
