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
---
volumes.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/volumes.c b/volumes.c
index ccfa732..b5
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 o
Oops, I mistook the intent of that check. Please disregard.
On Wed, Oct 5, 2016 at 3:25 PM, Justin Maggard 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 --git a/ioctl.h b/ioctl.
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 and report any new
On Thu, Aug 13, 2015 at 11:22 AM, Suman Chakravartula
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
> a simple de
ge is good enough to allow me to unmount without
crashing.
Signed-off-by: Justin Maggard
---
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/qgroup.c
+++ b/fs/btrfs/qgr
, 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
---
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 d9
On Tue, Sep 22, 2015 at 7:45 AM, David Sterba 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
> you change?
>
This test case tests if we are able to unmount a filesystem while
a quota rescan is running. Up to now (4.3-rc4) this would result
in a kernel NULL pointer dereference.
Signed-off-by: Justin Maggard
---
tests/btrfs/104 | 85 +
tests/btrfs
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: hostbyte=0x00 driverbyte=0x08
ge 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
---
fs/btrfs/disk-io.c | 3 +++
fs/btrfs/qgroup.c | 9 ++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs
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
---
tests/btrfs/114 | 61
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
---
fs/btrfs/qgr
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
---
tests/btrfs/115
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 a
olume: Fix a bug causing btrfs-find-root to skip
first chunk)
Signed-off-by: Justin Maggard
---
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 @@ int btrfs_next_bg(s
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
On Thu, Jul 20, 2017 at 4:44 PM, Qu Wenruo 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, and
>> often a
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 the 3rd filesystem I have (on 3 differe
. So 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
---
fs/btrfs/inode.c | 2 ++
1 file changed, 2 insertions(+)
di
the culprit.
Signed-off-by: Justin Maggard
---
tests/btrfs/152 | 102
tests/btrfs/152.out | 13 +++
tests/btrfs/group | 1 +
3 files changed, 116 insertions(+)
create mode 100755 tests/btrfs/152
create mode 100644 tests/btrfs
quota reservation
leak on preallocated files"
Signed-off-by: Justin Maggard
---
tests/btrfs/153 | 72 +
tests/btrfs/153.out | 2 ++
tests/btrfs/group | 1 +
3 files changed, 75 insertions(+)
create mode 100755 tests/btrfs/153
create m
On Mon, Oct 30, 2017 at 5:21 PM, Qu Wenruo 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, and
>> often a
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
# b
On Sat, Apr 4, 2015 at 4:33 AM, Filipe David Manana wrote:
> On Sat, Apr 4, 2015 at 12:36 AM, Justin Maggard wrote:
>> Hi,
>>
>> We're hitting a consistently reproducible ENOSPC condition with a
>> simple test case:
>>
>> # truncate -s 1T btrfs.fs
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 d
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 spa
On Wed, May 7, 2014 at 6:34 PM, Marc MERLIN 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
the verbose and
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 ++
On Mon, Jul 28, 2014 at 3:35 PM, Karl-Philipp Richter
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) the
> btrfs resto
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-of
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 cluste
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,
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
---
cmds-restore.c | 17
On Fri, Feb 14, 2014 at 10:59 AM, David Sterba 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 opti
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
---
fs/btrfs/super.c |1 +
1 file
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 devi
On Thu, Apr 24, 2014 at 6:34 AM, Daniel Lee 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 apparently use
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() as
39 matches
Mail list logo
