Hi, thanks for the reply. Yes, I agree, after going back over the commands, those ones you highlighted seem very suspicious.... These commands were executed weeks ago amid a fair amount of confusion.
But yes, I think that you are right - from memory the FS became inaccessible at about the time you mention. I would say that was the best theory as regards this problem. Assuming that this is the case, do I stand a chance of retrieving that volume and accessing that data again? Or does "destructive" imply total loss? (In which case, I'll cut my losses....) On 3 January 2012 21:49, C Anthony Risinger <anth...@xtfx.me> wrote: > > On Tue, Jan 3, 2012 at 8:44 AM, Dan Garton <dan.gar...@gmail.com> wrote: > > > > [...] > > 1327 btrfs-vol -a > > 1328 btrfs-vol -a /nuvat > > 1329 btrfs-vol -a asdasd /nuvat > > 1330 btrfs-vol -a missing /nuvat > > 1331 btrfs-vol -a /dev/sdc /nuvat > > 1332 btrfs-vol -a /dev/sdb /nuvat > > 1334 btrfs-vol -a missing /nuvat > > [...] > > these look destructive to me ... adding the wrong devices and the > existing devices back to the current array? IIRC you should have `-r > missing`, but in general, do not use the btrfsctl utility at all -- it > won't have as much visibility/exception-handling/recovery as the > `btrfs` utility. > > at what point did your FS become inaccessible? your command history > suggest it was working until shortly after these commands ... :-( > > -- > > C Anthony -- 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
