Re: [PATCH] btrfs: test if receive with qgroups corrupts metadata

On Mon, Oct 30, 2017 at 5:21 PM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: > > > On 2017年10月31日 06:32, Justin Maggard wrote: >> This test case does some concurrent send/receives with qgroups enabled. >> Currently (4.14-rc7) this usually results in btrfs check errors

[PATCH] btrfs: test for qgroup reservation leaks with prealloc

quota reservation leak on preallocated files" Signed-off-by: Justin Maggard <jmagg...@netgear.com> --- tests/btrfs/153 | 72 + tests/btrfs/153.out | 2 ++ tests/btrfs/group | 1 + 3 files changed, 75 insertions(+) create mode 100755

[PATCH] btrfs: test if receive with qgroups corrupts metadata

) as the culprit. Signed-off-by: Justin Maggard <jmagg...@netgear.com> --- tests/btrfs/152 | 102 tests/btrfs/152.out | 13 +++ tests/btrfs/group | 1 + 3 files changed, 116 insertions(+) create mode 100755 tests/btrfs/152 creat

[PATCH] btrfs: Fix quota reservation leak on preallocated files

we're left with both the qgroup and qgroup reservation accounting for the same space. This commit adds the missing btrfs_qgroup_free_data() call in the case of BTRFS_ORDERED_PREALLOC extents. Signed-off-by: Justin Maggard <jmagg...@netgear.com> --- fs/btrfs/inode.c | 2 ++ 1 file chan

Re: 4.11.6 / more corruption / root 15455 has a root item with a more recent gen (33682) compared to the found root node (0)

On Mon, Jul 31, 2017 at 2:17 PM, Marc MERLIN wrote: > On Tue, Aug 01, 2017 at 12:07:14AM +0300, Ivan Sizov wrote: >> 2017-07-09 10:57 GMT+03:00 Martin Steigerwald : >> > Hello Marc. >> > >> > Marc MERLIN - 08.07.17, 21:34: >> >> Sigh, >> >> >> >> This is now

Re: [PATCH] btrfs: test if receive with qgroups corrupts metadata

On Thu, Jul 20, 2017 at 4:44 PM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote: > On 2017年07月21日 07:03, Justin Maggard wrote: >> >> This test case does some concurrent send/receives with qgroups enabled. >> Currently (4.13-rc1) this usually results in btrfs check errors

[PATCH] btrfs: test if receive with qgroups corrupts metadata

This test case does some concurrent send/receives with qgroups enabled. Currently (4.13-rc1) this usually results in btrfs check errors, and often also results in a WARN_ON in record_root_in_trans(). Bisecting points to 6426c7ad697d (btrfs: qgroup: Fix qgroup accounting when creating snapshot) as

[PATCH] btrfs-progs: Fix an infinite loop in btrfs_next_bg

: Fix a bug causing btrfs-find-root to skip first chunk) Signed-off-by: Justin Maggard <jmagg...@netgear.com> --- volumes.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/volumes.c b/volumes.c index b350e259..8c0c10ce 100644 --- a/volumes.c +++ b/volumes.c @@ -1278,6 +1278,8

Global reserve values

I've run into a few systems where we start getting immediate ENOSPC errors on any operation as soon as we update to a recent kernel. These are all small filesystems (not MIXED), which should have had plenty of free metadata space but no unallocated chunks. I was able to trace this back to commit

Re: Btrfs progs pre-release 4.8.1-rc1

Hi David, On Fri, Oct 7, 2016 at 5:26 AM, David Sterba wrote: > Hi, > > another pre-release, just in case. I did a lot of build tests [1] and > automated a few things so the build failures should not happen again. > > ETA for the release is on Sunday (2016-10-09). Please test

Re: Btrfs progs release 4.8 (32bit builds broken)

Oops, I mistook the intent of that check. Please disregard. On Wed, Oct 5, 2016 at 3:25 PM, Justin Maggard <jmaggar...@gmail.com> wrote: > I saw a 32-bit build failure, but it looked like a legitimate bug, > unrelated to the compiler version. Here's the trivial fix: > > diff

Re: Btrfs progs release 4.8 (32bit builds broken)

I saw a 32-bit build failure, but it looked like a legitimate bug, unrelated to the compiler version. Here's the trivial fix: diff --git a/ioctl.h b/ioctl.h index a7235c0..26a3a5a 100644 --- a/ioctl.h +++ b/ioctl.h @@ -606,7 +606,7 @@ struct btrfs_ioctl_send_args { * Size of structure depends

[PATCH] btrfs-progs: fix memory leak with missing device

