Yes my error, definitely trying to install a cache disk. I thought the parity should be ok but I think it tried to start a parity check once early on during one of the restarts of V6 with no valid super.dat ie no Disk 3 available and teh system autostarted into a parity check. That was probably when data was lost. Entirely my bad.

It's difficult to tell if anything has been lost as I generally only save movies to it and they have been a bit thin recently. I only want to do a disk recovery to see if there is anything on there that isn't showing up when I do the restart with Disk 3 disconnected.

It's difficult to tell if anything has been lost as I generally only save movies to it and they have been a bit thin recently. I only want to do a disk recovery to see if there is anything on there that isn't showing up when I do the restart with Disk 3 disconnected.

The safest way forward is to rebuild the emulated disk3 slot on a new tested hard drive, then you at least have a protected array again. After the array is stable and you have what you can't afford to lose backed up elsewhere, if you want to try drastic file reconstruction on the fubared old disk3, at least you won't be going backwards if something doesn't work.

 

It's your call as to how much risk you want to put the rest of the array in vs. dealing with the disk3 recovery. Right now you have 2 different versions of disk3, one physical which has had its superblock overwritten along with who knows how much other data, and the emulated one that relies on every other disk in the array behaving perfectly until you finish a rebuild onto a physical disk. If you lose another disk right now, you WILL lose data, probably 2 disks worth.

 

Since the emulated disk3 sounds like it's at least showing a valid filesystem with files on it, I'd rebuild it onto a physical drive ASAP. Whether that's a new drive or overwriting the messed up disk is up to you.

Thanks Jonathan, it looks like there is no disk 3 data being emulated, stuff is missing. I can only assume the parity disk has tried to do a sync at some point. Im talking to Limetech by email but it looks like i will have to try to recover as much from disk 3 as i can get it to mount then rebuild parity. Its annoying but ultimately my fault. Live and learn.

OK I'm awake again. From these last few posts, there are a few things that are unclear to me.

 

Does unRAID say disk3 is reiserfs, or does it say it is unformatted?

 

It sounds as if you are looking at user shares to try to guess whether or not anything is missing from disk3. Is that because you can't look at disk3 because unRAID thinks it is unformatted?

 

Has any filesystem repair been attempted yet?

 

I think jonathanm has a good point about rebuilding onto a new disk. That will give you two different disks to attempt filesystem repair on, the original disk3 and the rebuilt disk3. They may both be unformatted but they may also be damaged in slightly different ways, one because parity was written to it, and the other because incorrect parity was used to rebuild it. Maybe trying to repair each of them would allow you to recover different things. Maybe not.

 

If you do rebuild onto a new disk, at least you will have a parity protected array again, like he said. Then you could try filesystem repair on the md device for the rebuilt disk while maintaining parity, and also try filesystem recovery on the sd device for the original disk3.

 

No guarantees any of this would get all or maybe even any of your files back so maybe more trouble than you want.

Morning,

 

Does unRAID say disk3 is reiserfs, or does it say it is unformatted?

disk3 reports as unformatted.

 

It sounds as if you are looking at user shares to try to guess whether or not anything is missing from disk3. Is that because you can't look at disk3 because unRAID thinks it is unformatted?

yes I am looking at user shares because disk 3 is not accessible because I unplugged it as per Jonathans suggestions

 

Has any filesystem repair been attempted yet?

No

 

I think jonathanm has a good point about rebuilding onto a new disk. That will give you two different disks to attempt filesystem repair on, the original disk3 and the rebuilt disk3. They may both be unformatted but they may also be damaged in slightly different ways, one because parity was written to it, and the other because incorrect parity was used to rebuild it. Maybe trying to repair each of them would allow you to recover different things. Maybe not.

Maybe, I am beginning to think another 3TB disk might be useful.

 

If you do rebuild onto a new disk, at least you will have a parity protected array again, like he said. Then you could try filesystem repair on the md device for the rebuilt disk while maintaining parity, and also try filesystem recovery on the sd device for the original disk3.

True

 

No guarantees any of this would get all or maybe even any of your files back so maybe more trouble than you want.

I consider myself an enthusiast so no trouble to do the job. I do wonder if it is worth it. If I had some faith the parity was OK or semi OK then for sure, Im just not sure. The system is protected at the moment because it's turned off.

 

... If I had some faith the parity was OK or semi OK then for sure, Im just not sure. The system is protected at the moment because it's turned off.

If you rebuild a data disk then parity will be valid. None of the other disks will be changed by the rebuild, and the rebuilt disk will be based on whatever parity and all the other disks have, so at the end of a rebuild parity is valid and could be used to rebuild one of the other disks if necessary.

 

If you are unclear how parity works the wiki has a good explanation. A lot of what I say is not based on personal experience but instead on an understanding of parity.

 

Are you running v5 now or v6? It might be useful to get smart reports from all disks if you haven't recently before attempting the rebuild just to make sure none of them are going to give any trouble.

 

 

Yes I understand parity and what you say is true if I install a fresh disk as disk 3. It's Sunday here now and no stores are open to sell me a new disk. Ill think on it until Monday and give Limetech a chance to offer some enlightenment. I do like the idea of adding a new disk and rebuilding just to see what is recovered. If nothing then I can still try a recovery of the original disk 3.

 

I've got it setup as V5 but it makes no difference to me to set up as V6 which I think I will do.

 

There is one thing that has me a bit confused. I have the system running with the Parity disk + disk 1 + disk 2 installed. disk 3 is unplugged. When I boot it up it correctly reports that disk 3 is missing. I then start the array and it sets the disk 3 position to unassigned. I understand that in this config I should still be able to see what was on disk 3 as the system would replicate it using parity and disk 1 and 2. That doesn't seem to happen as far as I can tell there is no disk 3 data available yet the parity disk is green ball and all looks fine. How do I know the information on the parity disk is OK or corrupted? Would that only be apparent if I did a parity sync (which I won't)? I know that sounds a bit confusing what I am trying to say is that there must be some data on the parity drive, why isn't that data being used to give me some replicated disk 3 information?

...

There is one thing that has me a bit confused. I have the system running with the Parity disk + disk 1 + disk 2 installed. disk 3 is unplugged. When I boot it up it correctly reports that disk 3 is missing. I then start the array and it sets the disk 3 position to unassigned. I understand that in this config I should still be able to see what was on disk 3 as the system would replicate it using parity and disk 1 and 2. That doesn't seem to happen as far as I can tell there is no disk 3 data available yet the parity disk is green ball and all looks fine. How do I know the information on the parity disk is OK or corrupted? Would that only be apparent if I did a parity sync (which I won't)? I know that sounds a bit confusing what I am trying to say is that there must be some data on the parity drive, why isn't that data being used to give me some replicated disk 3 information?

You said earlier

Yes my error, definitely trying to install a cache disk. I thought the parity should be ok but I think it tried to start a parity check once early on during one of the restarts of V6 with no valid super.dat ie no Disk 3 available and teh system autostarted into a parity check. That was probably when data was lost. Entirely my bad.

That might have overwritten the parity information that would allow the emulated disk to be seen as a valid filesystem that could be mounted. But if you stopped the parity check then it would still be able to reconstruct other parts of the disk that it hadn't got to yet, and maybe filesystem repair could get something out of that. So I think we can say that the parity disk is partially corrupted. unRAID doesn't really have any memory of what happened before the last boot except for what little bit it stores as the array configuration in super.dat, and parity is just a bunch of bits with no idea about filesystems, so it has no reason not to consider parity valid.

That sounds feasible, it would only be the first 100MB or so that could be overwritten before I stopped the parity sync. So if that contained the information needed to mount Disk 3 then no files would be available for emulation.

 

Given that I will probably have to do a file system repair on both disks in any event, maybe I should just go ahead and do the recovery on the current disk3 outside the array, if it fails I could then try the parity rebuild option and wouldn't need to purchase a new disk. I don't see too many downsides in that scenario. Assuming Tom doesn't have a surprise fix for the issue.

That sounds feasible, it would only be the first 100MB or so that could be overwritten before I stopped the parity sync. So if that contained the information needed to mount Disk 3 then no files would be available for emulation.

 

Given that I will probably have to do a file system repair on both disks in any event, maybe I should just go ahead and do the recovery on the current disk3 outside the array, if it fails I could then try the parity rebuild option and wouldn't need to purchase a new disk. I don't see too many downsides in that scenario. Assuming Tom doesn't have a surprise fix for the issue.

That sounds like it could work. I would not hold out for a surprise fix, since I'm pretty sure we have determined that nothing is going to allow a perfect rebuild.

 

Still might be a good idea to get smart reports if you haven't so we don't get surprised by another disk. And until you actually do a rebuild, you don't have parity protection.

I did actually confirm SMART was OK just a day or two ago but Ill check again.

 

I've asked Tom the question and he has been good enough to reply so Ill wait for him to come to the same conclusion as us or have a better fix.

Just to finish this thread off. Ran reiserfsck to rebiuld the superblock followed by a tree rebuild all on md3 (within the array). The emulated md3 was rebuilt with most everything intact, then reinserted disk3 as a new disk and a data rebuild started. Took forever but teh end state was a recovered system. A lot of directory names were lost but most files OK. Overall a tremendous result. I've just finished the V6 upgrade again and all is well. Thanks very much to all who assisted, couldn't have done it without you, and thanks to Tom who found the time to help me. great bunch.

I think I chose a data disk by mistake when I upgraded to v6. All drives are connected but the parity check keeps running.  All of my folders are there but the video file inside the folders is missing.

I think I chose a data disk by mistake when I upgraded to v6. All drives are connected but the parity check keeps running.  All of my folders are there but the video file inside the folders is missing.

I already replied to your other thread yesterday. Please continue discussion there.