invalid opcode 0000 / kernel bug with defect HDD

Cause of kernel bugs was a defective HDD (/dev/sdd). The kernel BUG: May 16 07:41:38 nas kernel: [37168.832800] btrfs_dev_stat_print_on_error: 470 callbacks suppressed May 16 07:41:38 nas kernel: [37168.832806] BTRFS error (device sdd): bdev /dev/sdb errs: wr 49293, rd 567248, flush 0, corrupt

Re: invalid opcode 0000 / kernel bug with defect HDD

Peter Becker posted on Tue, 28 Jun 2016 10:16:58 +0200 as excerpted: > Cause of kernel bugs was a defective HDD (/dev/sdd). Just a short note to mention that invalid opcode doesn't say much. I'm just another user and list regular, but apparently, opcode is used as a deliberate way

Re: [PATCH v2 0/4] btrfs feature testing + props fix

On Mon, Jun 27, 2016 at 04:14:10PM -0400, je...@suse.com wrote: > From: Jeff Mahoney > > Hi all - > > Thanks, Eryu, for the review. The btrfs feature testing changes were a > patchet I wrote three years ago, and it looks like significant cleanup > has happened in the xfstests

Re: Adventures in btrfs raid5 disk recovery

On 2016-06-27 23:17, Zygo Blaxell wrote: On Mon, Jun 27, 2016 at 08:39:21PM -0600, Chris Murphy wrote: On Mon, Jun 27, 2016 at 7:52 PM, Zygo Blaxell wrote: On Mon, Jun 27, 2016 at 04:30:23PM -0600, Chris Murphy wrote: Btrfs does have something of a work around

Re: Adventures in btrfs raid5 disk recovery

On 2016-06-27 17:57, Zygo Blaxell wrote: On Mon, Jun 27, 2016 at 10:17:04AM -0600, Chris Murphy wrote: On Mon, Jun 27, 2016 at 5:21 AM, Austin S. Hemmelgarn wrote: On 2016-06-25 12:44, Chris Murphy wrote: On Fri, Jun 24, 2016 at 12:19 PM, Austin S. Hemmelgarn

Btrfs check command fails with "assertion failed" error

When trying to repair a btrfs root filesystem I get the following error message: # losetup -f /home/fturco/Buffer/root-20160616.img # btrfs check --repair /dev/loop0 enabling repair mode warning, device 4 is missing Checking filesystem on /dev/loop0 UUID: 34fb5b58-f50f-47c3-a5b8-91d81a30eade

Re: Btrfs full balance command fails due to ENOSPC (bug 121071)

On 2016-06-27 23:47, Hans van Kranenburg wrote: > Since the existence of python-btrfs, it has gathered a few useful > example scripts: > > git clone https://github.com/knorrie/python-btrfs > cd python-btrfs/examples/ > (get root prompt) > > ./show_usage.py /mountpoint <- view sorted by 'virtual'

Re: Btrfs full balance command fails due to ENOSPC (bug 121071)

On 2016-06-27 23:26, Henk Slager wrote: > btrfs-debug does not show metadata ans system chunks; the balancing > problem might come from those. > This script does show all chunks: > https://github.com/knorrie/btrfs-heatmap/blob/master/show_usage.py > > You might want to use vrange or drange

Re: Btrfs check command fails with "assertion failed" error

On 2016-06-28 20:20, Francesco Turco wrote: > So I'm going to submit a bug as you suggested. Done: https://bugzilla.kernel.org/show_bug.cgi?id=12 I also found another similar bug: https://bugzilla.kernel.org/show_bug.cgi?id=104821 -- Website: http://www.fturco.net/ GPG key: 6712 2364 B2FE

Re: Adventures in btrfs raid5 disk recovery

On 28/06/16 22:25, Austin S. Hemmelgarn wrote: > On 2016-06-28 08:14, Steven Haigh wrote: >> On 28/06/16 22:05, Austin S. Hemmelgarn wrote: >>> On 2016-06-27 17:57, Zygo Blaxell wrote: On Mon, Jun 27, 2016 at 10:17:04AM -0600, Chris Murphy wrote: > On Mon, Jun 27, 2016 at 5:21 AM, Austin

Re: Adventures in btrfs raid5 disk recovery

Just wiping the slate clean to summarize: 1. We have a consistent ~1 in 3 maybe 1 in 2, reproducible corruption of *data extent* parity during a scrub with raid5. Goffredo and I have both reproduced it. It's a big bug. It might still be useful if someone else can reproduce it too. Goffredo, can

Re: Btrfs check command fails with "assertion failed" error

On Tue, Jun 28, 2016 at 9:58 AM, Francesco Turco wrote: > When trying to repair a btrfs root filesystem I get the following error > message: > > # losetup -f /home/fturco/Buffer/root-20160616.img > # btrfs check --repair /dev/loop0 > enabling repair mode > warning, device 4 is

Re: Btrfs check command fails with "assertion failed" error

On 2016-06-28 20:05, Chris Murphy wrote: > Well it probably shouldn't crash but the question is why is device 4 > missing? We have no information what version of btrfs-progs or kernel > is used, or what the layout of this volume is: how many devices, > what's the profile breakdown, etc. Are you

Re: Adventures in btrfs raid5 disk recovery

On 29/06/16 04:01, Chris Murphy wrote: > Just wiping the slate clean to summarize: > > > 1. We have a consistent ~1 in 3 maybe 1 in 2, reproducible corruption > of *data extent* parity during a scrub with raid5. Goffredo and I have > both reproduced it. It's a big bug. It might still be useful

Re: Bug in 'btrfs filesystem du' ?

On Tue, Jun 28, 2016 at 2:56 PM, M G Berberich wrote: > Hello, > > Am Montag, den 27. Juni schrieb Henk Slager: >> On Mon, Jun 27, 2016 at 3:33 PM, M G Berberich >> wrote: >> > Am Montag, den 27. Juni schrieb M G Berberich: >> >> after a

Re: Bug in 'btrfs filesystem du' ?

28.06.2016 19:55, Henk Slager пишет: > On Tue, Jun 28, 2016 at 2:56 PM, M G Berberich > wrote: >> Hello, >> >> Am Montag, den 27. Juni schrieb Henk Slager: >>> On Mon, Jun 27, 2016 at 3:33 PM, M G Berberich >>> wrote: Am Montag, den 27.

Re: Btrfs check command fails with "assertion failed" error

On Tue, Jun 28, 2016 at 12:20 PM, Francesco Turco wrote: > On 2016-06-28 20:05, Chris Murphy wrote: >> Well it probably shouldn't crash but the question is why is device 4 >> missing? We have no information what version of btrfs-progs or kernel >> is used, or what the layout

btrfs-check: Fix bitflipped keys from bad RAM

Hello! A patch with this subject was submitted in May 2014: http://www.spinics.net/lists/linux-btrfs/msg33777.html I don't see it among any of the ~360 open issues at https://bugzilla.kernel.org/buglist.cgi?bug_status=NEW_status=ASSIGNED_status=REOPENED=btrfs Unless somebody objects, I'll file

[PATCH] Btrfs: fix double free of fs root

I got this warning while mounting a btrfs image, [ 3020.509606] [ cut here ] [ 3020.510107] WARNING: CPU: 3 PID: 5581 at lib/idr.c:1051 ida_remove+0xca/0x190 [ 3020.510853] ida_remove called for id=42 which is not allocated. [ 3020.511466] Modules linked in: [ 3020.511802]

btrfs_evit_inode doesn't handle not fully initialized inodes.

Hello, On kernel 4.4.9 I've observed the following oops: [3248626.755570] BUG: unable to handle kernel NULL pointer dereference at 035c [3248626.755839] IP: [] btrfs_evict_inode+0x2f/0x610 [btrfs] [3248626.756079] PGD 1eaf8d067 PUD 4096a0067 PMD 0 [3248626.756383] Oops: [#1]

[PATCH 2/2] btrfs: fix free space calculation in dump_space_info()

Signed-off-by: Wang Xiaoguang --- fs/btrfs/extent-tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 8550a0e..520ba8f 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@