In read_one_chunk(), we may add an empty entry for a missing device. However, this entry wasn't being added to the dev_list, and so it never got freed. Signed-off-by: Justin Maggard <jmagg...@netgear.com> --- volumes.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/volumes.c b/vol

[PATCH] btrfs: test quota disable during quota rescan

This test case tests if we are able to disable quotas on a filesystem while a quota rescan is running. Up to now (4.3) this would result in a kernel NULL pointer dereference. Fixed by patch (btrfs: qgroup: fix quota disable during rescan). Signed-off-by: Justin Maggard <jmagg...@netgear.

[PATCH] btrfs: qgroup: fix quota disable during rescan

There's a race condition that leads to a NULL pointer dereference if you disable quotas while a quota rescan is running. To fix this, we just need to wait for the quota rescan worker to actually exit before tearing down the quota structures. Signed-off-by: Justin Maggard <jmagg...@netgear.

[PATCH v3] btrfs: qgroup: exit the rescan worker during umount

is good enough to allow me to unmount without crashing. v3: avoid more races by calling btrfs_qgroup_wait_for_completion() Signed-off-by: Justin Maggard <jmagg...@netgear.com> --- fs/btrfs/disk-io.c | 3 +++ fs/btrfs/qgroup.c | 9 ++--- 2 files changed, 9 insertions(+), 3 deletions(-)

[PATCH v2] btrfs: test unmount during quota rescan

This test case tests if we are able to unmount a filesystem while a quota rescan is running. Up to now (4.3) this would result in a kernel NULL pointer dereference. Fixed by patch (btrfs: qgroup: exit the rescan worker during umount). Signed-off-by: Justin Maggard <jmagg...@netgear.

Re: BTRFS with 8TB SMR drives

Sounds to me like this: https://bugzilla.kernel.org/show_bug.cgi?id=93581 On Mon, Oct 12, 2015 at 11:37 AM, Chris Murphy wrote: > I get a lot of these from both sdb and sdc > > Oct 11 23:00:03 cloud.warrenhughes.net kernel: sd 0:0:1:0: [sdb] > UNKNOWN(0x2003) Result:

Re: [PATCH v2] btrfs: qgroup: exit the rescan worker during umount

On Tue, Sep 22, 2015 at 7:45 AM, David Sterba <dste...@suse.cz> wrote: > On Wed, Sep 02, 2015 at 06:05:17PM -0700, Justin Maggard wrote: >> v2: Fix stupid error while making formatting changes... > > I haven't noticed any difference between the patches, what exactly did >

[PATCH] btrfs: qgroup: exit the rescan worker during umount

is good enough to allow me to unmount without crashing. Signed-off-by: Justin Maggard <jmagg...@netgear.com> --- fs/btrfs/qgroup.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index d904ee1..5bfcee9 100644 --- a/fs/btrfs/qg

[PATCH v2] btrfs: qgroup: exit the rescan worker during umount

, but that's a much larger change. This small change is good enough to allow me to unmount without crashing. Signed-off-by: Justin Maggard <jmagg...@netgear.com> --- fs/btrfs/qgroup.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/qgroup.c b/fs

Re: weird qgroup behavior, possible bug? btrfs-progs 4.1.2 and 4.1.5 kernel.

On Thu, Aug 13, 2015 at 11:22 AM, Suman Chakravartula su...@rockstor.com wrote: Hi, I use qgroups for subvolumes in Rockstor and have been noticing this behavior for a while(at least from 3.18 days). The behavior is that I get Disk quota exceeded errors before even hitting 70% usage. Here's

Re: Stability of Btrfs in Kernel 3.0

Yes, ReadyNAS btrfs is a long way away from 3.0 btrfs. And RN202/204 currently ship with a 3.12 kernel, and will be updated further soon. There are also firmware versions currently available in beta for all other hardware platforms using a much newer kernel, if you'd rather. But anyway, here's a

Re: Btrfs ENOSPC issue

On Sat, Apr 4, 2015 at 4:33 AM, Filipe David Manana fdman...@gmail.com wrote: On Sat, Apr 4, 2015 at 12:36 AM, Justin Maggard jmaggar...@gmail.com wrote: Hi, We're hitting a consistently reproducible ENOSPC condition with a simple test case: # truncate -s 1T btrfs.fs # mkfs.btrfs btrfs.fs

Btrfs ENOSPC issue

