Disabled disk due to read errors. How to shrink or repair?

[Zookeeper4094]

Hello, 

 

Looking for a bit of advice on how to deal with a disabled disk in Unraid. Disk has been disabled due to read/write errors and is showing as 'disabled'. 

 

Quote

Aug 26 06:40:37 tower kernel: sd 5:0:2:0: [sdd] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00
Aug 26 06:40:37 tower kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO
Aug 26 06:40:37 tower kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO
Aug 26 06:40:37 tower kernel: mpt2sas_cm0: mpt3sas_transport_port_remove: removed: sas_addr(0x4433221102000000)
Aug 26 06:40:37 tower kernel: mpt2sas_cm0: removing handle(0x000a), sas_addr(0x4433221102000000)
Aug 26 06:40:37 tower kernel: mpt2sas_cm0: enclosure logical id(0x500605b0061b3240), slot(5)
Aug 26 06:40:37 tower rc.diskinfo[9430]: SIGHUP received, forcing refresh of disks info.
r21-20020aa7d155000000b0043cc66d7accsm1979233edo.36 - gsmtp) uid=0 username=root outbytes=1304
Aug 27 01:16:00 tower kernel: md: disk1 read error, sector=7336960840
Aug 27 01:16:00 tower kernel: md: disk1 read error, sector=7336960848
Aug 27 01:16:00 tower kernel: md: disk1 read error, sector=7336960856
Aug 27 01:16:00 tower kernel: md: disk1 read error, sector=7336960864
Aug 27 01:16:01 tower kernel: md: disk1 write error, sector=7336960840
Aug 27 01:16:01 tower kernel: md: disk1 write error, sector=7336960848
Aug 27 01:16:01 tower kernel: md: disk1 write error, sector=7336960856
Aug 27 01:16:01 tower kernel: md: disk1 write error, sector=7336960864
Aug 28 03:40:16 tower crond[1737]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null
Aug 28 12:57:50 tower root: Fix Common Problems Version 2022.01.01a
Aug 28 12:57:51 tower root: Fix Common Problems: Error: disk1 (WDC_WD60EFRX-68L0BN1_WD-WXB1HB4TKHC9) is disabled
Aug 28 12:57:51 tower root: Fix Common Problems: Error: disk1 (WDC_WD60EFRX-68L0BN1_WD-WXB1HB4TKHC9) has read errors

 

I'm happy to remove the drive completely and just shrink the array as I feel this might be easiest and quickest but not sure how best to do this. I found several guides that suggest copying data off the drive and zeroing it and then shrinking the array to avoid parity rebuild. Obviously I can't copy the data off the drive as it's disabled in my case. 

 

Assuming the way I'd have to do it is to:

 

1. Stop array
2. Unassign the disabled disk
3. (New config setting maybe? This part always seems scary as 'new config' sounds like it's going to mess with all data on array and start as a 'new' storage pool)
4. Start array
5. Parity rebuilding 

 

Is there a better way or am I missing something? Any help would be hugely appreciated.

[JorgeB]

Please post the diagnostics.

[Zookeeper4094]

1 hour ago, JorgeB said:

Please post the diagnostics.

 

Shoot, sorry. Knew I forgot something.

tower-diagnostics-20220901-1318.zip

[JorgeB]

Looks more like a power/connection problem but since the disk dropped offline there's no SMART report, power down, check/replace cables, power back up and post new diags after array start.

[Zookeeper4094]

Dang. Just checked cables and such, rebooted, and it made some lovely clicking noises so I think the drive is gone. Array came back up with the drive showing as 'not installed' this time. 

 

Do you know if the best way to shrink the array by removing the drive is as I've outlined above? The new config bit scares me. I'm just thinking of stopping array, removing the drive, starting array and rebuilding parity.

[JorgeB]

If you shrink the array like that you will lose any data in the disabled disk, is that OK?

[Zookeeper4094]

Oof, I don't know what I was thinking. I naively thought that removing the disk, shrinking the array, it would then magically restore the content across the other disks. I can't lose the data that's on it. It is being emulated so assume it can't be copied/moved anymore. 

 

I'm thinking that replacing the drive is my only option unless there are any other tricks? 

[trurl]

2 hours ago, Zookeeper4094 said:

It is being emulated so assume it can't be copied/moved anymore. 

Missing / emulated disk1 is mounted, so of course you can access its data. If you need to backup some of it before rebuilding, I suggest copying it somewhere off the array so no array disks are modified until your array is protected again.

[Zookeeper4094]

Hey trurl. I don't think it's mounted as it's showing as 'not installed' or am I missing something with that?

 

How would I transfer data off of it to other disks as currently I can only browse data via the share?

[trurl]

A disk can be emulated and mounted without being installed. That is the whole point of parity. The actual physical disk could be completely destroyed and still be emulated.

 

Since it's been a few days since those diagnostics, start the array, post new diagnostics and a screenshot of Main - Array Devices.

[Zookeeper4094]

Ahh I see, thank you. I just came across an old post from you where you recommended copying the files to an unassigned drive to avoid further writing to the array. I don't have enough space to do that but am tempted to delete unimportant stuff from the emulated drive and then copy the bits I want to keep to the unassigned drive. Then copy it back after doing a new config/parity resync. Does this sound like the best option for my case?

 

tower-diagnostics-20220905-0952.zip

[JorgeB]

45 minutes ago, Zookeeper4094 said:

but am tempted to delete unimportant stuff from the emulated drive and then copy the bits I want to keep to the unassigned drive. Then copy it back after doing a new config/parity resync. Does this sound like the best option for my case?

That works.