[Bug] btrfs-progs v4.3.1, mkfs.btrfs manpage, profiles table missing raid1

As in the title... The btrfs-progs v4.3.1 mkfs.btrfs manpage has a quite nice profiles table listing the various profiles, single/dup/raid0/raid10/raid5/raid6. It's missing raid1. =:^( Also, it calls raid5/6 "copies" rather than "parity". Perhaps add another column for parity, change the

[PATCH v3] Btrfs: fix race when finishing dev replace leading to transaction abort

From: Filipe Manana During the final phase of a device replace operation, I ran into a transaction abort that resulted in the following trace: [23919.655368] WARNING: CPU: 10 PID: 30175 at fs/btrfs/extent-tree.c:9843 btrfs_create_pending_block_groups+0x15e/0x1ab [btrfs]()

Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?

On Fri, Nov 20, 2015 at 08:21:31AM -0500, Austin S Hemmelgarn wrote: > On 2015-11-20 06:39, Dmitry Katsubo wrote: > >If I may add: > > > >Information for "System" > > > > System, DUP: total=32.00MiB, used=16.00KiB > > > >is also quite technical, as for end user system = metadata (one can call >

Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?

On 2015-11-20 08:27, Hugo Mills wrote: On Fri, Nov 20, 2015 at 08:21:31AM -0500, Austin S Hemmelgarn wrote: On 2015-11-20 06:39, Dmitry Katsubo wrote: If I may add: Information for "System" System, DUP: total=32.00MiB, used=16.00KiB is also quite technical, as for end user system =

Re: Self-destruct of btrfs RAID6 array

On 2015-11-19 23:11, Paul Loewenstein wrote: I have just had an apparently catastrophic collapse of a large RAID6 array. I was hoping that the dual-redundancy of a RAID6 array would compensate for having no backup media large enough to back it up! Duncan already did a really good job of

Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?

Many thanks to Duncan for such a verbose clarification. I am thinking about another parallel similar to SimSity, and that is memory management in virtual machines like Java. If heap is full, it does not really mean that there is no free memory. In this case JVM forces garbage collector and if

Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?

On 2015-11-20 06:39, Dmitry Katsubo wrote: If I may add: Information for "System" System, DUP: total=32.00MiB, used=16.00KiB is also quite technical, as for end user system = metadata (one can call it "filesystem metadata" perhaps). For simplicity the numbers can be added to "Metadata"

[PATCH v4] Btrfs: fix race when finishing dev replace leading to transaction abort

From: Filipe Manana During the final phase of a device replace operation, I ran into a transaction abort that resulted in the following trace: [23919.655368] WARNING: CPU: 10 PID: 30175 at fs/btrfs/extent-tree.c:9843 btrfs_create_pending_block_groups+0x15e/0x1ab [btrfs]()

[PATCH] Btrfs: fix race when finishing dev replace leading to transaction abort

From: Filipe Manana During the final phase of a device replace operation, I ran into a transaction abort that resulted in the following trace: [23919.655368] WARNING: CPU: 10 PID: 30175 at fs/btrfs/extent-tree.c:9843 btrfs_create_pending_block_groups+0x15e/0x1ab [btrfs]()

[PATCH v2] Btrfs: fix race when finishing dev replace leading to transaction abort

From: Filipe Manana During the final phase of a device replace operation, I ran into a transaction abort that resulted in the following trace: [23919.655368] WARNING: CPU: 10 PID: 30175 at fs/btrfs/extent-tree.c:9843 btrfs_create_pending_block_groups+0x15e/0x1ab [btrfs]()

Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?

Am 20.11.2015 um 04:14 schrieb Duncan: > Meta-comment: > > Apparently that attribution should actually be to Hugo Mills. I've no > idea what went wrong, but at least here as received from gmane.org, the > from header really does say linux-btrfs.tebulin, so something obviously > bugged out

Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?

If I may add: Information for "System" System, DUP: total=32.00MiB, used=16.00KiB is also quite technical, as for end user system = metadata (one can call it "filesystem metadata" perhaps). For simplicity the numbers can be added to "Metadata" thus eliminating that line as well. For those

Re: [PATCH] Btrfs: fix a bug of sleeping in atomic context

On Thu, Nov 19, 2015 at 05:49:37PM -0800, Liu Bo wrote: > while xfstesting, this bug[1] is spotted by both btrfs/061 and btrfs/063, > so those sub-stripe writes are gatherred into plug callback list and > hopefully we can have a full stripe writes. > > However, while processing these plugged

Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?

On 2015-11-19 21:11, Duncan wrote: Austin S Hemmelgarn posted on Thu, 19 Nov 2015 07:28:34 -0500 as excerpted: (having all updates installed on Ubuntu doesn't really count in this case, they're pretty bad sometimes about not properly tracking upstream development[)] No kidding. I'm involved

Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?

linux-btrfs.tebulin posted on Fri, 20 Nov 2015 10:38:33 +0100 as excerpted: > Am 20.11.2015 um 04:14 schrieb Duncan: >> Meta-comment: >> >> Apparently that attribution should actually be to Hugo Mills. I've no >> idea what went wrong, but at least here as received from gmane.org, the >> from

Re: Kernel 3.19 and still "disk full" even though 'btrfs fi df" reports enough room left?

On 2015-11-20 14:52, Austin S Hemmelgarn wrote: > On 2015-11-20 08:27, Hugo Mills wrote: >> On Fri, Nov 20, 2015 at 08:21:31AM -0500, Austin S Hemmelgarn wrote: >>> On 2015-11-20 06:39, Dmitry Katsubo wrote: For those power users who really want to see the tiny details like "System" and

Re: [PATCH] Fix balance regression in 4.4-rc

On Tue, Nov 17, 2015 at 11:29 AM, Holger Hoffstätte wrote: > There's a regression in 4.4-rc since commit bc3094673f22 > (btrfs: extend balance filter usage to take minimum and maximum) in that > existing (non-ranged) balance with -dusage=x no longer works; all

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On Fri, 2015-11-20 at 17:23 +0100, Laurent Bonnaud wrote: > So here is the output of "btrfs-debug-tree -t 2 " in case it may Gosh... 15M via mail?! o.O Anyway an update from my side... I've copied all data from the fs in question to a new btrfs,... done under Linux 4.2.6 and btrfs-progs v4.3. No

Re: [Enhancement] ... and please rename "raid1" to something better

On Fri, 2015-11-20 at 11:05 +, Duncan wrote: > It's missing raid1. =:^( speaking of which... Wouldn't the developers consider to rename raid1 to something more correct? E.g. replicas2 or dup or whatever. RAID1 has ever had the meaning of mirrored devices and the closest to this in btrfs

Re: [PATCH] Btrfs: fix a bug of sleeping in atomic context

On Fri, Nov 20, 2015 at 09:57:49AM -0800, Liu Bo wrote: > On Fri, Nov 20, 2015 at 08:13:58AM -0500, Chris Mason wrote: > > On Thu, Nov 19, 2015 at 05:49:37PM -0800, Liu Bo wrote: > > > while xfstesting, this bug[1] is spotted by both btrfs/061 and btrfs/063, > > > so those sub-stripe writes are

Re: [PATCH] Btrfs: fix a bug of sleeping in atomic context

On 11/20/2015 06:13 AM, Chris Mason wrote: On Thu, Nov 19, 2015 at 05:49:37PM -0800, Liu Bo wrote: while xfstesting, this bug[1] is spotted by both btrfs/061 and btrfs/063, so those sub-stripe writes are gatherred into plug callback list and hopefully we can have a full stripe writes. However,

Re: [PATCH for 4.4] btrfs: fix rcu warning during device replace

Thanks David. Checked other places it seems to be fine. My oversight on the rcu usage part. Thanks. Reviewed-by: Anand Jain On 11/19/2015 06:35 PM, David Sterba wrote: The test btrfs/011 triggers a rcu warning === [ INFO: suspicious RCU

4.2.6: livelock in recovery (free_reloc_roots)?

Dear list, I am (still) trying to recover a RAID1 that can only be mounted recovery,degraded,ro. I experienced an issue that might be interesting for you: I tried to mount the file system rw,recovery and the kernel ended up burning one core (and only one specific core, never scheduled to another

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On 11/21/2015 03:24 AM, Christoph Anton Mitterer wrote: On Fri, 2015-11-20 at 17:23 +0100, Laurent Bonnaud wrote: So here is the output of "btrfs-debug-tree -t 2 " in case it may Gosh... 15M via mail?! o.O Anyway an update from my side... I've copied all data from the fs in question to a

[PATCH v3.3 0/2] xfstests: test the nfs/cifs/btrfs/xfs reflink/dedupe ioctls

Hi all, This is a small patch set against the reflink/dedupe test cases in xfstests. The first patch is a rewrite of the tools to find the lowest vacant ID number and to move a test case. These two programs are useful for staging a lot of new tests at a high number and moving them to lower

[PATCH 1/2] test-scripts: test migration scripts

Add two scripts: "nextid" finds the next available test ID number in a group, and "mvtest" relocates a test, fixes the golden output, and moves the group entry for that test. v2: sorting group files should preserve group order; nextid should use the same algorithm as new; move both tools to

[PATCH 2/2] generic/15[78]: fix error messages in the golden output

Fix the error messages in the golden output for generic/15[78], which examine the responses to invalid inputs as returned by the clone/clone_range/extent_same ioctls. Also fix a filtering omission. Signed-off-by: Darrick J. Wong --- tests/generic/157 | 12

Re: [PATCH] Btrfs: fix a bug of sleeping in atomic context

On Fri, Nov 20, 2015 at 02:30:43PM -0700, Jens Axboe wrote: > On 11/20/2015 06:13 AM, Chris Mason wrote: > >On Thu, Nov 19, 2015 at 05:49:37PM -0800, Liu Bo wrote: > >>while xfstesting, this bug[1] is spotted by both btrfs/061 and btrfs/063, > >>so those sub-stripe writes are gatherred into plug

Re: [PATCH v4] Btrfs: fix race when finishing dev replace leading to transaction abort

On Fri, Nov 20, 2015 at 02:12:26PM +, fdman...@kernel.org wrote: > From: Filipe Manana > > During the final phase of a device replace operation, I ran into a > transaction abort that resulted in the following trace: > > [23919.655368] WARNING: CPU: 10 PID: 30175 at

Re: 4.2.6: livelock in recovery (free_reloc_roots)?

A follow-up question: Can "btrfs_recover_relocation" prevented from being run? I would not mind losing a few recent writes (what was a balance) but instead going rw again, so I can restart a balance. >From what I have read, btrfs-zero-log would not help in this case (?) so I did not run it so

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On 11/21/2015 01:47 PM, Qu Wenruo wrote as excerpted: > Hard to say, but we'd better keep an eye on this issue. > At least, if it happens again, we should know if it's related to > something like newer kernel or snapshots. I can confirm the initially describe behavior of "btrfs check" and reading

Re: [PATCH] Btrfs: fix a bug of sleeping in atomic context

On Fri, Nov 20, 2015 at 07:26:45PM -0700, Jens Axboe wrote: > On 11/20/2015 04:08 PM, Liu Bo wrote: > >On Fri, Nov 20, 2015 at 02:30:43PM -0700, Jens Axboe wrote: > >>On 11/20/2015 06:13 AM, Chris Mason wrote: > >>>On Thu, Nov 19, 2015 at 05:49:37PM -0800, Liu Bo wrote: > while xfstesting,

Re: [PATCH] Btrfs: fix a bug of sleeping in atomic context

On 11/20/2015 08:14 PM, Liu Bo wrote: On Fri, Nov 20, 2015 at 07:26:45PM -0700, Jens Axboe wrote: On 11/20/2015 04:08 PM, Liu Bo wrote: On Fri, Nov 20, 2015 at 02:30:43PM -0700, Jens Axboe wrote: On 11/20/2015 06:13 AM, Chris Mason wrote: On Thu, Nov 19, 2015 at 05:49:37PM -0800, Liu Bo

Re: [Enhancement] ... and please rename "raid1" to something better

Christoph Anton Mitterer posted on Fri, 20 Nov 2015 20:29:34 +0100 as excerpted: > On Fri, 2015-11-20 at 11:05 +, Duncan wrote: >> It's missing raid1. =:^( > speaking of which... > > Wouldn't the developers consider to rename raid1 to something more > correct? E.g. replicas2 or dup or

Re: [PATCH] Btrfs: fix a bug of sleeping in atomic context

On 11/20/2015 04:08 PM, Liu Bo wrote: On Fri, Nov 20, 2015 at 02:30:43PM -0700, Jens Axboe wrote: On 11/20/2015 06:13 AM, Chris Mason wrote: On Thu, Nov 19, 2015 at 05:49:37PM -0800, Liu Bo wrote: while xfstesting, this bug[1] is spotted by both btrfs/061 and btrfs/063, so those sub-stripe

Re: 4.2.6: livelock in recovery (free_reloc_roots)?

Lukas Pirl posted on Sat, 21 Nov 2015 13:37:37 +1300 as excerpted: > Can "btrfs_recover_relocation" prevented from being run? I would not > mind losing a few recent writes (what was a balance) but instead going > rw again, so I can restart a balance. I'm not familiar with that thread name (I run

Re: [PATCH] Btrfs: fix a bug of sleeping in atomic context

On Fri, Nov 20, 2015 at 08:29:06PM -0700, Jens Axboe wrote: > On 11/20/2015 08:14 PM, Liu Bo wrote: > >On Fri, Nov 20, 2015 at 07:26:45PM -0700, Jens Axboe wrote: > >>On 11/20/2015 04:08 PM, Liu Bo wrote: > >>>On Fri, Nov 20, 2015 at 02:30:43PM -0700, Jens Axboe wrote: > On 11/20/2015 06:13