# btrfs dev scan
Scanning for Btrfs filesystems
(back to # prompt)
# mount -o ro,degraded /data
Seems to work, /data is mounted
# btrfs fi show
Label: '0e36d290:data' uuid: e75a9856-d9e5-4d02-92e6-a217056c69b7
Total devices 4 FS bytes used 6.09TiB
devid 1 size 2.71TiB used 2.71TiB path /dev/md127
devid 2 size 1.82TiB used 1.82TiB path /dev/md126
devid 3 size 1.82TiB used 1.82TiB path /dev/md125
*** Some devices missing
Where next ?
On 27 August 2015 at 18:27, Chris Murphy <li...@colorremedies.com> wrote:
> On Thu, Aug 27, 2015 at 11:18 AM, Mike Aubury <m...@aubit.com> wrote:
>> Offlist - thanks for the help so far..
>
> No, I'm changing it back to onlist. It's not appropriate to take this offlist.
>
> This whole conversation is relevant to others who end up in this same
> situation. And the ReadyNAS folks should have better support for this,
> you paid them money for this product, and it was their choice to use
> Btrfs. They should support you. But in the meantime the Btrfs list is
> the right place for the discussion.
>
>
>>
>>
>> The loop device is still there
>>
>> # losetup -a
>> /dev/loop0: [0861]:198 (/media/USB_HDD_1/t1/tmpbtrfs)
>>
>> But doesnt seem to be being picked up :
>>
>> # btrfs fi show
>> warning devid 4 not found already
>> Label: '0e36d290:data' uuid: e75a9856-d9e5-4d02-92e6-a217056c69b7
>> Total devices 4 FS bytes used 6.09TiB
>> devid 1 size 2.71TiB used 2.71TiB path /dev/md127
>> devid 2 size 1.82TiB used 1.82TiB path /dev/md126
>> devid 3 size 1.82TiB used 1.82TiB path /dev/md125
>> *** Some devices missing
>
>
> Try
>
> # btrfs dev scan
>
>
>> Trying a mount in that state gives :
>>
>> # mount /data
>> mount: wrong fs type, bad option, bad superblock on /dev/md126,
>> missing codepage or helper program, or other error
>> In some cases useful info is found in syslog - try
>> dmesg | tail or so
>>
>> dmesg gives :
>> btrfs: failed to read chunk tree on md125
>> btrfs: open_ctree failed
>
> If dev scan doesn't work you could try to mount with -o ro,degraded
> but I do not recommend it until you fist explore all options to make
> btrfs aware of this loop back device.
>
> In the future I think it's better to use the USB stick directly rather
> than loopback files which just adds more complexity to an already
> fragile situation.
>
>
>> FWIW - When I used the usb file - it never had any "usage" reported in
>> the "fi show" - used was always 0GB, I think the thing is just totally
>> messed up, and all i've done is mess it up more!
>
> There is at least some metadata on it, or it wouldn't be get fussy
> that the device is missing. So you need to get the loop back device
> visible to Btrfs and then it will almost certainly mount at least ro
> at which point you can get data off of it first; and then you can deal
> with the btrfs dev delete part.
>
>
>
>
>
> --
> 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
--
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
