Please help me to contribute to btrfs project

Hi, I have used the btrfs filesystem in one of my projects and I have added a small feature to it. I feel that the same feature will be useful for others too. Hence I would like to contribute the same to open source. If everything works fine and this feature is not already added by somebody

Re: [PATCH 0/6 EARLY RFC] Btrfs: Get rid of whole page I/O.

Hello David, I looked at previous postings of this patchset, but haven't found what are the expected supported block sizes. I assume powers of two starting with 512b, until 64k. The earlier patchset posted by Chandra Seethraman was to get 4k blocksize to work with ppc64's 64k PAGE_SIZE. I

Re: How to handle a RAID5 arrawy with a failing drive?

Marc MERLIN posted on Sun, 16 Mar 2014 15:20:26 -0700 as excerpted: Do I have other options? (data is not important at all, I just want to learn how to deal with such a case with the current code) First just a note that you hijacked Mr Manana's patch thread. Replying to a post and changing

Re: [PATCH] Btrfs: fix a crash of clone with inline extents's split

On Mon, Mar 17, 2014 at 03:41:31PM +0100, David Sterba wrote: On Mon, Mar 10, 2014 at 06:56:07PM +0800, Liu Bo wrote: xfstests's btrfs/035 triggers a BUG_ON, which we use to detect the split of inline extents in __btrfs_drop_extents(). For inline extents, we cannot duplicate another

[PATCH 3/6] Btrfs-progs: fsck: deal with snapshot one by one when rebuilding extent tree

Previously, we deal with node block firstly and then leaf block which can maximize readahead. However, to rebuild extent tree, we need deal with snapshot one by one. This patch makes us deal with snapshot one by one if we need rebuild extent tree otherwise we drop into previous way.

[PATCH 1/6] Btrfs-progs: fsck: don't free @seen cache until we finish searching

@seen cache is used to avoid iterating same block more than once, and we can not free them until we have finished searching. Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com --- cmds-check.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/cmds-check.c

[PATCH 5/6] Btrfs-progs: fsck: reduce memory usage of extent record struct

Two changes: 1.use bit filed for @found_rec 2.u32 is enough to calculate duplicate extent number. Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com --- cmds-check.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/cmds-check.c b/cmds-check.c index

[PATCH 6/6] Btrfs-progs: fsck: fix wrong index in pick_next_pending()

Though all tree blocks have same size, we'd better use right index here. Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com --- cmds-check.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmds-check.c b/cmds-check.c index 34f8fa6..ebdb643 100644 --- a/cmds-check.c +++

[PATCH 2/6] Btrfs-progs: fsck: fix possible memory leaks in run_next_block()

We still need free allocated cache memory in case error happens. Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com --- cmds-check.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cmds-check.c b/cmds-check.c index c0b7f8c..b3f7e22 100644 --- a/cmds-check.c +++ b/cmds-check.c @@

[PATCH 4/6] Btrfs-progs: fsck: add ability to rebuild extent tree with snapshots

This patch makes us to rebuild a really corrupt extent tree with snapshots. To implement this, we have to verify whether a block is FULL BACKREF. This idea come from Josef Bacik: 1) We walk down the original tree, every eb we encounter has btrfs_header_owner(eb) == root-objectid. We add normal

Re: Please help me to contribute to btrfs project

Ajesh js coolajes...@gmail.com writes: Hi, I have used the btrfs filesystem in one of my projects and I have added a small feature to it. I feel that the same feature will be useful for others too. Hence I would like to contribute the same to open source. Excellent! If everything works

[PATCH v3] Btrfs: part 2, fix incremental send's decision to delay a dir move/rename

For an incremental send, fix the process of determining whether the directory inode we're currently processing needs to have its move/rename operation delayed. We were ignoring the fact that if the inode's new immediate ancestor has a higher inode number than ours but wasn't renamed/moved, we

[PATCH] Btrfs: remove unnecessary inode generation lookup in send

No need to search in the send tree for the generation number of the inode, we already have it in the recorded_ref structure passed to us. Signed-off-by: Filipe David Borba Manana fdman...@gmail.com --- fs/btrfs/send.c |9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git

[PATCH v3] xfstests: add test for btrfs send regarding directory moves/renames

Regression test for a btrfs incremental send issue where the kernel entered an infinite loop building a path string. This happened when either of the 2 following cases happened: 1) A directory was made a child of another directory which has a lower inode number and has a pending move/rename

Re: [PATCH 5/6] Btrfs-progs: fsck: reduce memory usage of extent record struct

On Tue, Mar 18, 2014 at 08:02:46PM +0800, Wang Shilong wrote: @@ -2742,7 +2742,10 @@ static int add_extent_rec(struct cache_tree *extent_cache, - rec-found_rec = extent_rec; + if (extent_rec) + rec-found_rec = 1; + else + rec-found_rec = 0; I've

Re: [PATCH 5/6] Btrfs-progs: fsck: reduce memory usage of extent record struct

On 03/19/2014 02:18 AM, David Sterba wrote: On Tue, Mar 18, 2014 at 08:02:46PM +0800, Wang Shilong wrote: @@ -2742,7 +2742,10 @@ static int add_extent_rec(struct cache_tree *extent_cache, - rec-found_rec = extent_rec; + if (extent_rec) + rec-found_rec = 1; +

Please advise on repair action

Hello, I have a simple btrfs located on a dm-crypt volume. I'm getting a general protection fault when I attempt to access a specific directory in Thunar file manager and in a Python program. The trace is attached for Thunar. btrfsck returns this: Checking filesystem on