* [4.3-rc4] scrubbing aborts before finishing
@ 2015-10-22 8:41 Martin Steigerwald
2015-10-31 11:10 ` Martin Steigerwald
0 siblings, 1 reply; 9+ messages in thread
From: Martin Steigerwald @ 2015-10-22 8:41 UTC (permalink / raw)
To: linux-btrfs
Hi!
I get this:
merkaba:~> btrfs scrub status -d /
scrub status for […]
scrub device /dev/mapper/sata-debian (id 1) history
scrub started at Thu Oct 22 10:05:49 2015 and was aborted after 00:00:00
total bytes scrubbed: 0.00B with 0 errors
scrub device /dev/dm-2 (id 2) history
scrub started at Thu Oct 22 10:05:49 2015 and was aborted after 00:01:30
total bytes scrubbed: 23.81GiB with 0 errors
For / scrub aborts for sata SSD immediately.
For /home scrub aborts for both SSDs at some time.
merkaba:~> btrfs scrub status -d /home
scrub status for […]
scrub device /dev/mapper/msata-home (id 1) history
scrub started at Thu Oct 22 10:09:37 2015 and was aborted after 00:01:31
total bytes scrubbed: 22.03GiB with 0 errors
scrub device /dev/dm-3 (id 2) history
scrub started at Thu Oct 22 10:09:37 2015 and was aborted after 00:03:34
total bytes scrubbed: 53.30GiB with 0 errors
Also single volume BTRFS is affected:
merkaba:~> btrfs scrub status /daten
scrub status for […]
scrub started at Thu Oct 22 10:36:38 2015 and was aborted after 00:00:00
total bytes scrubbed: 0.00B with 0 errors
No errors in dmesg, btrfs device stat or smartctl -a.
Any known issue?
Thanks,
--
Martin
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [4.3-rc4] scrubbing aborts before finishing 2015-10-22 8:41 [4.3-rc4] scrubbing aborts before finishing Martin Steigerwald @ 2015-10-31 11:10 ` Martin Steigerwald 2015-11-25 15:35 ` Martin Steigerwald 0 siblings, 1 reply; 9+ messages in thread From: Martin Steigerwald @ 2015-10-31 11:10 UTC (permalink / raw) To: linux-btrfs Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald: > I get this: > > merkaba:~> btrfs scrub status -d / > scrub status for […] > scrub device /dev/mapper/sata-debian (id 1) history > scrub started at Thu Oct 22 10:05:49 2015 and was aborted after 00:00:00 > total bytes scrubbed: 0.00B with 0 errors > scrub device /dev/dm-2 (id 2) history > scrub started at Thu Oct 22 10:05:49 2015 and was aborted after 00:01:30 > total bytes scrubbed: 23.81GiB with 0 errors > > For / scrub aborts for sata SSD immediately. > > For /home scrub aborts for both SSDs at some time. > > merkaba:~> btrfs scrub status -d /home > scrub status for […] > scrub device /dev/mapper/msata-home (id 1) history > scrub started at Thu Oct 22 10:09:37 2015 and was aborted after 00:01:31 > total bytes scrubbed: 22.03GiB with 0 errors > scrub device /dev/dm-3 (id 2) history > scrub started at Thu Oct 22 10:09:37 2015 and was aborted after 00:03:34 > total bytes scrubbed: 53.30GiB with 0 errors > > Also single volume BTRFS is affected: > > merkaba:~> btrfs scrub status /daten > scrub status for […] > scrub started at Thu Oct 22 10:36:38 2015 and was aborted after 00:00:00 > total bytes scrubbed: 0.00B with 0 errors > > > No errors in dmesg, btrfs device stat or smartctl -a. > > Any known issue? I am still seeing this in 4.3-rc7. It happens so that on one SSD BTRFS doesn´t even start scrubbing. But in the end it aborts it scrubbing anyway. I do not see any other issue so far. But I would really like to be able to scrub my BTRFS filesystems completely again. Any hints? Any further information needed? merkaba:~> btrfs scrub status -d / scrub status for […] scrub device /dev/dm-5 (id 1) history scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 total bytes scrubbed: 0.00B with 0 errors scrub device /dev/mapper/msata-debian (id 2) status scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:20 total bytes scrubbed: 5.27GiB with 0 errors merkaba:~> btrfs scrub status -d / scrub status for […] scrub device /dev/dm-5 (id 1) history scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 total bytes scrubbed: 0.00B with 0 errors scrub device /dev/mapper/msata-debian (id 2) status scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:25 total bytes scrubbed: 6.59GiB with 0 errors merkaba:~> btrfs scrub status -d / scrub status for […] scrub device /dev/dm-5 (id 1) history scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 total bytes scrubbed: 0.00B with 0 errors scrub device /dev/mapper/msata-debian (id 2) status scrub started at Sat Oct 31 11:58:45 2015, running for 00:01:25 total bytes scrubbed: 21.97GiB with 0 errors merkaba:~> btrfs scrub status -d / scrub status for […] scrub device /dev/dm-5 (id 1) history scrub started at Sat Oct 31 11:58:45 2015 and was aborted after 00:00:00 total bytes scrubbed: 0.00B with 0 errors scrub device /dev/mapper/msata-debian (id 2) history scrub started at Sat Oct 31 11:58:45 2015 and was aborted after 00:01:32 total bytes scrubbed: 23.63GiB with 0 errors For the sake of it I am going to btrfs check one of the filesystem where BTRFS aborts scrubbing (which is all of the laptop filesystems, not only the RAID 1 one). I will use the /daten filesystem as I can unmount it during laptop runtime easily. There scrubbing aborts immediately: merkaba:~> btrfs scrub start /daten scrub started on /daten, fsid […] (pid=13861) merkaba:~> btrfs scrub status /daten scrub status for […] scrub started at Sat Oct 31 12:04:25 2015 and was aborted after 00:00:00 total bytes scrubbed: 0.00B with 0 errors It is single device: merkaba:~> btrfs fi sh /daten Label: 'daten' uuid: […] Total devices 1 FS bytes used 227.23GiB devid 1 size 230.00GiB used 230.00GiB path /dev/mapper/msata-daten btrfs-progs v4.2.2 merkaba:~> btrfs fi df /daten Data, single: total=228.99GiB, used=226.79GiB System, single: total=4.00MiB, used=48.00KiB Metadata, single: total=1.01GiB, used=449.50MiB GlobalReserve, single: total=160.00MiB, used=0.00B I do not see any output in btrfs check that points to any issue: merkaba:~> btrfs check /dev/msata/daten Checking filesystem on /dev/msata/daten UUID: 7918274f-e2ec-4983-bbb0-aa93ef95fcf7 checking extents checking free space cache checking fs roots checking csums checking root refs found 243936530607 bytes used err is 0 total csum bytes: 237758932 total tree bytes: 471384064 total fs tree bytes: 116473856 total extent tree bytes: 78544896 btree space waste bytes: 57523323 file data blocks allocated: 422700576768 referenced 243803443200 btrfs-progs v4.2.2 Thanks, -- Martin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [4.3-rc4] scrubbing aborts before finishing 2015-10-31 11:10 ` Martin Steigerwald @ 2015-11-25 15:35 ` Martin Steigerwald 2015-11-26 16:39 ` Duncan 2015-12-14 7:59 ` Martin Steigerwald 0 siblings, 2 replies; 9+ messages in thread From: Martin Steigerwald @ 2015-11-25 15:35 UTC (permalink / raw) To: linux-btrfs Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald: > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald: > > I get this: > > > > merkaba:~> btrfs scrub status -d / > > scrub status for […] > > scrub device /dev/mapper/sata-debian (id 1) history > > > > scrub started at Thu Oct 22 10:05:49 2015 and was aborted after > > 00:00:00 > > total bytes scrubbed: 0.00B with 0 errors > > > > scrub device /dev/dm-2 (id 2) history > > > > scrub started at Thu Oct 22 10:05:49 2015 and was aborted after > > 00:01:30 > > total bytes scrubbed: 23.81GiB with 0 errors > > > > For / scrub aborts for sata SSD immediately. > > > > For /home scrub aborts for both SSDs at some time. > > > > merkaba:~> btrfs scrub status -d /home > > scrub status for […] > > scrub device /dev/mapper/msata-home (id 1) history > > > > scrub started at Thu Oct 22 10:09:37 2015 and was aborted after > > 00:01:31 > > total bytes scrubbed: 22.03GiB with 0 errors > > > > scrub device /dev/dm-3 (id 2) history > > > > scrub started at Thu Oct 22 10:09:37 2015 and was aborted after > > 00:03:34 > > total bytes scrubbed: 53.30GiB with 0 errors > > > > Also single volume BTRFS is affected: > > > > merkaba:~> btrfs scrub status /daten > > scrub status for […] > > > > scrub started at Thu Oct 22 10:36:38 2015 and was aborted after > > 00:00:00 > > total bytes scrubbed: 0.00B with 0 errors > > > > No errors in dmesg, btrfs device stat or smartctl -a. > > > > Any known issue? > > I am still seeing this in 4.3-rc7. It happens so that on one SSD BTRFS > doesn´t even start scrubbing. But in the end it aborts it scrubbing anyway. > > I do not see any other issue so far. But I would really like to be able to > scrub my BTRFS filesystems completely again. Any hints? Any further > information needed? > > merkaba:~> btrfs scrub status -d / > scrub status for […] > scrub device /dev/dm-5 (id 1) history > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 > total bytes scrubbed: 0.00B with 0 errors > scrub device /dev/mapper/msata-debian (id 2) status > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:20 > total bytes scrubbed: 5.27GiB with 0 errors > merkaba:~> btrfs scrub status -d / > scrub status for […] > scrub device /dev/dm-5 (id 1) history > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 > total bytes scrubbed: 0.00B with 0 errors > scrub device /dev/mapper/msata-debian (id 2) status > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:25 > total bytes scrubbed: 6.59GiB with 0 errors > merkaba:~> btrfs scrub status -d / > scrub status for […] > scrub device /dev/dm-5 (id 1) history > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 > total bytes scrubbed: 0.00B with 0 errors > scrub device /dev/mapper/msata-debian (id 2) status > scrub started at Sat Oct 31 11:58:45 2015, running for 00:01:25 > total bytes scrubbed: 21.97GiB with 0 errors > merkaba:~> btrfs scrub status -d / > scrub status for […] > scrub device /dev/dm-5 (id 1) history > scrub started at Sat Oct 31 11:58:45 2015 and was aborted after > 00:00:00 total bytes scrubbed: 0.00B with 0 errors > scrub device /dev/mapper/msata-debian (id 2) history > scrub started at Sat Oct 31 11:58:45 2015 and was aborted after > 00:01:32 total bytes scrubbed: 23.63GiB with 0 errors > > > For the sake of it I am going to btrfs check one of the filesystem where > BTRFS aborts scrubbing (which is all of the laptop filesystems, not only > the RAID 1 one). > > I will use the /daten filesystem as I can unmount it during laptop runtime > easily. There scrubbing aborts immediately: > > merkaba:~> btrfs scrub start /daten > scrub started on /daten, fsid […] (pid=13861) > merkaba:~> btrfs scrub status /daten > scrub status for […] > scrub started at Sat Oct 31 12:04:25 2015 and was aborted after > 00:00:00 total bytes scrubbed: 0.00B with 0 errors > > It is single device: > > merkaba:~> btrfs fi sh /daten > Label: 'daten' uuid: […] > Total devices 1 FS bytes used 227.23GiB > devid 1 size 230.00GiB used 230.00GiB path > /dev/mapper/msata-daten > > btrfs-progs v4.2.2 > merkaba:~> btrfs fi df /daten > Data, single: total=228.99GiB, used=226.79GiB > System, single: total=4.00MiB, used=48.00KiB > Metadata, single: total=1.01GiB, used=449.50MiB > GlobalReserve, single: total=160.00MiB, used=0.00B > > > I do not see any output in btrfs check that points to any issue: > > merkaba:~> btrfs check /dev/msata/daten > Checking filesystem on /dev/msata/daten > UUID: 7918274f-e2ec-4983-bbb0-aa93ef95fcf7 > checking extents > checking free space cache > checking fs roots > checking csums > checking root refs > found 243936530607 bytes used err is 0 > total csum bytes: 237758932 > total tree bytes: 471384064 > total fs tree bytes: 116473856 > total extent tree bytes: 78544896 > btree space waste bytes: 57523323 > file data blocks allocated: 422700576768 > referenced 243803443200 > btrfs-progs v4.2.2 Even with 4.4-rc2 this issue still happens: merkaba:~> btrfs scrub status -d / scrub status for […] scrub device /dev/mapper/sata-debian (id 1) history scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:00 total bytes scrubbed: 0.00B with 0 errors scrub device /dev/dm-2 (id 2) status scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:55 total bytes scrubbed: 14.24GiB with 0 errors merkaba:~> btrfs scrub status -d / scrub status for […] scrub device /dev/mapper/sata-debian (id 1) history scrub started at Wed Nov 25 16:28:33 2015 and was aborted after 00:00:00 total bytes scrubbed: 0.00B with 0 errors scrub device /dev/dm-2 (id 2) history scrub started at Wed Nov 25 16:28:33 2015 and was aborted after 00:01:33 total bytes scrubbed: 23.71GiB with 0 errors merkaba:~> cat /proc/version Linux version 4.4.0-rc2-tp520+ (martin@merkaba) (gcc version 5.2.1 20151121 (Debian 5.2.1-24) ) #45 SMP PREEMPT Mon Nov 23 17:10:16 CET 2015 This time I also removed all files in /var/lib/btrfs to avoid any possible issues with saved BTRFS status reports. (Yeah, I think it would have been enough to just delete the one for the filesystem with that UUID.) As written this bug also happens with a single device BTRFS. I´d report a bug report, in case anyone would be interested. But if the interest it like in this mailinglist post I can spare myself the time for reporting via bugzilla. So does anyone at all care about this issue? Thanks, -- Martin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [4.3-rc4] scrubbing aborts before finishing 2015-11-25 15:35 ` Martin Steigerwald @ 2015-11-26 16:39 ` Duncan 2015-12-14 7:59 ` Martin Steigerwald 1 sibling, 0 replies; 9+ messages in thread From: Duncan @ 2015-11-26 16:39 UTC (permalink / raw) To: linux-btrfs Martin Steigerwald posted on Wed, 25 Nov 2015 16:35:39 +0100 as excerpted: > I´d report a bug report, in case anyone would be interested. But if the > interest it like in this mailinglist post I can spare myself the time > for reporting via bugzilla. > > So does anyone at all care about this issue? FWIW I'm interested, but haven't as a user seen the same thing here... scrubs have worked fine here unless I forget to sudo, in which case they don't work at all as they can't get necessary privs. And I'm stumped as to what else it might be. I don't even have an idea where to start looking for clues. But not being a dev and having not the foggiest what the problem may be, it's not like my interest is going to help much, which is why I didn't reply earlier. Just posting now to say you're not alone in your interest. Things like this that don't seem to have any logic bother me, tho, so I really would like to at least learn why it's happening. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [4.3-rc4] scrubbing aborts before finishing 2015-11-25 15:35 ` Martin Steigerwald 2015-11-26 16:39 ` Duncan @ 2015-12-14 7:59 ` Martin Steigerwald 2015-12-14 17:31 ` Henk Slager 2015-12-15 23:18 ` [4.3-rc4] scrubbing aborts before finishing (probably solved) Martin Steigerwald 1 sibling, 2 replies; 9+ messages in thread From: Martin Steigerwald @ 2015-12-14 7:59 UTC (permalink / raw) To: linux-btrfs Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie: > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald: > > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald: > > > I get this: > > > > > > merkaba:~> btrfs scrub status -d / > > > scrub status for […] > > > scrub device /dev/mapper/sata-debian (id 1) history > > > > > > scrub started at Thu Oct 22 10:05:49 2015 and was aborted after > > > 00:00:00 > > > total bytes scrubbed: 0.00B with 0 errors > > > > > > scrub device /dev/dm-2 (id 2) history > > > > > > scrub started at Thu Oct 22 10:05:49 2015 and was aborted after > > > 00:01:30 > > > total bytes scrubbed: 23.81GiB with 0 errors > > > > > > For / scrub aborts for sata SSD immediately. > > > > > > For /home scrub aborts for both SSDs at some time. > > > > > > merkaba:~> btrfs scrub status -d /home > > > scrub status for […] > > > scrub device /dev/mapper/msata-home (id 1) history > > > > > > scrub started at Thu Oct 22 10:09:37 2015 and was aborted after > > > 00:01:31 > > > total bytes scrubbed: 22.03GiB with 0 errors > > > > > > scrub device /dev/dm-3 (id 2) history > > > > > > scrub started at Thu Oct 22 10:09:37 2015 and was aborted after > > > 00:03:34 > > > total bytes scrubbed: 53.30GiB with 0 errors > > > > > > Also single volume BTRFS is affected: > > > > > > merkaba:~> btrfs scrub status /daten > > > scrub status for […] > > > > > > scrub started at Thu Oct 22 10:36:38 2015 and was aborted after > > > 00:00:00 > > > total bytes scrubbed: 0.00B with 0 errors > > > > > > No errors in dmesg, btrfs device stat or smartctl -a. > > > > > > Any known issue? > > > > I am still seeing this in 4.3-rc7. It happens so that on one SSD BTRFS > > doesn´t even start scrubbing. But in the end it aborts it scrubbing > > anyway. > > > > I do not see any other issue so far. But I would really like to be able to > > scrub my BTRFS filesystems completely again. Any hints? Any further > > information needed? > > > > merkaba:~> btrfs scrub status -d / > > scrub status for […] > > scrub device /dev/dm-5 (id 1) history > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 > > total bytes scrubbed: 0.00B with 0 errors > > > > scrub device /dev/mapper/msata-debian (id 2) status > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:20 > > total bytes scrubbed: 5.27GiB with 0 errors > > > > merkaba:~> btrfs scrub status -d / > > scrub status for […] > > scrub device /dev/dm-5 (id 1) history > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 > > total bytes scrubbed: 0.00B with 0 errors > > > > scrub device /dev/mapper/msata-debian (id 2) status > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:25 > > total bytes scrubbed: 6.59GiB with 0 errors > > > > merkaba:~> btrfs scrub status -d / > > scrub status for […] > > scrub device /dev/dm-5 (id 1) history > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 > > total bytes scrubbed: 0.00B with 0 errors > > > > scrub device /dev/mapper/msata-debian (id 2) status > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:01:25 > > total bytes scrubbed: 21.97GiB with 0 errors > > > > merkaba:~> btrfs scrub status -d / > > scrub status for […] > > scrub device /dev/dm-5 (id 1) history > > > > scrub started at Sat Oct 31 11:58:45 2015 and was aborted after > > > > 00:00:00 total bytes scrubbed: 0.00B with 0 errors > > scrub device /dev/mapper/msata-debian (id 2) history > > > > scrub started at Sat Oct 31 11:58:45 2015 and was aborted after > > > > 00:01:32 total bytes scrubbed: 23.63GiB with 0 errors > > > > > > For the sake of it I am going to btrfs check one of the filesystem where > > BTRFS aborts scrubbing (which is all of the laptop filesystems, not only > > the RAID 1 one). > > > > I will use the /daten filesystem as I can unmount it during laptop runtime > > easily. There scrubbing aborts immediately: > > > > merkaba:~> btrfs scrub start /daten > > scrub started on /daten, fsid […] (pid=13861) > > merkaba:~> btrfs scrub status /daten > > scrub status for […] > > > > scrub started at Sat Oct 31 12:04:25 2015 and was aborted after > > > > 00:00:00 total bytes scrubbed: 0.00B with 0 errors > > > > It is single device: > > > > merkaba:~> btrfs fi sh /daten > > Label: 'daten' uuid: […] > > > > Total devices 1 FS bytes used 227.23GiB > > devid 1 size 230.00GiB used 230.00GiB path > > > > /dev/mapper/msata-daten > > > > btrfs-progs v4.2.2 > > merkaba:~> btrfs fi df /daten > > Data, single: total=228.99GiB, used=226.79GiB > > System, single: total=4.00MiB, used=48.00KiB > > Metadata, single: total=1.01GiB, used=449.50MiB > > GlobalReserve, single: total=160.00MiB, used=0.00B > > > > > > I do not see any output in btrfs check that points to any issue: > > > > merkaba:~> btrfs check /dev/msata/daten > > Checking filesystem on /dev/msata/daten > > UUID: 7918274f-e2ec-4983-bbb0-aa93ef95fcf7 > > checking extents > > checking free space cache > > checking fs roots > > checking csums > > checking root refs > > found 243936530607 bytes used err is 0 > > total csum bytes: 237758932 > > total tree bytes: 471384064 > > total fs tree bytes: 116473856 > > total extent tree bytes: 78544896 > > btree space waste bytes: 57523323 > > file data blocks allocated: 422700576768 > > > > referenced 243803443200 > > > > btrfs-progs v4.2.2 > > Even with 4.4-rc2 this issue still happens: > > merkaba:~> btrfs scrub status -d / > scrub status for […] > scrub device /dev/mapper/sata-debian (id 1) history > scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:00 > total bytes scrubbed: 0.00B with 0 errors > scrub device /dev/dm-2 (id 2) status > scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:55 > total bytes scrubbed: 14.24GiB with 0 errors > > merkaba:~> btrfs scrub status -d / > scrub status for […] > scrub device /dev/mapper/sata-debian (id 1) history > scrub started at Wed Nov 25 16:28:33 2015 and was aborted after > 00:00:00 > total bytes scrubbed: 0.00B with 0 errors > scrub device /dev/dm-2 (id 2) history > scrub started at Wed Nov 25 16:28:33 2015 and was aborted after > 00:01:33 > total bytes scrubbed: 23.71GiB with 0 errors > > merkaba:~> cat /proc/version > Linux version 4.4.0-rc2-tp520+ (martin@merkaba) (gcc version 5.2.1 20151121 > (Debian 5.2.1-24) ) #45 SMP PREEMPT Mon Nov 23 17:10:16 CET 2015 > > This time I also removed all files in /var/lib/btrfs to avoid any possible > issues with saved BTRFS status reports. (Yeah, I think it would have been > enough to just delete the one for the filesystem with that UUID.) > > As written this bug also happens with a single device BTRFS. > > > I´d report a bug report, in case anyone would be interested. But if the > interest it like in this mailinglist post I can spare myself the time for > reporting via bugzilla. > > So does anyone at all care about this issue? I am replying to this a fourth time in the hope that someone can at least give some suggestion on how to move forward with this. Thanks, -- Martin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [4.3-rc4] scrubbing aborts before finishing 2015-12-14 7:59 ` Martin Steigerwald @ 2015-12-14 17:31 ` Henk Slager 2015-12-14 18:11 ` Henk Slager 2015-12-15 23:18 ` [4.3-rc4] scrubbing aborts before finishing (probably solved) Martin Steigerwald 1 sibling, 1 reply; 9+ messages in thread From: Henk Slager @ 2015-12-14 17:31 UTC (permalink / raw) To: linux-btrfs [...] >> > merkaba:~> btrfs fi sh /daten >> > Label: 'daten' uuid: […] >> > >> > Total devices 1 FS bytes used 227.23GiB >> > devid 1 size 230.00GiB used 230.00GiB path [...] >> > merkaba:~> btrfs fi df /daten >> > Data, single: total=228.99GiB, used=226.79GiB >> > System, single: total=4.00MiB, used=48.00KiB >> > Metadata, single: total=1.01GiB, used=449.50MiB >> > GlobalReserve, single: total=160.00MiB, used=0.00B If this is still the fill-level of the storage device, then also with 4.4-rcX and new enough tools it will fail I think. AFAIK, scrub does writes (in metadata?) so I think a non-read-only scrub command can't allocate space. See all other comments/threads w.r.t. allocated / free space. Especially an fs of this size, I would keep ~10% free on 'device-level' ( 227.23GiB would need to be 207.00GiB ) and also ~10% on 'chunk-level' ( 226.79GiB would need to be 186.30GiB ). Assuming you don't have snapshots, a btrfs fi defrag -r /daten might give some more room short-term, after you just (re)moved files off the fs first. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [4.3-rc4] scrubbing aborts before finishing 2015-12-14 17:31 ` Henk Slager @ 2015-12-14 18:11 ` Henk Slager 0 siblings, 0 replies; 9+ messages in thread From: Henk Slager @ 2015-12-14 18:11 UTC (permalink / raw) To: linux-btrfs On Mon, Dec 14, 2015 at 6:31 PM, Henk Slager <eye1tm@gmail.com> wrote: > [...] >>> > merkaba:~> btrfs fi sh /daten >>> > Label: 'daten' uuid: […] >>> > >>> > Total devices 1 FS bytes used 227.23GiB >>> > devid 1 size 230.00GiB used 230.00GiB path > [...] >>> > merkaba:~> btrfs fi df /daten >>> > Data, single: total=228.99GiB, used=226.79GiB >>> > System, single: total=4.00MiB, used=48.00KiB >>> > Metadata, single: total=1.01GiB, used=449.50MiB >>> > GlobalReserve, single: total=160.00MiB, used=0.00B > > If this is still the fill-level of the storage device, then also with > 4.4-rcX and new enough tools it will fail I think. > AFAIK, scrub does writes (in metadata?) so I think a non-read-only > scrub command can't allocate space. See all other comments/threads > w.r.t. allocated / free space. > Especially an fs of this size, I would keep ~10% free on > 'device-level' ( 227.23GiB would need to be 207.00GiB ) and also ~10% > on 'chunk-level' ( 226.79GiB would need to be 186.30GiB ). > > Assuming you don't have snapshots, a btrfs fi defrag -r /daten > might give some more room short-term, after you just (re)moved files > off the fs first. # btrfs fi defrag -r -clzo /daten I meant. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [4.3-rc4] scrubbing aborts before finishing (probably solved) 2015-12-14 7:59 ` Martin Steigerwald 2015-12-14 17:31 ` Henk Slager @ 2015-12-15 23:18 ` Martin Steigerwald 2015-12-17 13:29 ` [4.3-rc4] scrubbing aborts before finishing (SOLVED) Martin Steigerwald 1 sibling, 1 reply; 9+ messages in thread From: Martin Steigerwald @ 2015-12-15 23:18 UTC (permalink / raw) To: linux-btrfs Am Montag, 14. Dezember 2015, 08:59:59 CET schrieb Martin Steigerwald: > Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie: > > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald: > > > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald: > > > > I get this: > > > > > > > > merkaba:~> btrfs scrub status -d / > > > > scrub status for […] > > > > scrub device /dev/mapper/sata-debian (id 1) history > > > > > > > > scrub started at Thu Oct 22 10:05:49 2015 and was aborted > > > > after > > > > 00:00:00 > > > > total bytes scrubbed: 0.00B with 0 errors > > > > > > > > scrub device /dev/dm-2 (id 2) history > > > > > > > > scrub started at Thu Oct 22 10:05:49 2015 and was aborted > > > > after > > > > 00:01:30 > > > > total bytes scrubbed: 23.81GiB with 0 errors > > > > > > > > For / scrub aborts for sata SSD immediately. > > > > > > > > For /home scrub aborts for both SSDs at some time. > > > > > > > > merkaba:~> btrfs scrub status -d /home > > > > scrub status for […] > > > > scrub device /dev/mapper/msata-home (id 1) history > > > > > > > > scrub started at Thu Oct 22 10:09:37 2015 and was aborted > > > > after > > > > 00:01:31 > > > > total bytes scrubbed: 22.03GiB with 0 errors > > > > > > > > scrub device /dev/dm-3 (id 2) history > > > > > > > > scrub started at Thu Oct 22 10:09:37 2015 and was aborted > > > > after > > > > 00:03:34 > > > > total bytes scrubbed: 53.30GiB with 0 errors > > > > > > > > Also single volume BTRFS is affected: > > > > > > > > merkaba:~> btrfs scrub status /daten > > > > scrub status for […] > > > > > > > > scrub started at Thu Oct 22 10:36:38 2015 and was aborted > > > > after > > > > 00:00:00 > > > > total bytes scrubbed: 0.00B with 0 errors > > > > > > > > No errors in dmesg, btrfs device stat or smartctl -a. > > > > > > > > Any known issue? > > > > > > I am still seeing this in 4.3-rc7. It happens so that on one SSD BTRFS > > > doesn´t even start scrubbing. But in the end it aborts it scrubbing > > > anyway. > > > > > > I do not see any other issue so far. But I would really like to be able > > > to > > > scrub my BTRFS filesystems completely again. Any hints? Any further > > > information needed? > > > > > > merkaba:~> btrfs scrub status -d / > > > scrub status for […] > > > scrub device /dev/dm-5 (id 1) history > > > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 > > > total bytes scrubbed: 0.00B with 0 errors > > > > > > scrub device /dev/mapper/msata-debian (id 2) status > > > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:20 > > > total bytes scrubbed: 5.27GiB with 0 errors > > > > > > merkaba:~> btrfs scrub status -d / > > > scrub status for […] > > > scrub device /dev/dm-5 (id 1) history > > > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 > > > total bytes scrubbed: 0.00B with 0 errors > > > > > > scrub device /dev/mapper/msata-debian (id 2) status > > > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:25 > > > total bytes scrubbed: 6.59GiB with 0 errors > > > > > > merkaba:~> btrfs scrub status -d / > > > scrub status for […] > > > scrub device /dev/dm-5 (id 1) history > > > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00 > > > total bytes scrubbed: 0.00B with 0 errors > > > > > > scrub device /dev/mapper/msata-debian (id 2) status > > > > > > scrub started at Sat Oct 31 11:58:45 2015, running for 00:01:25 > > > total bytes scrubbed: 21.97GiB with 0 errors > > > > > > merkaba:~> btrfs scrub status -d / > > > scrub status for […] > > > scrub device /dev/dm-5 (id 1) history > > > > > > scrub started at Sat Oct 31 11:58:45 2015 and was aborted after > > > > > > 00:00:00 total bytes scrubbed: 0.00B with 0 errors > > > scrub device /dev/mapper/msata-debian (id 2) history > > > > > > scrub started at Sat Oct 31 11:58:45 2015 and was aborted after > > > > > > 00:01:32 total bytes scrubbed: 23.63GiB with 0 errors > > > > > > > > > For the sake of it I am going to btrfs check one of the filesystem where > > > BTRFS aborts scrubbing (which is all of the laptop filesystems, not only > > > the RAID 1 one). > > > > > > I will use the /daten filesystem as I can unmount it during laptop > > > runtime > > > easily. There scrubbing aborts immediately: > > > > > > merkaba:~> btrfs scrub start /daten > > > scrub started on /daten, fsid […] (pid=13861) > > > merkaba:~> btrfs scrub status /daten > > > scrub status for […] > > > > > > scrub started at Sat Oct 31 12:04:25 2015 and was aborted after > > > > > > 00:00:00 total bytes scrubbed: 0.00B with 0 errors > > > > > > It is single device: > > > > > > merkaba:~> btrfs fi sh /daten > > > Label: 'daten' uuid: […] > > > > > > Total devices 1 FS bytes used 227.23GiB > > > devid 1 size 230.00GiB used 230.00GiB path > > > > > > /dev/mapper/msata-daten > > > > > > btrfs-progs v4.2.2 > > > merkaba:~> btrfs fi df /daten > > > Data, single: total=228.99GiB, used=226.79GiB > > > System, single: total=4.00MiB, used=48.00KiB > > > Metadata, single: total=1.01GiB, used=449.50MiB > > > GlobalReserve, single: total=160.00MiB, used=0.00B > > > > > > > > > I do not see any output in btrfs check that points to any issue: > > > > > > merkaba:~> btrfs check /dev/msata/daten > > > Checking filesystem on /dev/msata/daten > > > UUID: 7918274f-e2ec-4983-bbb0-aa93ef95fcf7 > > > checking extents > > > checking free space cache > > > checking fs roots > > > checking csums > > > checking root refs > > > found 243936530607 bytes used err is 0 > > > total csum bytes: 237758932 > > > total tree bytes: 471384064 > > > total fs tree bytes: 116473856 > > > total extent tree bytes: 78544896 > > > btree space waste bytes: 57523323 > > > file data blocks allocated: 422700576768 > > > > > > referenced 243803443200 > > > > > > btrfs-progs v4.2.2 > > > > Even with 4.4-rc2 this issue still happens: > > > > merkaba:~> btrfs scrub status -d / > > scrub status for […] > > scrub device /dev/mapper/sata-debian (id 1) history > > > > scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:00 > > total bytes scrubbed: 0.00B with 0 errors > > > > scrub device /dev/dm-2 (id 2) status > > > > scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:55 > > total bytes scrubbed: 14.24GiB with 0 errors > > > > merkaba:~> btrfs scrub status -d / > > scrub status for […] > > scrub device /dev/mapper/sata-debian (id 1) history > > > > scrub started at Wed Nov 25 16:28:33 2015 and was aborted after > > > > 00:00:00 > > > > total bytes scrubbed: 0.00B with 0 errors > > > > scrub device /dev/dm-2 (id 2) history > > > > scrub started at Wed Nov 25 16:28:33 2015 and was aborted after > > > > 00:01:33 > > > > total bytes scrubbed: 23.71GiB with 0 errors > > > > merkaba:~> cat /proc/version > > Linux version 4.4.0-rc2-tp520+ (martin@merkaba) (gcc version 5.2.1 > > 20151121 > > (Debian 5.2.1-24) ) #45 SMP PREEMPT Mon Nov 23 17:10:16 CET 2015 > > > > This time I also removed all files in /var/lib/btrfs to avoid any possible > > issues with saved BTRFS status reports. (Yeah, I think it would have been > > enough to just delete the one for the filesystem with that UUID.) > > > > As written this bug also happens with a single device BTRFS. > > > > > > I´d report a bug report, in case anyone would be interested. But if the > > interest it like in this mailinglist post I can spare myself the time for > > reporting via bugzilla. > > > > So does anyone at all care about this issue? > > I am replying to this a fourth time in the hope that someone can at least > give some suggestion on how to move forward with this. It was a third time, and well: I now have 4.4-rc5 running, the boot crash I had appears to be fixed. Oh, and I see that scrubbing / at leasted worked now: merkaba:~> btrfs scrub status -d / scrub status for […] scrub device /dev/dm-5 (id 1) history scrub started at Wed Dec 16 00:13:20 2015 and finished after 00:01:42 total bytes scrubbed: 23.94GiB with 0 errors scrub device /dev/mapper/msata-debian (id 2) history scrub started at Wed Dec 16 00:13:20 2015 and finished after 00:01:34 total bytes scrubbed: 23.94GiB with 0 errors I will check with other BTRFS filesystems tomorrow and report back whether scrubbing is stable for meagain. Ciao, -- Martin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [4.3-rc4] scrubbing aborts before finishing (SOLVED) 2015-12-15 23:18 ` [4.3-rc4] scrubbing aborts before finishing (probably solved) Martin Steigerwald @ 2015-12-17 13:29 ` Martin Steigerwald 0 siblings, 0 replies; 9+ messages in thread From: Martin Steigerwald @ 2015-12-17 13:29 UTC (permalink / raw) To: linux-btrfs Am Mittwoch, 16. Dezember 2015, 00:18:53 CET schrieb Martin Steigerwald: > Am Montag, 14. Dezember 2015, 08:59:59 CET schrieb Martin Steigerwald: > > Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie: > > > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald: > > > > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin > Steigerwald: > > > > > I get this: > > > > > > > > > > merkaba:~> btrfs scrub status -d / > > > > > scrub status for […] > > > > > scrub device /dev/mapper/sata-debian (id 1) history > > > > > > > > > > scrub started at Thu Oct 22 10:05:49 2015 and was aborted > > > > > after > > > > > 00:00:00 > > > > > total bytes scrubbed: 0.00B with 0 errors > > > > > > > > > > scrub device /dev/dm-2 (id 2) history > > > > > > > > > > scrub started at Thu Oct 22 10:05:49 2015 and was aborted > > > > > after > > > > > 00:01:30 > > > > > total bytes scrubbed: 23.81GiB with 0 errors > > > > > > > > > > For / scrub aborts for sata SSD immediately. > > > > > > > > > > For /home scrub aborts for both SSDs at some time. […] > I now have 4.4-rc5 running, the boot crash I had appears to be fixed. Oh, > and I see that scrubbing / at leasted worked now: > > merkaba:~> btrfs scrub status -d / > scrub status for […] > scrub device /dev/dm-5 (id 1) history > scrub started at Wed Dec 16 00:13:20 2015 and finished after > 00:01:42 total bytes scrubbed: 23.94GiB with 0 errors > scrub device /dev/mapper/msata-debian (id 2) history > scrub started at Wed Dec 16 00:13:20 2015 and finished after > 00:01:34 total bytes scrubbed: 23.94GiB with 0 errors > > I will check with other BTRFS filesystems tomorrow and report back whether > scrubbing is stable for meagain. This appears to be fixed with 4.4-rc5. Thank you!!! Thanks, -- Martin ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-12-17 13:29 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-10-22 8:41 [4.3-rc4] scrubbing aborts before finishing Martin Steigerwald 2015-10-31 11:10 ` Martin Steigerwald 2015-11-25 15:35 ` Martin Steigerwald 2015-11-26 16:39 ` Duncan 2015-12-14 7:59 ` Martin Steigerwald 2015-12-14 17:31 ` Henk Slager 2015-12-14 18:11 ` Henk Slager 2015-12-15 23:18 ` [4.3-rc4] scrubbing aborts before finishing (probably solved) Martin Steigerwald 2015-12-17 13:29 ` [4.3-rc4] scrubbing aborts before finishing (SOLVED) Martin Steigerwald
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).