From: "Konstantin V. Gavrilenko" <k.gavrilenko@arhont.com>
To: Linux fs Btrfs <linux-btrfs@vger.kernel.org>
Subject: super_total_bytes 32004083023872 mismatch with fs_devices total_rw_bytes 64008166047744
Date: Tue, 24 Oct 2017 10:20:15 +0100 (BST) [thread overview]
Message-ID: <13409678.203.1508836811909.JavaMail.gkos@dynomob> (raw)
In-Reply-To: <7560696.184.1508834006162.JavaMail.gkos@dynomob>
Hi list,
having installed the recent kernel version I am no longer able to mount the btrfs partition with compression on the first attempt. Previously on 4.10.0-37-generic everything was working fine, once I switched to 4.13.9-041309-generic I started getting the following error while trying to mount it with the same options "compress-force=zlib,space_cache=v2"
[ 204.596381] BTRFS error (device sda): open_ctree failed
[ 204.631895] BTRFS info (device sda): force zlib compression
[ 204.631901] BTRFS info (device sda): using free space tree
[ 204.631903] BTRFS info (device sda): has skinny extents
[ 204.890145] BTRFS error (device sda): super_total_bytes 32004083023872 mismatch with fs_devices total_rw_bytes 64008166047744
[ 204.891276] BTRFS error (device sda): failed to read chunk tree: -22
[ 204.944333] BTRFS error (device sda): open_ctree failed
For some reason, the super_total_bytes is exactly half of total_rw_bytes.
however, if after unsuccessful first mount attempt, I mount it with minimum number of options "space_cache=v2" the partition mounts. Then I umount it, and mount normally, with full set of options "compress-force=zlib,space_cache=v2" it mounts without an error.
I also observed the same error on 4.12.14-041214-generic
Any ideas why this might be happening?
System information
distribution: Ubuntu 16.04
btrfs-progs v4.8.1 later upgraded to v4.13.3
# btrfs fi usage /mnt/backup
Overall:
Device size: 29.11TiB
Device allocated: 18.04TiB
Device unallocated: 11.07TiB
Device missing: 0.00B
Used: 17.99TiB
Free (estimated): 11.12TiB (min: 5.58TiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Data,single: Size:17.93TiB, Used:17.88TiB
/dev/sda 17.93TiB
Metadata,DUP: Size:53.50GiB, Used:51.78GiB
/dev/sda 107.00GiB
System,DUP: Size:8.00MiB, Used:2.30MiB
/dev/sda 16.00MiB
Unallocated:
/dev/sda 11.07TiB
Yours sincerely,
Konstantin V. Gavrilenko
next parent reply other threads:[~2017-10-24 9:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <7560696.184.1508834006162.JavaMail.gkos@dynomob>
2017-10-24 9:20 ` Konstantin V. Gavrilenko [this message]
2017-10-24 9:37 ` super_total_bytes 32004083023872 mismatch with fs_devices total_rw_bytes 64008166047744 Qu Wenruo
[not found] ` <14075786.243.1508845404640.JavaMail.gkos@dynomob>
2017-10-24 13:44 ` Qu Wenruo
2017-10-24 19:02 ` Konstantin V. Gavrilenko
2019-03-19 22:36 ` Piotr Balwierz
2019-03-20 0:58 ` Qu Wenruo
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=13409678.203.1508836811909.JavaMail.gkos@dynomob \
--to=k.gavrilenko@arhont.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).