[PATCH 1/2] btrfs: fix fsfreeze hang caused by delayed iputs deal

When running fstests generic/068, sometimes we got below WARNING: xfs_io D 8800331dbb20 0 6697 6693 0x0080 8800331dbb20 88007acfc140 880034d895c0 8800331dc000 880032d243e8 fffe 880032d24400 0001 8800331dbb38

Re: Kernel bug during RAID1 replace

On Mon, 27 Jun 2016 20:14:58 -0600, Chris Murphy wrote : > On Mon, Jun 27, 2016 at 6:49 PM, Saint Germain > wrote: > > > > > I've tried both option and launched a replace, but I got the same > > error (replace is cancelled, jernel bug). > > I will

Re: Btrfs full balance command fails due to ENOSPC (bug 121071)

On Tue, Jun 28, 2016 at 3:46 PM, Francesco Turco wrote: > On 2016-06-27 23:26, Henk Slager wrote: >> btrfs-debug does not show metadata ans system chunks; the balancing >> problem might come from those. >> This script does show all chunks: >>

[PATCH 21/20] xfs/128: cycle_mount the scratch device, not the test device

This test uses the scratch device, so cycle that, not the test dev. Signed-off-by: Darrick J. Wong --- tests/xfs/128 |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tests/xfs/128 b/tests/xfs/128 index 8758d7e..2e756d5 100755 ---

Re: Bug in 'btrfs filesystem du' ?

28.06.2016 20:20, Andrei Borzenkov пишет: > 28.06.2016 19:55, Henk Slager пишет: >> On Tue, Jun 28, 2016 at 2:56 PM, M G Berberich >> wrote: >>> Hello, >>> >>> Am Montag, den 27. Juni schrieb Henk Slager: On Mon, Jun 27, 2016 at 3:33 PM, M G Berberich

Re: Kernel bug during RAID1 replace

On Tue, Jun 28, 2016 at 4:52 PM, Saint Germain wrote: > Well I made a ddrescue image of both drives (only one error on sdb > during ddrescue copy) and started the computer again (after > disconnecting the old drives). What was the error? Any kernel message at the time of

[PATCH] Btrfs: fix read_node_slot to return errors

We use read_node_slot() to read btree node and it has two cases, a) slot is out of range, which means 'no such entry' b) we fail to read the block, due to checksum fails or corrupted content or not with uptodate flag. But we're returning NULL in both cases, this makes it return -ENOENT in case

Re: invalid opcode 0000 / kernel bug with defect HDD

On Tue, Jun 28, 2016 at 10:16:58AM +0200, Peter Becker wrote: > Cause of kernel bugs was a defective HDD (/dev/sdd). Thanks for reporting this bug, I can reproduce it, it's due to the fact that we cannot read a valid btree node from the underlying disks, which comes from a defective HDD in your

Re: Adventures in btrfs raid5 disk recovery

On 2016-06-28 08:14, Steven Haigh wrote: On 28/06/16 22:05, Austin S. Hemmelgarn wrote: On 2016-06-27 17:57, Zygo Blaxell wrote: On Mon, Jun 27, 2016 at 10:17:04AM -0600, Chris Murphy wrote: On Mon, Jun 27, 2016 at 5:21 AM, Austin S. Hemmelgarn wrote: On 2016-06-25

Re: Bug in 'btrfs filesystem du' ?

Hello, Am Montag, den 27. Juni schrieb Henk Slager: > On Mon, Jun 27, 2016 at 3:33 PM, M G Berberich > wrote: > > Am Montag, den 27. Juni schrieb M G Berberich: > >> after a balance ‘btrfs filesystem du’ probably shows false data about > >> shared data. > > > > Oh, I

Re: Adventures in btrfs raid5 disk recovery

On 28/06/16 22:05, Austin S. Hemmelgarn wrote: > On 2016-06-27 17:57, Zygo Blaxell wrote: >> On Mon, Jun 27, 2016 at 10:17:04AM -0600, Chris Murphy wrote: >>> On Mon, Jun 27, 2016 at 5:21 AM, Austin S. Hemmelgarn >>> wrote: On 2016-06-25 12:44, Chris Murphy wrote: >