Re: Raid0 rescue

2017-08-16 Thread Chris Murphy
OK this time, also -mraid1 -draid0, and filled it with some more metadata this time, but I then formatted NTFS, then ext4, then xfs. And then wiped those signatures. Brutal, especially ext4 which writes a lot more stuff and zeros a bunch of areas too. # btrfs rescue super -v /dev/mapper/vg-2

Re: Raid0 rescue

2017-08-16 Thread Chris Murphy
I'm testing explicitly for this case: # lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert 1 vg Vwi-a-tz-- 10.00g thintastic0.00 2 vg Vwi-a-tz-- 10.00g thintastic0.00 thintastic vg twi-aotz-- 100.00g

Re: Raid0 rescue

2017-08-01 Thread Chris Murphy
On Tue, Aug 1, 2017 at 12:36 PM, Alan Brand wrote: > I successfully repaired the superblock, copied it from one of the backups. > My biggest problem now is that the UUID for the disk has changed due > to the reformatting and no longer matches what is in the metadata. > I

Re: Raid0 rescue

2017-08-01 Thread Chris Murphy
On Thu, Jul 27, 2017 at 8:49 AM, Alan Brand wrote: > I know I am screwed but hope someone here can point at a possible solution. > > I had a pair of btrfs drives in a raid0 configuration. One of the > drives was pulled by mistake, put in a windows box, and a quick NTFS >

Re: Raid0 rescue

2017-07-27 Thread Adam Borowski
On Thu, Jul 27, 2017 at 08:25:19PM +, Duncan wrote: > >Welcome to RAID-0... > > As Hugo implies, RAID-0 mode, not just for btrfs but in general, is well > known among admins for being "garbage data not worth trying to recover" > mode. Not only is there no redundancy, but with raid0

Re: Raid0 rescue

2017-07-27 Thread Duncan
Hugo Mills posted on Thu, 27 Jul 2017 15:10:38 + as excerpted: > On Thu, Jul 27, 2017 at 10:49:37AM -0400, Alan Brand wrote: >> I know I am screwed but hope someone here can point at a possible >> solution. >> >> I had a pair of btrfs drives in a raid0 configuration. One of the >> drives

Re: Raid0 rescue

2017-07-27 Thread Alan Brand
> > Correct, I should have said 'superblock'. > > It is/was raid0. Funny thing is that this all happened when I was > > prepping to convert to raid1. >If youre metadata was also RAID-0, then your filesystem is almost > certainly toast. If any part of the btrfs metadata was overwritten by >

Re: Raid0 rescue

2017-07-27 Thread Hugo Mills
On Thu, Jul 27, 2017 at 03:43:37PM -0400, Alan Brand wrote: > Correct, I should have said 'superblock'. > It is/was raid0. Funny thing is that this all happened when I was > prepping to convert to raid1. If youre metadata was also RAID-0, then your filesystem is almost certainly toast. If any

Re: Raid0 rescue

2017-07-27 Thread Alan Brand
Correct, I should have said 'superblock'. It is/was raid0. Funny thing is that this all happened when I was prepping to convert to raid1. running a btrfs-find-root shows this (which gives me hope) Well block 4871870791680(gen: 73257 level: 1) seems good, but generation/level doesn't match, want

Re: Raid0 rescue

2017-07-27 Thread Hugo Mills
On Thu, Jul 27, 2017 at 10:49:37AM -0400, Alan Brand wrote: > I know I am screwed but hope someone here can point at a possible solution. > > I had a pair of btrfs drives in a raid0 configuration. One of the > drives was pulled by mistake, put in a windows box, and a quick NTFS > format was

Raid0 rescue

2017-07-27 Thread Alan Brand
I know I am screwed but hope someone here can point at a possible solution. I had a pair of btrfs drives in a raid0 configuration. One of the drives was pulled by mistake, put in a windows box, and a quick NTFS format was done. Then much screaming occurred. I know the data is still there. Is