[PATCH RFC] btrfs-progs: Show backtrace on BUGs

check[0x804f061] btrfsck: extent_io.c:612: free_extent_buffer: Assertion `!(eb-flags 1)' failed. enabling repair mode Checking filesystem on /dev/sdb2 UUID: a53121ee-679f-4241-bb44-ceb5a1a7beb7 Now it's much clear that there's something wrong around alloc_extent_buffer. Signed-off-by: Naohiro

[PATCH] btrfs-progs: Do not free dirty extent buffer

free_some_buffer() should not free dirty extent buffers. They should be left for later commit. Signed-off-by: Naohiro Aota na...@elisp.net --- extent_io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extent_io.c b/extent_io.c index a127e54..8a668be 100644 --- a/extent_io.c

Re: [PATCH] btrfs-progs: Do not free dirty extent buffer

Hi, Filipe David Manana fdman...@gmail.com writes: On Thu, Aug 21, 2014 at 1:07 PM, Naohiro Aota na...@elisp.net wrote: free_some_buffer() should not free dirty extent buffers. They should be left for later commit. Signed-off-by: Naohiro Aota na...@elisp.net --- extent_io.c | 2 +- 1

btrfs-progs: initial reference count of extent buffer is correct?

Hi, list I'm having trouble with my btrfs FS recently and running btrfs check to try to fix the FS. Unfortunately, it aborted with: btrfsck: root-tree.c:81: btrfs_update_root: Assertion `!(ret != 0)' failed. It means that extent tree root is not found in tree root tree! Then I added

[PATCH] btrfs-progs: do not reclaim extent buffer

() to catch non-free'ed buffers properly. Signed-off-by: Naohiro Aota na...@elisp.net --- extent_io.c | 37 +++-- 1 file changed, 3 insertions(+), 34 deletions(-) diff --git a/extent_io.c b/extent_io.c index 1df377d..425af8a 100644 --- a/extent_io.c +++ b/extent_io.c

[PATCH] btrfs: clear bio reference after submit_one_bio()

${dmesgout} exit 1 fi done umount $directory exit 0 Signed-off-by: Naohiro Aota na...@elisp.net --- fs/btrfs/extent_io.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 4ebabd2..4421161 100644

[PATCH] btrfs: tweak key advancing condition

() to take a lot of time scanning all the leaf a blocks one by one. This commit fix the problem using standard way of key comparison: btrfs_comp_cpu_keys() Signed-off-by: Naohiro Aota na...@elisp.net --- fs/btrfs/ioctl.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/fs

[PATCH][RESEND] btrfs: fix search key advancing condition

() to take unexpectedly long time scanning all the leaf a blocks one by one. This commit fix the problem using standard way of key comparison: btrfs_comp_cpu_keys() Signed-off-by: Naohiro Aota na...@elisp.net --- fs/btrfs/ioctl.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions

Re: [PATCH][RESEND] btrfs: fix search key advancing condition

Hello, list. Could any one take a look at on this? I believe this is a issue slowing down ioctl(BTRFS_IOC_TREE_SEARCH) if the target key is missing. On Tue, Jun 30, 2015 at 11:25 AM, Naohiro Aota na...@elisp.net wrote: The search key advancing condition used in copy_to_sk() is loose. It can

[PATCH 1/3] btrfs-progs: test: umount if confirmation failed

When a check in check_inode() failed, the test should umount test target file system. This commit add clean up umount line in failure path. Signed-off-by: Naohiro Aota <na...@elisp.net> --- tests/fsck-tests/012-leaf-corruption/test.sh | 4 1 file changed, 4 insertions(+) diff --git a

[PATCH 2/3] btrfs-progs: properly reset nlink of multi-linked file

file links. Signed-off-by: Naohiro Aota <na...@elisp.net> --- cmds-check.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/cmds-check.c b/cmds-check.c index 6a0b50a..11ff3fe 100644 --- a/cmds-check.c +++ b/cmds-check.c @@ -810,7 +810,8 @@ static void maybe_free_ino

