TerraMaster Forum

U4-500 Sleep mode for disks leads to RAID degradation.

D4-320U
TOS 7.0.1188
BIOS/InitBoot 5.26

I have a D4-320U.
RAID 1 is sde + sdf.
Despite HyperCache enabled on the U4-500, RAID 1 works reliably until I enable drive hibernation in the settings. About three hours ago, I enabled RAID 1, and it immediately went into degradation mode. No matter how I physically swap the drives, the hard sdf drive always fails, but the sde always stays functional.

I sent logs to"[email protected]".
Around 8:41 PM, sdf rejected the write cache flush command, after which RAID disabled sdf4.

Tolian wrote: ↑16 Sep 2026, 02:21

We have received your email. However, the system diagnostic report uploaded to Google Drive is currently restricted by access permissions, and we are unable to access or download it.

Could you please update the sharing settings of the Google Drive link (e.g., set to "Anyone with the link can view/download") so our technical team can download the logs for analysis?

Thanks.

EriChan wrote: ↑16 Sep 2026, 08:35

Hello,

I read on the forum that the logs didn't open for you using the link I provided from Google Drive.

I just sent you a new email.
I've corrected the file permissions, please try again.

The root cause is a cache-flush compatibility issue at the D4-320U USB-bridge / UAS layer.

As I understand it, the only chance to fix the problem is a new firmware for the D4-320U.

Could you please escalate this case to the TerraMaster R&D team?

Additional findings: D4-320U hibernation, UAS and SYNCHRONIZE CACHE

I did some additional research and found several points that may be useful for TerraMaster Support and R&D.

My current understanding is that the fix may not necessarily require only a D4-320U firmware update. There are at least two possible places where this issue could potentially be addressed:

1. D4-320U USB-to-SATA bridge firmware
2. TOS / Linux UAS / SCSI layer

1. D4-320U USB-to-SATA bridge

According to my system logs, the affected bridge enumerates as:
This VID:PID is identified by public USB databases and smartmontools as a Realtek RTL9201 USB-to-SATA bridge.

With Disk Hibernation enabled, the bridge rejects:
with:
The failure sequence is essentially:
So one possible solution may be a firmware fix for the RTL9201 bridge, if the firmware incorrectly handles SYNCHRONIZE CACHE(10), especially during or after hibernation/wakeup.

2. Possible TOS / Linux UAS / SCSI workaround

Even if changing the bridge firmware is not possible, R&D could investigate a Linux/TOS device-specific quirk or workaround for:
Possible approaches could include different handling of the rejected cache-flush command, a UAS-specific quirk, or preventing the device from being offlined after this failure.

As a diagnostic test, it may also be useful to force this bridge to use the traditional driver instead of UAS.

I am not suggesting that disabling UAS is necessarily the correct permanent fix, because it may reduce performance. My point is that the issue may potentially be addressed on either side of the USB/SCSI interface.

Therefore I think R&D should investigate both the D4-320U bridge firmware and the TOS Linux UAS/SCSI layer.

3. Very similar SYNCHRONIZE CACHE / UAS failure on D4-320 under Linux

I found a very interesting TerraMaster forum thread:

D4-320 disconnecting in linux, and other problems

A Proxmox user reported:
This is very similar to my case:
I understand that this is not proof of the same root cause, and D4-320 and D4-320U may use different USB-SATA bridge hardware. However, the similarity at the Linux SCSI/UAS level seems significant enough that R&D should compare the two cases.

Another user in that discussion later reported that disabling UAS and using eliminated the errors on a related TerraMaster DAS. This may therefore be useful as a diagnostic test.

4. Existing D4-320 sleep / RAID reports

There is also this thread:

D4-320 sleep issue on Mac

Users reported RAID degradation and problems related to the DAS putting drives to sleep and waking them again.

Another user with a Mac Mini M4 and D4-320 using two HDDs in software RAID1 suspected an interaction between software RAID, hibernation and the DAS itself.

TM Support directed users to:
This is a different host OS and a D4-320 rather than D4-320U, so I am not claiming that the root cause is identical. However, it shows that sleep/wakeup behaviour combined with software RAID has caused problems for other users in the D4-320 family.

5. Official TerraMaster USB TDAS troubleshooting guide

TerraMaster also publishes:

TerraMaster USB TDAS Data Interruption Troubleshooting Guide

The list of applicable products explicitly includes:
The guide discusses read/write interruptions during USB data transfer.

I understand that it mainly covers ports, cables and general connection problems, so it does not prove that my issue has the same cause.

However, it confirms that TerraMaster already treats USB data-interruption problems affecting the D4-320U as a specific troubleshooting category.

My case appears more specific because the problem is reproducibly triggered by Disk Hibernation, and the kernel log clearly shows the failed immediately before the UAS reset and RAID degradation.

6. D4-320U / Realtek hardware

There is also a D4-320U hardware discussion here:

D4-320U chipset discussion

A forum member, referring to an internal-board photo, stated that the D4-320U appears to use an all-Realtek solution.

This was not an official TerraMaster statement, so I do not treat it as confirmation. However, my system actually reports:
which public USB databases identify as Realtek RTL9201.

7. Existing D4-320 firmware is not listed for D4-320U

TerraMaster has a firmware update guide for D4-320/D6-320:

Firmware Update Guide for D6-320/D4-320

This is interesting because it shows that firmware updates in this product family can fix USB/SATA related problems.

However, the guide explicitly lists only:
D4-320U is not listed.

Therefore I do not think it would be safe to try that firmware on my D4-320U.

This raises an important question:

Does the Realtek RTL9201 used in the D4-320U have upgradeable firmware, and if so, is there a newer production, beta or engineering firmware that changes SYNCHRONIZE CACHE or hibernation behaviour?

8. Questions for TerraMaster R&D

I would appreciate it if this case could be escalated to R&D and they could check:

1. What firmware version is running on the RTL9201 in my D4-320U?
2. Is newer production, beta or engineering firmware available?
3. Does the bridge fully support

   Code: Select all

   SYNCHRONIZE CACHE(10)

   ?
4. Does its behaviour change after hibernation/wakeup?
5. Is this issue known for USB ID

   Code: Select all

   0bda:9201

   ?
6. Could a TOS/Linux UAS quirk prevent the disk from being offlined?
7. Would disabling UAS for

   Code: Select all

   0bda:9201

   be a useful diagnostic test?
8. Can R&D reproduce this with D4-320U + TerraMaster NAS + software RAID1 + Disk Hibernation enabled?

9. Most important observation from my testing

The failure does not follow the physical HDD.

I physically swapped the two HDDs, but the problem continued to follow the same D4-320U USB path/device position.

Whichever physical disk enumerates as on that path is eventually removed from RAID1 after Disk Hibernation is enabled.

With Disk Hibernation disabled, the RAID1 array remains stable.

This strongly suggests an interaction between:
rather than a defective HDD.

Conclusion

I believe this should be investigated specifically as a possible D4-320U bridge firmware / UAS / hibernation compatibility issue, not only as a generic USB connectivity problem.

The strongest evidence is:

• the failure follows the D4-320U path rather than the physical HDD;
• Disk Hibernation reproducibly triggers it;

• Code: Select all

  SYNCHRONIZE CACHE(10)

  is rejected immediately before the failure;
• the rejection is followed by UAS recovery/reset;
• md/RAID1 then removes the disk;
• similar SYNCHRONIZE CACHE/UAS failures have been reported with other TerraMaster DAS devices under Linux.

I am happy to provide additional logs, test with UAS disabled, test beta/engineering firmware, or perform any other controlled test requested by R&D.

Thank you.

Thank you for your thorough testing and feedback. Please run further tests with the UAS disabled, and enable debug mode on the NAS, then send everything to us for analysis.

CursaYang wrote: ↑17 Sep 2026, 17:55 Thank you for your thorough testing and feedback. Please run further tests with the UPS disconnected, and enable debug mode on the NAS, then send everything to us for analysis.

Am I understanding you correctly? I need to:
1. Enable debug mode on the U4-500.
2. Clear the UPS settings on the U4-500.
3. Turn on the U4-500 and D4-320U without using the power loss protection (without the UPS).
4. Enable sleep mode on the U4-500.
5. Wait until the RAID fails again (sdf will be lost).
6. Collect the logs and send them to you.

Is that correct?

I meant disabling UAS; the other steps are correct.

Thank you for your help and for continuing to investigate this issue. However, I will not perform the proposed test with UAS disabled on my production storage system. I am not prepared to experiment with drivers on a mounted array and expose my data to additional risk.

My D4-320U contains a RAID1 array, and HyperCache is enabled in Read-Write mode for the corresponding volume. In this mode, acknowledged writes may remain in the SSD cache for some time before being written to the HDDs. An error when disabling or rebinding the driver could interrupt access to both USB drives, cause I/O errors, and interrupt pending write operations. RAID1 mirroring does not protect against losing access to both drives simultaneously through their shared USB connection.

I understand that switching from UAS to another transport may have diagnostic value. Nevertheless, changing storage driver behaviour myself on a system containing production data presents an unacceptable risk to me. This is the reason for my objection, rather than a lack of instructions for performing the test.

The array has already entered a degraded state several times and required rebuilding. While degraded, only one active HDD remains in the mirror. I am not prepared to continue experiments that could cause another degradation, require another resynchronization, or jeopardize data integrity. The previous failure has already been captured in the logs provided to you.

Furthermore, enabling debug mode may affect the reproducibility of the issue itself. Your own official documentation, “Why won't TNAS disks hibernate?”, lists debug mode among the factors that can prevent hibernation, because enabling it causes the system to continuously write debug logs to disk.

In my case, the failure occurs after HDD sleep is enabled. If debugging activity prevents the drives from sleeping, the absence of a failure with UAS disabled cannot be considered confirmation that the issue has been resolved: the condition under which it occurs would have changed. Therefore, the proposed test could both introduce additional risk to the production array and produce an ambiguous diagnostic result.

Please forward the existing materials to your R&D engineers. I had hoped that you would conduct further tests yourselves on a test bench using a U4-500 and a D4-320U.

We understand your concerns; we will conduct the testing while ensuring data security and will reply to you via email.