Oops, here is the attachement...
root tree
leaf 29401088 items 15 free space 1691 generation 37 owner 1
fs uuid 606227ec-aa2e-43de-8b81-a56b70d1084e
chunk uuid d18a5784-11ed-4d14-a437-56bab0d6d1f9
item 0 key (EXTENT_TREE ROOT_ITEM 0) itemoff 3756 itemsize 239
root data
On 07/25/2012 06:41 PM, Guenther Rasch wrote:
Hi!
I'm writing my bsc thesis about btrfs and I'm analyzing the
btrfs metadata structure at the moment.
I'm using fedora 17 with kernel 3.4 and btrfs-prog from your
git-repository. For an overview I use btrfs-debug-tree and
here are my
(2012/07/26 15:57), Miao Xie wrote:
The snapshot should be the image of the fs tree before it was created,
so the metadata of the snapshot should not exist in the its tree. But now, we
found the directory item and directory name index is in both the snapshot tree
and the fs tree. It introduces
Check for the return value of 'open_ctree()' before dereferencing it.
Signed-off-by: Nageswara R Sastry nasas...@in.ibm.com
---
btrfs-image.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/btrfs-image.c b/btrfs-image.c
index f2bbcc8..2a33a55 100644
--- a/btrfs-image.c
+++ b/btrfs-image.c
@@
On Mon, Jul 23, 2012 at 12:42:03AM -0600, Marc MERLIN wrote:
22 seconds for 15K files on an SSD is super slow and being 5 times
slower than a spinning disk with the same data.
What's going on?
Hi Marc,
The easiest way to figure out is with latencytop. I'd either run the
latencytop gui or
On Fri, 27 Jul 2012 16:04:14 +0530, Nageswara R Sastry wrote:
Check for the return value of 'open_ctree()' before dereferencing it.
Signed-off-by: Nageswara R Sastry nasas...@in.ibm.com
---
btrfs-image.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/btrfs-image.c b/btrfs-image.c
On Fri, 27 Jul 2012 13:09:53 +0200, Stefan Behrens wrote:
On Fri, 27 Jul 2012 16:04:14 +0530, Nageswara R Sastry wrote:
Check for the return value of 'open_ctree()' before dereferencing it.
Signed-off-by: Nageswara R Sastry nasas...@in.ibm.com
---
btrfs-image.c | 1 +
1 file changed, 1
On Thu, Jul 26, 2012 at 03:09:59PM -0600, David Sterba wrote:
On Wed, Jul 25, 2012 at 03:26:20PM +0200, Cyril B. wrote:
When creating a filesystem with devices of different sizes, the resulting
filesystem total size depends on the device order specified to mkfs. When
the smaller device
On Fri, Jul 27, 2012 at 04:52:21PM +0900, Hidetoshi Seto wrote:
(2012/07/26 15:57), Miao Xie wrote:
btrfs_abort_transaction(trans, root, ret);
goto fail;
}
@@ -1386,13 +1408,13 @@ int btrfs_commit_transaction(struct
btrfs_trans_handle *trans,
*/
My patch
04609add88ef8428d725de6ef60f46a3ff0dbc8e
introduced a regression where if you mkfs'ed a group of disks with different
sizes it limited the disks to the size of the first one that is specified.
This was not the intent of my patch, I only want it to limit the size based
on the -b option,
In iterate_inodes_from_logical() the error result from
extent_from_logical() is patched by mistake. Typically ENOENT is
patched to EINVAL because (-ENOENT BTRFS_EXTENT_FLAG_TREE_BLOCK)
evaluates to true.
---
fs/btrfs/backref.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi Alexander,
your solution is simple and elegant. I this this issue is solved now. Thanks!
Two minor issues:
1)
/*
* We need some special handling for inodes that get processed before the parent
* directory got created. See process_all_refs for details.
* This function does the check if we
On Fri, Jul 27, 2012 at 07:08:35AM -0400, Chris Mason wrote:
On Mon, Jul 23, 2012 at 12:42:03AM -0600, Marc MERLIN wrote:
22 seconds for 15K files on an SSD is super slow and being 5 times
slower than a spinning disk with the same data.
What's going on?
Hi Marc,
The easiest way to
13 matches
Mail list logo