Hi, We're hitting a consistently reproducible ENOSPC condition with a simple test case: # truncate -s 1T btrfs.fs # mkfs.btrfs btrfs.fs # mount btrfs.fs /mnt/ # fallocate -l 1021G /mnt/fallocate # btrfs fi sync /mnt/ # dd if=/dev/zero of=/mnt/dd bs=1G # btrfs fi sync /mnt/ # rm /mnt/fallocate #

[PATCH] btrfs-progs: Fix btrfs fi show by uuid and label

Commit 8be2fff (btrfs-progs: apply realpath for btrfs fi show when mount point is given) changed the behavior of btrfs fi show to return an error if the call to realpath() failed. This broke the ability to specify a filesystem by uuid or label. So let's not consider a failed call to realpath()

[PATCH] btrfs-progs: add always option to restore's looping prompt

If you are using btrfs restore to try to recover a very large or fragmented file, you may encounter _lots_ of prompts requiring you to press 'y' to continue because we are looping a lot. Add the option to press 'a', to supress these prompts for the rest of the file. --- cmds-restore.c | 17

Re: How to skip looping a lot question of btrfs restore 3.15?

On Mon, Jul 28, 2014 at 3:35 PM, Karl-Philipp Richter krich...@posteo.de wrote: Hi together, In the current HEAD (3f11e516db629f7a662bfd6376231817b4e34cc9) of https://github.com/kdave/btrfs-progs.git (I assume this list is the right address because I got some hints to the project from here)

[PATCH v2] btrfs-progs: add always option to restore's looping prompt

If you are using btrfs restore to try to recover a very large or fragmented file, you may encounter _lots_ of prompts requiring you to press 'y' to continue because we are looping a lot. Add the option to press 'a', to supress these prompts for the rest of the file. Signed-off-by: Justin Maggard

Re: URGENT: my laptop's boot ssd btrfs crashed, what do you need off it?

On Wed, May 7, 2014 at 6:34 PM, Marc MERLIN m...@merlins.org wrote: Can btrfs restore be used to navigate the filesystem and look for files and patterns without dumping the entire filesystem, which I don't have room for? On recent versions of btrfs-progs, you can run btrfs restore with both

Re: Which companies are using Btrfs in production?

On Thu, Apr 24, 2014 at 6:34 AM, Daniel Lee longinu...@gmail.com wrote: On 04/23/2014 06:19 PM, Marc MERLIN wrote: Oh while we're at it, are there companies that can say they are using btrfs in production? Marc Netgear uses BTRFS as the filesystem in their refreshed ReadyNAS line. They

Space cache degradation

I've found that, after using some btrfs filesystems for some time, that the first large write after a reboot takes a very long time. So I went to work trying out different test cases to simplify reproduction of the issue, and I've got it down to just these steps: 1) mkfs.btrfs on a large-ish

[PATCH] btrfs: wake up transaction thread upon remount

will not wake up until the large interval has expired. This also causes the cleaner thread to stay sleeping, since it gets woken up by the transaction thread. Fix it by simply waking up the transaction thread during a remount. Signed-off-by: Justin Maggard jmaggar...@gmail.com --- fs/btrfs/super.c

[PATCH v2] btrfs-progs: add dry-run option to restore command

Sometimes it is useful to see what btrfs restore is going to do before provisioning enough external storage to restore onto. Add a dry-run option so we can see what files and paths are found by restore, without actually restoring any data. Signed-off-by: Justin Maggard jmaggar...@gmail.com

Re: [PATCH v2] btrfs-progs: add dry-run option to restore command

On Fri, Feb 14, 2014 at 10:59 AM, David Sterba dste...@suse.cz wrote: On Fri, Feb 14, 2014 at 10:40:47AM -0800, Justin Maggard wrote: Sometimes it is useful to see what btrfs restore is going to do before provisioning enough external storage to restore onto. Add a dry-run option so we can see

[PATCH] btrfs-progs: add dry-run option to restore command

Sometimes it is useful to see what btrfs restore is going to do before provisioning enough external storage to restore onto. Add a dry-run option so we can see what files and paths are found by restore, without actually restoring any data. --- cmds-restore.c | 14 -- 1 file changed,

[PATCH] btrfs: fix defrag 32-bit integer overflow

When defragging a very large file, the cluster variable can wrap its 32-bit signed int type and become negative, which eventually gets passed to btrfs_force_ra() as a very large unsigned long value. On 32-bit platforms, this eventually results in an Oops from the SLAB allocator. Change the

btrfsck crash, irreparable filesystem

I've been experimenting with btrfs for a few weeks now, and things have been going smoothly, until yesterday. Today my filesystem seems to be in an irrecoverable situation. I had btrfs running on a small (4GB) MD RAID5 array for a while, and things were working well. I started running out of