On 21/05/12 15:22, Marc MERLIN wrote:
Have the free space problems been fixed in 3.3.x or is the 3.4.x branch
better or should I stay with 3.2.x for safety?
There have been some fixes pushed back from the development tree into
the stable tree for 3.3.x (for the first time in btrfs's history I
Hi Tsutomu,
On Mon, May 21, 2012 at 01:44 (+0200), Tsutomu Itoh wrote:
+static noinline int
+__tree_mod_log_insert(struct btrfs_fs_info *fs_info, struct tree_mod_elem
*tm)
+{
+struct rb_root *tm_root;
+struct rb_node **new;
+struct rb_node *parent = NULL;
+struct
[cc to the list]
On Sun, May 20, 2012 at 19:00 (+0200), Andrei Popa wrote:
For testing qgroup, the patches for btrfs-progs sent last year are ok ?
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg12724.html
Yes, that's the link to the patches required. Sorry for missing it in my
Hi Liu,
do you think that this should not happen? I see this all the time, and
I am not doing any stress tests. Just creating a file and writing some
data at different offsets, to create holes in the file offset space.
btrfsck does not produce any errors.
I am using kernel 3.3.6 and btrfs-progrs
On 05/21/2012 04:20 PM, Alex Lyakas wrote:
Hi Liu,
do you think that this should not happen? I see this all the time, and
I am not doing any stress tests. Just creating a file and writing some
data at different offsets, to create holes in the file offset space.
btrfsck does not produce any
Hi Liu,
thanks for the clarifications.
I did not understand the dd example of yours, though.
So for the following situation:
item 23 key (266 EXTENT_DATA 4096) itemoff 2269 itemsize 53
extent data disk byte 0 nr 0
extent data offset 0 nr 4096 ram 8192
On Mon, 21 May 2012 13:34:05 +0800, Miao Xie wrote:
On Fri, 18 May 2012 14:52:07 +0200, David Sterba wrote:
On Thu, May 17, 2012 at 07:58:21PM +0800, Miao Xie wrote:
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1151,6 +1151,8 @@ static int btrfs_remount(struct super_block *sb, int
On 21.05.2012 07:34, Miao Xie wrote:
On Fri, 18 May 2012 14:52:07 +0200, David Sterba wrote:
On Thu, May 17, 2012 at 07:58:21PM +0800, Miao Xie wrote:
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1151,6 +1151,8 @@ static int btrfs_remount(struct super_block *sb, int
*flags, char *data)
Hi Alex,
On Fri, May 18, 2012 at 13:21 (+0200), Alex Lyakas wrote:
Some general questions on the ctree code.
# I saw that slot==0 is special. My understanding is that btrfs
maintains the property that the parent of each node/leaf has a key
pointing to that node/leaf, which must be equal to
On Fri, 18 May 2012 13:57:19 +0200, David Sterba wrote:
On Wed, May 16, 2012 at 06:50:47PM +0200, Stefan Behrens wrote:
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -823,6 +823,26 @@ struct btrfs_csum_item {
u8 csum;
} __attribute__ ((__packed__));
+struct
Currently btrfs has a limitation on the maximum number of hard links an
inode can have. Specifically, links are stored in an array of ref
items:
struct btrfs_inode_ref {
__le64 index;
__le16 name_len;
/* name goes here */
} __attribute__ ((__packed__));
The ref arrays are
From: Mark Fasheh mfas...@suse.com
The iterate_irefs in backref.c is used to build path components from inode
refs. This patch adds code to iterate extended refs as well.
I had modify the callback function signature to abstract out some of the
differences between ref structures. iref_to_path()
From: Mark Fasheh mfas...@suse.com
Teach tree-log.c about extended inode refs. In particular, we have to adjust
the behavior of inode ref replay as well as log tree recovery to account for
the existence of extended refs.
Signed-off-by: Mark Fasheh mfas...@suse.de
---
fs/btrfs/backref.c | 68
On 05/21/2012 06:05 PM, Alex Lyakas wrote:
Hi Liu,
thanks for the clarifications.
I did not understand the dd example of yours, though.
So for the following situation:
item 23 key (266 EXTENT_DATA 4096) itemoff 2269 itemsize 53
extent data disk byte 0 nr 0
14 matches
Mail list logo
