http://bugzilla.suse.com/show_bug.cgi?id=1043912
http://bugzilla.suse.com/show_bug.cgi?id=1043912#c40
--- Comment #40 from Nikolay Borisov ---
So in your case the bytes used for the super are indeed smaller than the total
bytes of the device even after the rounding. This could cause the issue.
However, I don't understand how this could happen. I just tried similar
scenario on the rpm tag of your kernel (which has the rounding down fixes and
here is what I've got)
sle12sp3:~ # lsblk -b
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 2147487744 0 loop /media/scratch
So first I created a device which is 2g+4kb big:
sle12sp3:~ # btrfs inspect dump-tree /dev/loop0 | grep total
dev item devid 1 total_bytes 2147487744 bytes used 239861760
total bytes 2147487744
sle12sp3:~ # btrfs inspect dump-super /dev/loop0 | grep total
total_bytes 2147487744
dev_item.total_bytes 2147487744
So both the device item and the size in super block show the correct size.
I then decrease it by 512 bytes, so the device size would be 2147487744 - 512 =
2147487232, which is 3584 bytes above rounded 2g. This should simulate your
"broken" btrfs volume.
sle12sp3:~ # btrfs fi resize 1:-512 /media/scratch/ && sync
Resize '/media/scratch/' of '1:-512'
Printing again the state of the tree and super block:
sle12sp3:~ # btrfs inspect dump-tree /dev/loop0 | grep total
dev item devid 1 total_bytes 2147483648 bytes used 239861760
total bytes 2147483648
sle12sp3:~ # btrfs inspect dump-super /dev/loop0 | grep total
total_bytes 2147483648
dev_item.total_bytes 2147483648
So the 2 values match and are precisely rounded to 2g, which is the expected
behavior. I'm at a loss how you could have arrived at the numbers you show.
Just to recap, initially you had:
super: 1000203816960
dev: 1000203820544
Then after doing the resize with the patched kernel:
super: 1000203808768
device: 1000203812864
So the difference in the size of the super is 8kb so you shrunk your fs by this
much, correct? However, the difference in the device size is 7680 bytes rather
than 8kb. And it just happens that the resulting value is evenly divisible by
sectorsize, hence there is no need to round down. This causes superblock size
to be smaller than device and triggers the check.
--
You are receiving this mail because:
You are on the CC list for the bug.