[PATCH 0/3] btrfs-progs: fix file restore to lost+found bug

This series address an issue of btrfsck to restore infinite number of same file into `lost+found' directory. The issue occur on a file which is linked from two different directory A and B. If links from dir A is corrupted and links from dir B is kept valid, btrfsck won't stop creating a file in

Re: [PATCH 0/3] btrfs-progs: fix file restore to lost+found bug

On Sat, Dec 5, 2015 at 10:35 AM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: > > > On 12/04/2015 01:37 PM, Naohiro Aota wrote: >> >> This series address an issue of btrfsck to restore infinite number of >> same file into `lost+found' directory. The issue occur on a

Re: [PATCH 1/3] btrfs-progs: test: umount if confirmation failed

On Tue, Dec 8, 2015 at 12:33 AM, David Sterba <dste...@suse.cz> wrote: > On Fri, Dec 04, 2015 at 02:37:25PM +0900, Naohiro Aota wrote: >> When a check in check_inode() failed, the test should umount test target >> file system. This commit add clean up umount line in failu

Re: [PATCH 0/3] btrfs-progs: fix file restore to lost+found bug

On Tue, Dec 8, 2015 at 12:35 AM, David Sterba <dste...@suse.cz> wrote: > On Mon, Dec 07, 2015 at 11:59:19AM +0900, Naohiro Aota wrote: >> > But I only see the first 2 patches in maillist... >> > The last test case seems missing? >> >> Maybe, the last patch

Re: [PATCH v2] Btrfs: Show a warning message if one of objectid reaches its highest value

2016-03-07 12:05 GMT+09:00 Satoru Takeuchi : > - It's better to show a warning message for the exceptional case > that one of objectid (in most case, inode number) reaches its > highest value. Show this message only once to avoid filling > dmesg with it. > -

[PATCH] btrfs: let btrfs_delete_unused_bgs() to clean relocated bgs

quot; flag set (to keep balancing BG intact). On the other hand, btrfs cannot drop "ro" flag here to prevent additional writes. So this patch make use of "removed" flag. btrfs_delete_unused_bgs() now detect the flag to distinguish whether a read-only BG is relocating or not

Re: [PATCH] btrfs: let btrfs_delete_unused_bgs() to clean relocated bgs

2016-09-02 (金) の 09:35 -0400 に Josef Bacik さんは書きました: > On 09/02/2016 03:46 AM, Naohiro Aota wrote: > > > > Currently, btrfs_relocate_chunk() is removing relocated BG by > > itself. But > > the work can be done by btrfs_delete_unused_bgs() (and it's better > >

[PATCH 1/2] btrfs-progs: build: generate all dependency files

dependency file building rules. Signed-off-by: Naohiro Aota <naohiro.a...@wdc.com> --- Makefile |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index a114eca..c00dff6 100644 --- a/Makefile +++ b/Makefile @@ -121,6 +121,9 @@ libbtrfs_header

[PATCH 2/2] btrfs: build: omit unnecessary -MD flag

uot;-MM" flag. I guess we can drop it. Signed-off-by: Naohiro Aota <naohiro.a...@wdc.com> --- Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c00dff6..60c802a 100644 --- a/Makefile +++ b/Makefile @@ -264,7 +264,7 @@ else endif

Re: [PATCH 1/2] btrfs-progs: build: generate all dependency files

On 2017年09月14日 21:41, David Sterba wrote: > On Thu, Sep 14, 2017 at 07:10:46PM +0900, Naohiro Aota wrote: >> We're missing several dependency files like: >> >> $ diff -u <(find -name '*.o'|cut -d. -f2|sort) <(find -name '*.o.d'|cut -d. >> -f2|sort) >>-

Re: [PATCH] btrfs: fix max chunk size on dup

teresting code puzzle... :) > > On 10/10/2017 07:22 PM, Hans van Kranenburg wrote: >> On 10/10/2017 07:07 PM, Hans van Kranenburg wrote: >>> On 10/10/2017 01:31 PM, David Sterba wrote: >>>> Hi, >>>> >>>> On Fri, Sep 29, 2017 at 04:20:51PM +09

