On Thu, Aug 27, 2015 at 11:33 AM, Mike Aubury <mike@xxxxxxxxx> wrote: > # 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 <lists@xxxxxxxxxxxxxxxxx> wrote: >> On Thu, Aug 27, 2015 at 11:18 AM, Mike Aubury <mike@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- Chris Murphy -- 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
