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 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.