Re: [PATCH] btrfs: set include path relatively

2017-10-12 21:38 GMT+09:00 David Sterba <dste...@suse.cz>: > On Thu, Oct 12, 2017 at 11:22:24AM +0900, Naohiro Aota wrote: >> Currently, gcc is passed the include directory with full path. As a result, >> dependency files (*.o.d) also record the full path at the build ti

[PATCH] btrfs: propagate error to btrfs_cmp_data_prepare caller

ertion). This patch just return the error as is so that the caller stop the process. Signed-off-by: Naohiro Aota <naohiro.a...@wdc.com> Fixes: f441460202cb ("btrfs: fix deadlock with extent-same and readpage") Cc: <sta...@vger.kernel.org> # 4.2 --- fs/btrfs/ioctl.c |2 +-

Re: [PATCH 1/2] btrfs: clear ordered flag on cleaning up ordered extents

On 2017年09月08日 03:25, David Sterba wrote: > On Fri, Sep 01, 2017 at 06:59:49PM +0800, Qu Wenruo wrote: >> On 2017年09月01日 16:58, Naohiro Aota wrote: >>> commit 524272607e88 ("btrfs: Handle delalloc error correctly to avoid >>> ordered extent hang") int

[PATCH] btrfs: fix max chunk size on dup

1 on DUP, it disallows the block group to have > 128MB. What missing here is "dev_stripes". Proper logical space used by the block group is "stripe_size * data_stripes / dev_stripes". Tweak the equations to use the right value. Signed-off-by: Naohiro Aota <naohiro.a...

[PATCH] btrfs: fix NULL pointer dereference from free_reloc_roots()

__del_reloc_root should be called before freeing up reloc_root->node. If not, calling __del_reloc_root() dereference reloc_root->node, causing the system BUG. Signed-off-by: Naohiro Aota <naohiro.a...@wdc.com> --- fs/btrfs/relocation.c |2 +- 1 file changed, 1 insertion(+)

[PATCH 2/2] btrfs: finish ordered extent cleaning if no progress is found

ts. Since the ordered extents are created from head to tail, we can stop the search if there are no offset progress. Signed-off-by: Naohiro Aota <naohiro.a...@wdc.com> Fixes: 524272607e88 ("btrfs: Handle delalloc error correctly to avoid ordered extent hang") Cc: <sta...@vger.ker

[PATCH 1/2] btrfs: clear ordered flag on cleaning up ordered extents

e. Signed-off-by: Naohiro Aota <naohiro.a...@wdc.com> Fixes: 524272607e88 ("btrfs: Handle delalloc error correctly to avoid ordered extent hang") Cc: <sta...@vger.kernel.org> # 4.12 --- fs/btrfs/inode.c | 12 1 file changed, 12 insertions(+) diff --git a/fs/

[PATCH] btrfs: set include path relatively

way what other program using autotools e.g. e2fsprogs is doing: $ grep top_builddir Makefile top_builddir = . CPPFLAGS = -I. -I$(top_builddir)/lib -I$(top_srcdir)/lib BUILD_CFLAGS = -g -O2 -I. -I$(top_builddir)/lib -I$(top_srcdir)/lib -DHAVE_CONFIG_H Signed-off-by: Naohiro Aota <na...@elisp.

[PATCH] btrfs: revert fs_devices state on error of btrfs_init_new_device()

later use-after-free bug. Error path also messes the things like ->num_devices. While they go backs to the original value by unscanning btrfs devices, it is safe to revert them here. Fixes: 79787eaab461 ("btrfs: replace many BUG_ONs with proper error handling") Signed-off-by: Naohiro

[PATCH] btrfs: fix use-after-free of cmp workspace pages

s to avoid use-after-free. Fixes: 67b07bd4bec5 ("Btrfs: reuse cmp workspace in EXTENT_SAME ioctl") Signed-off-by: Naohiro Aota --- fs/btrfs/ioctl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 43ecbe620dea..b077544b5232 100644 --- a/fs/bt