From: Martin Steigerwald <martin@lichtvoll.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: [4.3-rc4] scrubbing aborts before finishing
Date: Mon, 14 Dec 2015 08:59:59 +0100 [thread overview]
Message-ID: <2196957.diBSeBoUhe@merkaba> (raw)
In-Reply-To: <4738187.k1WenrURk2@merkaba>
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
next prev parent reply other threads:[~2015-12-14 8:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2196957.diBSeBoUhe@merkaba \
--to=martin@lichtvoll.de \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.