After a power cut I have the following issue with one of my disks, a parity ran not long before hand and completed successfully so hopefully I haven't lost anything.

What's the best/safest way to resolve?

 

Status in file system check:

 

 

Phase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... would write modified primary superblock Primary superblock would have been modified. Cannot proceed further in no_modify mode. Exiting now.

 

 

 

Thanks in advance

unraid-diagnostics-20220811-2120.zip

Edited August 11, 20223 yr by DaFr0n
More Info

36 minutes ago, DaFr0n said:

parity ran not long before hand and completed successfully

parity won't help with unmountable

 

37 minutes ago, DaFr0n said:

file system check

How did you do this check?

Start the array in normal mode and attach new diagnostics to your NEXT post

7 minutes ago, trurl said:

parity won't help with unmountable

 

How did you do this check?

Booted in maintenence mode, clicked on the appropriate disk and ran the check. I may have jumped the gun but another post stated run with -L. 

This stated there was errors etc and done its thing. 

 

I just booted out of maintenence as you have said (with the disk in the array) and its got a yellow ⚠️..

I can now see the storage availability and it states a rebuild is in progress.

7 minutes ago, trurl said:

Start the array in normal mode and attach new diagnostics to your NEXT post

OK, attached

unraid-diagnostics-20220811-2243.zip

You didn't mention the disk was also disabled.

 

Of course rebuild is the whole point of parity, but better to repair the filesystem before rebuilding. In fact, I would say you shouldn't rebuild on top of the original disk unless you have already repaired the filesystem.

 

Looks like repair on the emulated disk worked, emulated disk3 mounted and rebuilding. Doesn't appear to be any lost+found, but it only has 183G data, is that expected?

1 minute ago, trurl said:

You didn't mention the disk was also disabled.

In fact, it was missing in those earlier diagnostics, but I can see it was also disabled, I didn't look in the right place.

1 minute ago, trurl said:

You didn't mention the disk was also disabled.

 

Of course rebuild is the whole point of parity, but better to repair the filesystem before rebuilding. In fact, I would say you shouldn't rebuild on top of the original disk unless you have already repaired the filesystem.

 

Looks like repair on the emulated disk worked, emulated disk3 mounted and rebuilding. Doesn't appear to be any lost+found, but it only has 183G data, is that expected?

Hi sorry for not mentioning that, first time this has happened. I have had a disk ❌️ which needed to be rebuilt but never this issue. Would running in maintenence mode using the xfs repair with -L repair the disk. If so I did do that. 

 

Yes the 183G is about right for that drive

TBH I think it's time to get a better controller, assume this could also be contributing to the issue?

 

 

4 minutes ago, DaFr0n said:

Would running in maintenence mode using the xfs repair with -L repair the disk

yes, but sometimes not perfectly. Since the disk was disabled, repair was on the emulated disk, not the physical disk. Now emulated disk is rebuilding to physical disk.

 

The reason I said you shouldn't rebuild on top until repaired is because it might be possible to get a different result from the physical disk instead of the emulated disk if things didn't go well.

Ahhh so it could still fail?

1 minute ago, DaFr0n said:

Ahhh so it could still fail?

I often confuse people by giving them more information than they need.

 

Of course anything can fail at any time, but since the emulated disk looks good, and the emulated disk is currently being written to the physical disk, then assuming nothing goes wrong while rebuilding, it should be OK. And even if something does go wrong it would probably be possible to try again depending on the details.

15 minutes ago, DaFr0n said:

TBH I think it's time to get a better controller, assume this could also be contributing to the issue?

Marvell controllers are not recommended. I'm still trying to work out if that is the controller the disk was on.

2 minutes ago, trurl said:

I often confuse people by giving them more information than they need.

 

Of course anything can fail at any time, but since the emulated disk looks good, and the emulated disk is currently being written to the physical disk, then assuming nothing goes wrong while rebuilding, it should be OK. And even if something does go wrong it would probably be possible to try again depending on the details.

Thank you for the help. Much appreciated 

Even though disk3 was not assigned in those earlier diagnostics, I can see it was sdh in both diagnostics, and sdh is on the Marvell controller.

1 minute ago, trurl said:

Marvell controllers are not recommended. I'm still trying to work out if that is the controller the disk was on.

Yes it is as I checked the cables first. Would a Dell Perc H310 flashed to IT be a better option?

2 minutes ago, DaFr0n said:

Would a Dell Perc H310 flashed to IT be a better option

Looks like that one is mentioned here:

 

Brilliant, thank you again. Any issues with rebuilding I will drop a update here.