0

I have an Intel NUC with Windows 10 64bits, I connected with USB3.0 (UASP) an 8-bay HDD enclosure that contains 2 new HDD WD Red 6Tb, and 1 old HDD WD Green 2Tb (99% full but healthy, formatted with ReFS). With the two WD Red I created with Storage Spaces a 2-way mirrored volume of 6Tb (thick provisioning) formatted with ReFS. Then I want to migrate the content of the WD Green to the empty Storage Spaces volume with the following command as administrator:

robocopy "E:\data" "D:\data" /COPY:DAT /DCOPY:DAT /E /J /B /MT:4 /W:5 /R:50 /UNILOG:log.txt /TEE

I made 2 attempts and both given the same result: Everything seems to work fine for roughly 30 minutes, then Storage Spaces suddenly thinks the two disks failed simultaneously and kill the pool. But if I take them back online, everything work again flawlessly!

I don't think the disks are faulty as they perform well when I do anything other than this 2Tb file transfert. The first HDD enclosure I received WAS clearly faulty and I sent it back for a replacement, now the new enclosure seems fine as I also don't have any problem with it except with this transfert.

From what I found on the Internet the best guess I have for two healthy disks to be declared dead at the same time is maybe a 30 minute timer that put the HDD enclosure or the HDD themselves in idle mode, and when the next access happens by the time everything go back online Windows already marked both disks as unresponsive. But why would this happens in the middle of a big copy? So I'm a little lost...

What can be wrong with this Storage Spaces volume? What should I check to identify the root cause of this problem?

Improve this question

1 Answer 1

Reset to default
0

I doubt that it's because of the idle/sleep timer. If it's really the case you should see that the drives go dead/offline even if there's no copying.

The JMicron JMS567 on my adapter from IOCrest does have the standby timer enabled by default though. However apparently the actual default timeout is 10 minutes, although it has a bogus default of 30 minutes:

enter image description here

You can try to disable the timer with sdparm:

sdparm --set STANDBY=0 PDN

Where N is the disk number enumerated by Windows, which is shown in Disk Management and list disk in diskpart. PD stands for Physical Drive.

For disk(s) in a Storage Space pool you might need to test and guess about the physical disk number. For example:

enter image description here

You do NOT run it on the virtual disk(s) in the pool but on EACH of the physical disk(s).

Be noted that the setting is volatile to a power cycle of the enclosure.

EDIT: I just flashed the firmware update available on StarTech to my chip. Apparently it has the standby timer disabled by default. You may want to confirm that the firmware on your enclosure has it disabled as well (in case StarTech did not change the firmware version for this change):

enter image description here

Improve this answer
6
  • I tried your tool but apparently it does not work with a Storage Spaces virtual disk. I haven't tried the firmware update yet because I think it tells me I'm already up-to-date... And I don't understand some parts of the GUI... What do the "RD version" checkbox means? Does the list of disks on it is only informative or do I need to update each one? See for yourself.
    – Oungawak
    Commented Apr 9, 2016 at 17:40
  • @Oungawak Of course you do NOT run it on the virtual disk, but on the physical disks one by one. But yeah since Windows hides the physical disk(s) in a storage pool so you might need test and guess, but it still works. See my update answer.
    – Tom Yan
    Commented Apr 9, 2016 at 20:31
  • Apparently "RD Version" sort of means "Advanced Options" or so. You can see options like backing up the old firmware once you tick it. And I've no idea whether you need to update each one manually (probably yes). Also it seems the firmware version is already up-to-date (I was intrigued by NoSleep in the file name of the firmware file though)
    – Tom Yan
    Commented Apr 9, 2016 at 20:36
  • Sorry for the delay @Tom Yan. I tested your solution but it didn't work. I also flashed the firmware and nothing changed.
    – Oungawak
    Commented Apr 11, 2016 at 21:25
  • @Oungawak In my answer I said that If it's really the case you should see that the drives go dead/offline even if there's no copying., but is it true that they only die after 30min if there is copying? Also, have you tested that whether the issue is specific to robocopy?
    – Tom Yan
    Commented Apr 11, 2016 at 23:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .