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
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
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
. 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
as enabled? IIRC, you're a send/receive user.
The combination of quotas and btrfs receive can corrupt your
filesystem, as shown by the xfstest I sent to the list a little while
ago.
-Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
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
/333 again. Changing 3 to 2 works, but
then I'm just guessing. What would be appropriate?
-Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I'm using a 4.1 kernel built with the standard
armhf toolchain from Wheezy (gcc 4.7.2).
-Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
truct btrfs_ioctl_send_args) == 68
-Justin
On Wed, Oct 5, 2016 at 6:33 AM, David Sterba wrote:
> I got a report that the 32bit builds are broken. This seems to be caused
> by padding inserted (or not) into the structures and depends on a
> compiler version. The error messages may look cryptic,
kills whatever file is
giving it trouble and lets you know to restore it later.
http://serverfault.com/questions/746938/how-to-find-the-file-at-a-certain-btrfs-inode
On Tue, Aug 30, 2016 at 2:57 AM, henkjan gersen wrote:
> Thanks for the response Justin. This is exactly what I tried before
>
I converted my significantly smaller raid 5 array to raid 1 a little
less than a year ago now and I encountered some similar issues.
What i ended up doing was starting balance again and again with
slightly different arguments (usually thresholds for what blocks to
move) and eventually (a week or t
I don't think its possible to change raid levels without using a balance.
I'm not sure why you want to avoid a balance, its a background process that
will auto resume if interrupted. You don't have to leave your machine on for
weeks at a time and it shouldn't slow down an active application using
Do not run device delete, the issue is with parity and disk-failure
recovery, manually
incurring disk failure is a very bad idea.
I would suggest running a full backup of all the files before touching
anything and then
an in place conversion should be fine as its just reading from
undegraded disks
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
Here's some thoughts:
> Assume a CD sized (680MB) /boot
Some distros carry patches for grub that allow booting from Btrfs, so
no separate /boot file system is required. (Fedora does not; Ubuntu --
and therefore probably all Debians -- does.)
> perhaps a 200MB (?) sized EFI partition
Way bigger
> Mitchell wrote:
> With RAID10, there's still only 1 other copy, but the entire "original"
disk is mirrored to another one, right?
No, full disks are never mirrored in any configuration.
Here's how I understand Btrfs' non-parity redundancy profiles:
single: only a single instance of a file exis
name (i.e. btrfs receive
/var/media/backups/ not btrfs receive /var/media/backups/HOME).
Here's some send/receive commands that I've successfully used
recently. Maybe they'll point you in the right direction:
pull a RO snapshot from a remote system:
cd ~/ksp/backups
ssh 192.168.0.122
I have a btrfs filesystem spanning 3 drives. The metadata is using
raid1 (mirroring), but the data is using single, so no mirroring or
parity just spanning. For example:
mkfs.btrfs -m raid1 -d single /dev/sda /dev/sdb /dev/sdc
One of the drives, /dev/sdb, had a hardware failure before I could
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
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 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
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
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
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
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?
>
, 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
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
ince
qgroup support has undergone major surgery.
> I see that there are qgroup related patches going into 4.2. Are these
> problems addressed by them, perhaps?
>
Your issues are probably addressed in 4.2. If you really want to use
qgroups with 4.1, you may want to see if those patches help in your
case. (https://patchwork.kernel.org/project/linux-btrfs/list/?submitter=59741)
-Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ef-cache.h |only
74 files changed, 29498 insertions(+), 10648 deletions(-)
-Justin
On Thu, Jun 4, 2015 at 8:33 AM, Maximilian Eschenbacher
wrote:
> Hey Martin,
>
> On 04/06/2015 15:55:49, Martin Steigerwald wrote:
>>
>> BTRFS and Kernel 3.0?
>>
>> Unless its has
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
, device, &search_start, &hole_size)) {
btrfs_release_path(path);
goto again;
}
Thanks,
-Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
/var/media/backups/venus/home/"
Any idea what's happening? I can't find a single example online of
sending a delta over ssh.
Thanks,
Justin
On Thu, Oct 2, 2014 at 1:53 AM, Hugo Mills wrote:
> On Thu, Oct 02, 2014 at 12:05:39AM -0500, Justin Brown wrote:
>> I'm experi
;
Obviously, trying to delete the subvol directory fails too:
~$ sudo rm -rf /var/media/backups/venus/home/home-2014-10-01/
rm: cannot remove ‘/var/media/backups/venus/home/home-2014-10-01/’:
Operation not permitted
Is there anyway to delete this partial subvol?
Thanks,
Justin
--
To unsubscribe
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
t regards,
> Karl-P. Richter
>
I just posted the patch we use to get around that. Or, if you don't
want to build a modified btrfs-progs, you could always use the `yes`
command to press y for you.
-Justin
--
To unsubscribe from this list: send the line "unsubscribe lin
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 ++
O that was in progress
when the original failure occurred. Fortunately, it was all data that
could be recovered from other systems, and there wasn't any need to
troubleshoot the errors.
Thanks,
Justin
On Wed, May 28, 2014 at 3:40 PM, Chris Murphy wrote:
>
> On May 28, 2014, at 1
ended?
Thanks,
Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
earlier.
What can I do to recover this file system? I have another spare drive
that I can use if it's any help.
Thanks,
Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
th
the verbose and dry-run options to see what it finds, without actually
restoring anything.
-Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Debian derivative, but we
have pulled in lots of changes from Oracle UEK and the SUSE SLE11-SP3
kernel tree. And we do indeed run atop MD.
-Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
;s 100% reproducible, on various
kernel versions including 3.14-rc8. Is there anything I should
provide to help debug?
-Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
Absolutely. I'd like to know the answer to this, as 13 tera will take
a considerable amount of time to back up anywhere, assuming I find a
place. I'm considering rebuilding a smaller raid with newer drives
(it was originally built using 16 250 gig western digital drives, it's
about eleven years o
ear of things breaking, but
both have been reading from it without issue other than the noticeable
impact in performance balance seems to be having. Thanks for the
help.
-Justin
On Fri, Feb 28, 2014 at 12:26 AM, Chris Murphy wrote:
>
> On Feb 27, 2014, at 11:13 PM, Chris Murphy wro
sing space
assuming it's possible? Any help is most appreciated.
-Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the updated
btrfs-progs, and while it hasn't uncovered any errors yet, the scrub
won't be finished until tomorrow. (I know that won't do anything
besides indicate some kind of transient error or a problem with
0.20-rc1.) After that, I'll give balance a try to attempt to fix
rrected and uncorrectable errors that occur during normal
operation? I guess something similar to `mdadm -D`.
* It seems like this type of error shouldn't happen on RAID6 as there
should be enough information to recover between the data, p parity,
and q parity. Is this just an implementation l
relying on autodefrag to work).
It should simply be a matter of: Who manages the storage decides how it
should be configured and whether not to do CoW is an aspect of
configuration.
Regards,
justin
On 21-02-14 17:55, Chris Murphy wrote:
Use case is a user who doesn't kn
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
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
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
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,
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
I tried to suspend a computer running linux 3.11.1 while a scrub was
going, and I got this:
Oct 2 20:15:12 caper kernel: [ 1237.472716] PM: Preparing system for mem sleep
Oct 2 20:15:12 caper kernel: [ 1237.472856] Freezing user space processes ...
Oct 2 20:15:12 caper kernel: [ 1257.474848] Fr
Hi,
I've been having some trouble with one of my computers recently that
I'm currently blaming on btrfs.
At first, I thought the computer had a hardware fault, since it tended
to just mysteriously hard-lockup a few times per day. Usually, it
would hard-lockup with the GUI, and I was unable to ge
I would try mounting it. That symptom
has now gone away after running a couple more times, but the
filesystem is still unmountable unless I mount read-only.
So, where should I go from here? Make btrfs-image files of the base
(or all) devs for this fs for someone to look at? Try btrfsck
--init-cs
dm device. https://github.com/facebook/flashcache
Regards,
--Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
hardening all of it's internals and backends
before getting around to these "extra" project facilities.
Regards,
justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: "Justin P. Mattock"
The patch below removes an extra semicolon.
Note: I have not compile tested this patch, so am unsure if this breaks things.
Signed-off-by: Justin P. Mattock
CC: Chris Mason
CC: linux-btrfs@vger.kernel.org
---
fs/btrfs/free-space-cache.c |2 +-
1 fil
'll try the
bleeding edge git kernel (which appears to have this patch by now) and
see if the problem goes away.
Justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
is report proves useful for finding the bug responsible for this. If
complete logs, details about versions used or steps taken, diagnostic output
from system commands, or particular pieces of the disk image would be helpful
for debugging this problem, I can provide them.
Thanks,
Justin
--
To unsub
problem per patch
> if possible and practicle.
> --Mark
I Think Tsutomu's point was more that you've changed the behavior from a
BUG() on error to silently ignoring the error.
So you should at least add 'BUG_ON(ERR_PTR(...) == -ENOMEM)' in the
callers to maintain the current behavior while still pushing the check
up the call chain.
Regards,
justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
sk failure.
Regards,
justin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
x27;d like to recover it if possible. If
there are absolutely no recovery options, a note on the wiki about
which failures are nonrecoverable might be good.
Thanks for the continuous improvements.
*Justin Chudgar* - Weed, CA 96094
On 01/08/2011 03:42 AM, Fajar A. Nugraha wrote:
> On Sat, Jan 8,
vailable.
So the real strength is that corruptions are more likely only to impact
a small subset of the filesystem and that different objects can have
different amount of redundancy. So 'raid1' for metadata and other very
important files, no raid for unimportant data and raid5/6 fo
hout recompiling
the kernel.
Regards,
justin
On 27/07/10 22:30, Dave Cundiff wrote:
> Hello,
>
> I installed the git repo kernel and added some debug to the ENOSPC
> returns. Unfortunately its still failing. If it helps any its bombing
> out in btrfs_check_data_free_spa
Hi,
FYI:
http://www.netsplit.com/2010/05/14/btrfs-by-default-in-maverick/
from the blog entry:
"The btrfs upstream must be happy with the idea"
--
JS
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo
Awesome.
Has there been a lot of testing with RAID + TRIM setups?
-- Original Message --
From: Josef Bacik
To: Justin
Cc: linux-btrfs@vger.kernel.org
Subject: Re: TRIM + RAID Support?
Date: Tue, 4 May 2010 11:58:35 -0400
On Tue, May 04, 2010 at 03:53:17PM +, Justin wrote
king: When btrfs is in RAID
mode, does it still pass the TRIM commands to the SSD?
Justin
Penny Stock Jumping 2000%
Sign up to the #1 voted penny stock newsletter for free today!
http://thirdpartyoffers.netzero.n
Btrfs Btrfs v0.19
I'm running SysRescueCD-1.5.2-b6 with the 2.6.33.02 kernel.
Anything I should run? Any other info that might be helpful?
Justin
A Reverse Mortgage?
Near 70? Find out how much money you can get f
As far as I know TRIM was enabled. I didn't forcibly disable it and I'm under
the assumption that btrfs enables it when an SSD is detected.
-- Original Message --
From: Chris Mason
To: Justin
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs Bug?
Date: Fri, 9 Apr
itself).
For future reference, how would I go about getting an image of the drive
without being able to use btrfs-image?
Justin
Car Insurance 18.29/Month
Get car insurance for as low as $18.29 a month.
http://thirdpartyoffers
76 matches
Mail list logo
