14TB disk (WD140EFGX) fails on kirkwood

I have a Netgear ReadyNAS Duo v2 on which I recently installed 22.03.4 built from the Imagebuilder. 6TB WD60EFRX disks work well on the SATA ports, but I'm seeing I/O errors on the first access to 14TB WD140EFGX. The 14TB drives are recognized on boot/insertion, but first attempt to access them fails in error - I have not save the error status yet.

Any advice on where to look first?

Thanks -
Dana

I don't have an answer for you, but I'd check to see if the disk controller on the NAS can handle drives that large. The largest supported drive (as advertised when the device was supported by Netgear) was 4TB. A quick search seems to show that there may be a 12TB limit in the (stock) firmware), but it's not entirely clear what the controller can actually support. So, I'd recommend doing a bit of research on the actual limits that people have reported.

1 Like

Thanks for helping with this. I did a bit of research, and found this: https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/Tutorial-Readynas-duo-V2-using-12TB-14TB-or-16TB-drives/td-p/2202668 which reports using WD 14TB drives. It does not appear the controller is fundamentally unhappy with the larger drives.

I did attempt using the 14TB driver on the stock Netgear firmware 5.3.13 (IIRC) without success. Without consulting my notes, I recall the 6TB drive claimed to sync to the 14TB successfully, but it actually hadn't.

With the age, general creakiness and unsupported nature of the stock Netgear firmware, I was delighted to give OpenWRT a spin. With the 6TB drives, I now have the NAS working and see overall better performance as a back-up server, but I'm ready to re-visit why the 14TB drives immediately result in an I/O error. The drives are recognized - it's the first attempt to do I/O that fails.

Thanks -
Dana

Yeah, I won't be able to help you beyond my general suggestion -- no expereince with this specific device. I deployed a Duo v1 at my dad's house (sadly cannot run OpenWrt, only the v2 is supported), but I've never used a v2.

My understanding on the drive recongnition (and I could be wrong) is that the OS will ask the drive "what are you" and it will respond with all the relevant info, including the size. This can work even if the drive/size itself is not supported, and the error would theoretically come when you try to read/write data rather than simply reading identificatoin information.

So, based on your previous experience and the error you are experiencing, I suspect the controller may be the limiting factor here, but this is purley speculation.

1 Like

Thanks, though I'm not easily concluding the controller is at fault; that link above reports 12, 14 and 16 TB drives being used with the stock Netgear 'firmware'. I don't think it's specifically related to size - though there may be another hardware compatibility issue with this specific model of drive.

Drive identification is like most other SATA commands; the controller blurts a control data block (ATA registers) at the drive and it answers back. Fortunately the error reported on OpenWRT includes the CDB, so I'll have a look at it.

As an aside, I once had a v1, was amused to discover it used a microSPARC-based SoC (apparently the result of Sun open-sourcing the microSPARC HDL in 1998). Though I worked on Solaris at Sun from 1993 past the 2010 acquisition by Oracle, that was the last SPARC system that ran at my house (and the only, AFAIK, to run Linux). It was a wheezy at the time - the v2 was a decided upgrade.

Thanks -
Dana

There may be two other reasons:

  • not enough power provided to spin up many/ more platters
  • issues with the SATA cable or connector (I regularly see issues with older SATA cables and new SSDs, where the cable doesn't meet the requirements of SATA3).
3 Likes

The usual suspects (spin-up power, cables, etc.) didn't appear to apply here. In particular, the ReadyNAS Duo uses a backplane for the SATA interconnect, there are no cables, It's possible the backplane has an issue, but that's a stretch.

It occurred to me, I have a Sabrent external USB3 enclosure, so let's try the disk as an external USB device (note that I'm already happily using a 14TB Seagate USB3 enclosure on the same NAS, this is hardly rocket science).

And... the drive works no better in the external enclosure, which obviates the internal SATA interconnect, and appears to obviate anything Kirkwood-specific. The disk is getting heartburn from something further up the ATA stack:

[  791.137991] usb 3-2: new SuperSpeed USB device number 4 using xhci_hcd
[  791.181826] scsi host2: uas
[  791.187068] scsi 2:0:0:0: Direct-Access     SABRENT                   0104 PQ: 0 ANSI: 6
[  801.197331] sd 2:0:0:0: [sdc] Spinning up disk...
[  804.227779] .ready
[  810.090054] sd 2:0:0:0: [sdc] 3418095616 4096-byte logical blocks: (14.0 TB/12.7 TiB)
[  810.098478] sd 2:0:0:0: [sdc] Write Protect is off
[  810.103298] sd 2:0:0:0: [sdc] Mode Sense: 53 00 00 08
[  810.109069] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  810.118884] sd 2:0:0:0: [sdc] Optimal transfer size 33550336 bytes
[  812.478518] sd 2:0:0:0: [sdc] tag#1 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=2s
[  812.488155] sd 2:0:0:0: [sdc] tag#1 Sense Key : 0xb [current] 
[  812.494016] sd 2:0:0:0: [sdc] tag#1 ASC=0x0 ASCQ=0x0 
[  812.499106] sd 2:0:0:0: [sdc] tag#1 CDB: opcode=0x28 28 00 00 00 00 00 00 00 01 00
[  812.506710] blk_update_request: I/O error, dev sdc, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[  812.516590] Buffer I/O error on dev sdc, logical block 0, async page read
[  814.894452] sd 2:0:0:0: [sdc] tag#2 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=2s
[  814.904089] sd 2:0:0:0: [sdc] tag#2 Sense Key : 0xb [current] 
[  814.909965] sd 2:0:0:0: [sdc] tag#2 ASC=0x0 ASCQ=0x0 
[  814.915039] sd 2:0:0:0: [sdc] tag#2 CDB: opcode=0x28 28 00 00 00 00 00 00 00 01 00
[  814.922646] blk_update_request: I/O error, dev sdc, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[  814.932528] Buffer I/O error on dev sdc, logical block 0, async page read
[  814.940011]  sdc: unable to read partition table

I'll try the external enclosure on an Ubuntu 20 box I have.

i suggest to RMA as quickly as possible. most probably you have drive failure, and if i understand correctly you have not yet put any valued data on it.

1 Like

Tested both new drives on a Windows machine, both in the Sabrent USB3 enclosure and directly-attached to SATA. Bogus. Two DOA drives, RMA'ed. First time I've seen something like this in decades.

Thanks -
Dana

Following-up: installed 12TB Seagate Ironwolf ST12000VN0008, no issues, sync of md completed without problem. A little surprised to get a pair of DOA WD Red drives but such is life.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.