From: Kai Krakow <hurikhan77@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: bad metadata crossing stripe boundary (was: csum errors in VirtualBox VDI files)
Date: Mon, 28 Mar 2016 12:02:03 +0200 [thread overview]
Message-ID: <20160328120203.1b8d79dc@jupiter.sol.kaishome.de> (raw)
In-Reply-To: 56F7E65C.7020300@gmx.com
Changing subject to reflect the current topic...
Am Sun, 27 Mar 2016 21:55:40 +0800
schrieb Qu Wenruo <quwenruo.btrfs@gmx.com>:
> > I finally got copy&paste data:
> >
> > # before mounting let's check the FS:
> >
> > $ sudo btrfsck /dev/disk/by-label/usb-backup
> > Checking filesystem on /dev/disk/by-label/usb-backup
> > UUID: 1318ec21-c421-4e36-a44a-7be3d41f9c3f
> > checking extents
> > bad metadata [156041216, 156057600) crossing stripe boundary
> > bad metadata [181403648, 181420032) crossing stripe boundary
> > bad metadata [392167424, 392183808) crossing stripe boundary
> > bad metadata [783482880, 783499264) crossing stripe boundary
> > bad metadata [784924672, 784941056) crossing stripe boundary
> > bad metadata [130151612416, 130151628800) crossing stripe boundary
> > bad metadata [162826813440, 162826829824) crossing stripe boundary
> > bad metadata [162927083520, 162927099904) crossing stripe boundary
> > bad metadata [619740659712, 619740676096) crossing stripe boundary
> > bad metadata [619781947392, 619781963776) crossing stripe boundary
> > bad metadata [619795644416, 619795660800) crossing stripe boundary
> > bad metadata [619816091648, 619816108032) crossing stripe boundary
> > bad metadata [620011388928, 620011405312) crossing stripe boundary
> > bad metadata [890992459776, 890992476160) crossing stripe boundary
> > bad metadata [891022737408, 891022753792) crossing stripe boundary
> > bad metadata [891101773824, 891101790208) crossing stripe boundary
> > bad metadata [891301199872, 891301216256) crossing stripe boundary
> > bad metadata [1012219314176, 1012219330560) crossing stripe boundary
> > bad metadata [1017202409472, 1017202425856) crossing stripe boundary
> > bad metadata [1017365397504, 1017365413888) crossing stripe boundary
> > bad metadata [1020764422144, 1020764438528) crossing stripe boundary
> > bad metadata [1251103342592, 1251103358976) crossing stripe boundary
> > bad metadata [1251144695808, 1251144712192) crossing stripe boundary
> > bad metadata [1251147055104, 1251147071488) crossing stripe boundary
> > bad metadata [1259271225344, 1259271241728) crossing stripe boundary
> > bad metadata [1266223611904, 1266223628288) crossing stripe boundary
> > bad metadata [1304750063616, 1304750080000) crossing stripe boundary
> > bad metadata [1304790106112, 1304790122496) crossing stripe boundary
> > bad metadata [1304850792448, 1304850808832) crossing stripe boundary
> > bad metadata [1304869928960, 1304869945344) crossing stripe boundary
> > bad metadata [1305089540096, 1305089556480) crossing stripe boundary
> > bad metadata [1309561651200, 1309561667584) crossing stripe boundary
> > bad metadata [1309581443072, 1309581459456) crossing stripe boundary
> > bad metadata [1309583671296, 1309583687680) crossing stripe boundary
> > bad metadata [1309942808576, 1309942824960) crossing stripe boundary
> > bad metadata [1310050549760, 1310050566144) crossing stripe boundary
> > bad metadata [1313031585792, 1313031602176) crossing stripe boundary
> > bad metadata [1313232912384, 1313232928768) crossing stripe boundary
> > bad metadata [1555210764288, 1555210780672) crossing stripe boundary
> > bad metadata [1555395182592, 1555395198976) crossing stripe boundary
> > bad metadata [2050576744448, 2050576760832) crossing stripe boundary
> > bad metadata [2050803957760, 2050803974144) crossing stripe boundary
> > bad metadata [2050969108480, 2050969124864) crossing stripe
> > boundary
>
> Already mentioned in another reply, this *seems* to be false alert.
> Latest btrfs-progs would help.
No, btrfs-progs 4.5 reports those, too (as far as I understood, this
includes the fixes for bogus "bad metadata" errors, tho I thought this
has already been fixed in 4.2.1, I used 4.4.1). There were some nbytes
wrong errors before which I already repaired using "--repair". I think
that's okay, I had those in the past and it looks like btrfsck can
repair those now (and I don't have to delete and recreate the files).
It caused problems with "du" and "df" in the past, a problem that I'm
currently facing too. So I better fixed them.
With that done, the backup fs now only reports "bad metadata" which
have been there before space cache v2. Full output below.
> > checking free space tree cache and super generation don't match,
> > space cache will be invalidated checking fs roots
> Err, I found a missing '\n' before "checking fs roots".
Copy and paste problem. Claws mail pretends to be smarter than me
- I missed to fix that one. ;-)
> And it seems that fs roots and extent tree are all OK.
>
> Quite surprising.
> The only possible problem seems to be outdated space cache.
>
> Maybe mount with "-o clear_cache" will help, but I don't think that's
> the cause.
Helped, it automatically reverted the FS back to space cache v1 with
incompat flag cleared. (I wouldn't have enabled v2 if it wasn't
documented that this is possible)
> > checking csums
> > checking root refs
> > found 1860217443214 bytes used err is 0
> > total csum bytes: 1805105116
> > total tree bytes: 11793776640
> > total fs tree bytes: 8220835840
> > total extent tree bytes: 1443315712
> > btree space waste bytes: 2307850845
> > file data blocks allocated: 2137151094784
> > referenced 2706830905344
> >
> > # now let's wait for the backup to mount the FS and look at dmesg:
> >
> > [21375.606479] BTRFS info (device sde1): force zlib compression
> > [21375.606483] BTRFS info (device sde1): using free space tree
>
> Thanks to Chris Murphy, I almost ignored such line.
> Not familiar with the new free space cache tree, sorry.
>
> If "clear_cache" doesn't help, then try "nospace_cache" to disable
> the entire space cache.
It's gone now, ignore that. It's back to the situation before space
cache v2. Minus some "nbytes wrong" errors I had and fixed.
Nevertheless, I'm now using btrfs-progs 4.5. Here's the full output:
(the lines seem to be partly out of order, probably due to the
redirection)
$ sudo btrfsck /dev/sde1 2>&1 | tee btrfsck-label-usb-backup.txt
checking extents
bad metadata [156041216, 156057600) crossing stripe boundary
bad metadata [181403648, 181420032) crossing stripe boundary
bad metadata [392167424, 392183808) crossing stripe boundary
bad metadata [783482880, 783499264) crossing stripe boundary
bad metadata [784924672, 784941056) crossing stripe boundary
bad metadata [130151612416, 130151628800) crossing stripe boundary
bad metadata [162826813440, 162826829824) crossing stripe boundary
bad metadata [162927083520, 162927099904) crossing stripe boundary
bad metadata [619740659712, 619740676096) crossing stripe boundary
bad metadata [619781947392, 619781963776) crossing stripe boundary
bad metadata [619795644416, 619795660800) crossing stripe boundary
bad metadata [619816091648, 619816108032) crossing stripe boundary
bad metadata [620011388928, 620011405312) crossing stripe boundary
bad metadata [890992459776, 890992476160) crossing stripe boundary
bad metadata [891022737408, 891022753792) crossing stripe boundary
bad metadata [891101773824, 891101790208) crossing stripe boundary
bad metadata [891301199872, 891301216256) crossing stripe boundary
bad metadata [1012219314176, 1012219330560) crossing stripe boundary
bad metadata [1017202409472, 1017202425856) crossing stripe boundary
bad metadata [1017365397504, 1017365413888) crossing stripe boundary
bad metadata [1020764422144, 1020764438528) crossing stripe boundary
bad metadata [1251103342592, 1251103358976) crossing stripe boundary
bad metadata [1251145809920, 1251145826304) crossing stripe boundary
bad metadata [1251147055104, 1251147071488) crossing stripe boundary
bad metadata [1259271225344, 1259271241728) crossing stripe boundary
bad metadata [1266223611904, 1266223628288) crossing stripe boundary
bad metadata [1304750063616, 1304750080000) crossing stripe boundary
bad metadata [1304790106112, 1304790122496) crossing stripe boundary
bad metadata [1304850792448, 1304850808832) crossing stripe boundary
bad metadata [1304869928960, 1304869945344) crossing stripe boundary
bad metadata [1305089540096, 1305089556480) crossing stripe boundary
bad metadata [1309581443072, 1309581459456) crossing stripe boundary
bad metadata [1309583671296, 1309583687680) crossing stripe boundary
bad metadata [1309942808576, 1309942824960) crossing stripe boundary
bad metadata [1310050549760, 1310050566144) crossing stripe boundary
bad metadata [1313031585792, 1313031602176) crossing stripe boundary
bad metadata [1313232912384, 1313232928768) crossing stripe boundary
bad metadata [1555210764288, 1555210780672) crossing stripe boundary
bad metadata [1555395182592, 1555395198976) crossing stripe boundary
bad metadata [2050576744448, 2050576760832) crossing stripe boundary
bad metadata [2050803957760, 2050803974144) crossing stripe boundary
bad metadata [2050969108480, 2050969124864) crossing stripe boundary
checking free space cache
checking fs roots
checking csums
checking root refs
Checking filesystem on /dev/sde1
UUID: 1318ec21-c421-4e36-a44a-7be3d41f9c3f
found 1860212384661 bytes used err is 0
total csum bytes: 1805105124
total tree bytes: 11788713984
total fs tree bytes: 8220835840
total extent tree bytes: 1443282944
btree space waste bytes: 2306453698
file data blocks allocated: 2137152151552
referenced 2706831974400
That drive was not converted so either "bad metadata" is still a false
alert or there is something else going wrong in btrfs.
--
Regards,
Kai
Replies to list-only preferred.
next prev parent reply other threads:[~2016-03-28 10:10 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 8:03 csum errors in VirtualBox VDI files Kai Krakow
2016-03-22 8:06 ` Kai Krakow
2016-03-22 8:07 ` Kai Krakow
2016-03-22 8:47 ` Qu Wenruo
2016-03-22 18:48 ` Kai Krakow
2016-03-22 19:42 ` Chris Murphy
2016-03-22 20:35 ` Kai Krakow
2016-03-23 4:16 ` Qu Wenruo
2016-03-26 19:30 ` Kai Krakow
2016-03-26 20:28 ` Chris Murphy
2016-03-26 21:04 ` Chris Murphy
2016-03-27 1:30 ` Kai Krakow
2016-03-27 4:57 ` Chris Murphy
2016-03-27 17:31 ` Kai Krakow
2016-03-27 19:04 ` Chris Murphy
2016-03-28 10:30 ` Kai Krakow
2016-03-27 1:01 ` Kai Krakow
2016-03-27 1:50 ` Kai Krakow
2016-03-27 4:43 ` Chris Murphy
2016-03-27 13:55 ` Qu Wenruo
2016-03-28 10:02 ` Kai Krakow [this message]
2016-03-31 1:33 ` bad metadata crossing stripe boundary Qu Wenruo
2016-03-31 2:31 ` Qu Wenruo
2016-03-31 20:27 ` Kai Krakow
2016-03-31 20:37 ` Henk Slager
2016-03-31 21:00 ` Marc Haber
2016-03-31 21:16 ` Kai Krakow
2016-03-31 21:35 ` Kai Krakow
2016-04-01 5:57 ` Marc Haber
2016-04-02 9:03 ` Kai Krakow
2016-04-02 9:44 ` Marc Haber
2016-04-02 18:31 ` Kai Krakow
2016-04-02 19:39 ` Patrik Lundquist
2016-04-03 8:39 ` Marc Haber
2016-04-02 19:41 ` Chris Murphy
2016-04-03 8:51 ` Marc Haber
2016-04-03 18:29 ` Chris Murphy
2016-03-27 13:46 ` csum errors in VirtualBox VDI files Qu Wenruo
2016-03-22 20:07 ` Henk Slager
2016-03-22 21:23 ` Kai Krakow
2016-03-27 12:18 ` Martin Steigerwald
2016-03-27 16:53 ` Kai Krakow
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=20160328120203.1b8d79dc@jupiter.sol.kaishome.de \
--to=hurikhan77@gmail.com \
--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 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).