On 11/21/2015 01:47 PM, Qu Wenruo wrote as excerpted:
> Hard to say, but we'd better keep an eye on this issue.
> At least, if it happens again, we should know if it's related to
> something like newer kernel or snapshots.
I can confirm the initially describe behavior of "btrfs check" and
reading the data works fine also.
Versions etc.:
$ uname -a
Linux 4.2.0-0.bpo.1-amd64 #1 SMP Debian 4.2.6-1~bpo8+1 …
$ btrfs filesystem show /mnt/data
Label: none uuid: 5be372f5-5492-4f4b-b641-c14f4ad8ae23
Total devices 6 FS bytes used 2.87TiB
devid 1 size 931.51GiB used 636.00GiB path /dev/mapper/…SZ
devid 2 size 931.51GiB used 634.03GiB path /dev/mapper/…03
devid 3 size 1.82TiB used 1.53TiB path /dev/mapper/…76
devid 4 size 1.82TiB used 1.53TiB path /dev/mapper/…78
devid 6 size 1.82TiB used 1.05TiB path /dev/mapper/…UK
*** Some devices missing
btrfs-progs v4.3
$ btrfs subvolume list /mnt/data | wc -l
62
Best,
Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
