On Tue, Jun 28, 2016 at 12:20 PM, Francesco Turco <ftu...@fastmail.fm> wrote: > On 2016-06-28 20:05, Chris Murphy wrote: >> Well it probably shouldn't crash but the question is why is device 4 >> missing? We have no information what version of btrfs-progs or kernel >> is used, or what the layout of this volume is: how many devices, >> what's the profile breakdown, etc. Are you attempting to fix a >> degraded volume and are the minimum number of devices present? Btrfs >> fi show would be useful for this. >> >> If it's relatively recent version of btrfs-progs then I'd file a bug >> just because it shouldn't crash, it should give some sort of coherent >> message about why it can't proceed. > > Sorry for the missing informations. Here you are: > > - linux-libre: 4.6.2 > - btrfs-progs: 4.5.3 > > # btrfs filesystem show /dev/loop0 > warning, device 4 is missing > Label: none uuid: 34fb5b58-f50f-47c3-a5b8-91d81a30eade > Total devices 2 FS bytes used 5.17GiB > devid 1 size 30.00GiB used 30.00GiB path /dev/loop0 > *** Some devices missing > > If I remember correctly I extended that root filesystem with some > additional space from a file in the home directory, in the hope of > fixing a problem with btrfs balance and not enough space. I don't have > the additional file anymore, so I probably won't be able to mount this > image file anymore. Anyway as you said btrfs-check shouldn't crash. > > So I'm going to submit a bug as you suggested.
Yeah depending on the layout, if the only copy of some important metadata is on the missing device, the btrfs check will naturally fail. It's just that to a human the messages are out of order... warning, device 4 is missing (therefore) Unable to find block group for 0 (And therefore fail to proceed... please find missing device 4) or some such. -- Chris Murphy -- 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
