On 2017年10月24日 17:20, Konstantin V. Gavrilenko wrote: > 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 Such problem can be easily fixed with this branch: https://github.com/adam900710/btrfs-progs/tree/check_unaligned_dev Use "btrfs rescue fix-device-size" should handle it well. But the problem is, normally the super_total_bytes should only be less than 4K smaller than total device size. Unless something else went wrong, it should not have such large difference. > > 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? Would you please provide super dump by: # btrfs inspect-internal dump-super -fa /dev/sda (Although I don't think it will be very interesting since it can be mounted later) And device tree dump by: # btrfs inspect-internal dump-tree -t dev /dev/sda Normally it should not be mountable after v4.6 kernel if super_total_bytes mismatch, but I'm more interested in how it mounted successfully. And BTW, are you using x86_64 kernel or x86 kernel? I don't think it's related in your case, but some reports about 32bit kernel has strange bugs are in mail list, so just in case. Thanks, Qu > > > > 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 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Attachment:
signature.asc
Description: OpenPGP digital signature
