Page 4 of 4
Re: Constant disc activity after reboot
Posted: 24 Aug 2026, 01:12
by EriChan
LordP wrote: ↑23 Aug 2026, 07:05
Here is a breakdown and troubleshooting steps for both issues:
1. Transfer Speed Dropping to ~108 MB/s on F6-424
- Check Network Link Speed: ~108 MB/s is the typical maximum bandwidth of a 1 Gbps (1000 Mbps) connection (compared to your previous ~205 MB/s on 2.5 Gbps). The port may have negotiated down to 1000 Mbps after the update.
- Go to Control Panel > Network > Network Interface to check if the link displays 2500 Mbps or 1000 Mbps. If it shows 1000 Mbps, try reconnecting the cable or power-cycling the switch port.
- Post-Upgrade System Load: Background parity checks or newly initialized services after an upgrade can also temporarily impact overall transfer throughput.
2. High Disk Activity on F4-423 After Reboot
- Routine Maintenance & Self-Checks: Drive activity following a reboot is typically driven by startup self-checks, file system routines, or indexing services rather than pending dirty cache data.
- How to Identify Active Tasks: On either device, navigate to System Information > Services and Processes to identify which specific process is generating the disk I/O.
Re: Constant disc activity after reboot
Posted: 25 Aug 2026, 05:16
by LordP
My whole system is 2.5G
I see: LAN 1 Connected - 2500Mbps - 1500 MTU
"Post-Upgrade System Load: Background parity checks or newly initialized services after an upgrade can also temporarily impact overall transfer throughput." I initialized this new NAS about two weeks ago.
In System Information, as I'm transferring a file, I only see md0_raid5, smbd, and kworker00 - the highest CPU use in at 5%. smbd disk write is at 45.00MB/s
I only use the NAS for storage; I have zero running apps or any other crazy thing like Plex.
What I would love to monitor is that Hypercache SSD - I'd love to see what it's doing.
Let me ask you: Suppose I am transferring 800GB of data, and the SSD is 256GB - what happens? Does the SSD start offloading right away? Does it wait until some threshold? My speeds always start very high, but always drop off drastically. What if I were transferring only 100GB, would it act the same way? I suppose I can try it.
I am in the process of moving everything from the F4-423 to the F6-424 and it is slooowwww. I want to try to update the F4-424 to TOS-7, but I don't trust the process, hence I'm moving everything.
I ordered a 2TB SSD from Amazon to see if it will help - what do you think will happen?
Thanks for the reply.
BTW, I WAS on 'Balance Mode' when I wrote the prior posts, but I decided to try 'Read-write Mode' - it didn't help at all, in fact it seems a bit worse. All the stuff I mentioned in this response is based on the SSD being 'Read-write Mode'
Re: Constant disc activity after reboot
Posted: 25 Aug 2026, 05:23
by LordP
BTW. This was the FastCopy log for my last transfer - this is where I had switched to 'Read-Write mode':
TotalRead = 1,357,703 MiB
TotalWrite = 1,355,671 MiB
TotalFiles = 33 (0)
TotalTime = 06:46:37
TransRate = 58.3 MB/s
FileRate = 0.00 files/s
Not very good, is it?
I did notice ONE thing. There was zero hard drive activity AFTER the transfer was complete - does THAT mean I no longer have 'dirty data'? I assume the SSD is not unloading anything - would this be a correct assumption?
Re: Constant disc activity after reboot
Posted: 25 Aug 2026, 05:39
by LordP
So I did my little test to see what type of cache is better for me. I used a single file with FastCopy ,5.12.0
Balace Mode:
TotalRead = 64,577 MiB
TotalWrite = 64,577 MiB
TotalFiles = 1 (0)
TotalTime = 05:07
TransRate = 220.2 MB/s
FileRate = 0.00 files/s
Result : (ErrFiles : 0 / ErrDirs : 0) at 2026/08/24 17:35:18
I didn't bother finishing 'Read-write Mode' because it said it would take 20 minutes when I first started transferring that same file.
Going forward, please don't ask me what my LAN speed is.
Re: Constant disc activity after reboot
Posted: 25 Aug 2026, 07:18
by MikeZhang
Your observation is very keen. This phenomenon most likely indicates that you're experiencing a forced slowdown after the write cache becomes full, rather than the cache working efficiently.
The "dirty data" is still there, but has nowhere to go: In "read-write mode," data is first written to the faster SSD cache, and then the system "quietly" writes it to the HDD in the background. The "zero activity" you see is most likely because the 256GB SSD cache is completely full, and the system is struggling to flush the data from the SSD to the HDD. However, due to the limited write speed of the HDD (approximately 150-200MB/s per disk), this process is very slow and inconspicuous, resulting in no obvious hard drive activity visible in Task Manager.
You may have encountered a "write stoppage": In a more extreme case, when the SSD cache is full and the system cannot free up space in time, the write operation is temporarily "paused" while waiting for the cache to be cleared. This causes the CPU and hard drive to appear "idle" after the transfer is complete, but in reality, the system is processing the write of cached data to disk.
The difference from "Balanced Mode": This also explains why you felt worse after switching to "Read/Write Mode." "Balanced Mode" might use both the SSD and HDD simultaneously, and while it will slow down later, it maintains a smoother curve; whereas "Read/Write Mode," once the cache is full, can experience a more precipitous drop in speed, making it feel slower.
In summary, your situation is: your 256GB SSD cache was completely overwhelmed by consecutive large file writes of 1.3TB. The average speed of 58.3 MB/s is the result of the system being forced to write at the true HDD speed (or even slower) after the SSD cache was exhausted.
Your order of a 2TB SSD is the right direction to solve the problem. Larger capacity means larger SLC cache and buffers, which can better absorb the impact of such large-scale continuous writes, keeping speeds high for a longer period.
Before replacing the SSD, if you want to verify this judgment, you can try temporarily removing the SSD cache and directly writing a smaller file (such as 50GB) to the HDD array, and observe whether the speed stabilizes at a low but steady level (such as 150-200MB/s). If the speed is stable, it will confirm our analysis.
Re: Constant disc activity after reboot
Posted: 25 Aug 2026, 18:20
by LordP
Thank you for the response.
There is one thing I still don't understand:
You say this: However, due to the limited write speed of the HDD (approximately 150-200MB/s per disk)
And then you say this: The average speed of 58.3 MB/s is the result of the system being forced to write at the true HDD speed (or even slower)
So which is the hard drive write speed?
I'll get the 2TB SSD today, and maybe I'll have a bit more data.
Re: Constant disc activity after reboot
Posted: 26 Aug 2026, 03:36
by LordP
So, I spent the entire day trying to make sense of what is going on, and I ran some tests.
You guys owe me.
My verdict is that Terra Master has a LOT of work to do to fix Hyper Cache - it does not work.
All tests done with FastCopy v5.12.0 as Admin
F4-423 4TB System SSD - 4TB Hyper Cache SSD
F6-424 512GB System SSD - 512GB SSD Hyper Cache, except when I disabled Hyper Cache by deleting it.
==============================================================================================
This first transfer is to test the read speed of the F4-423
F4 -> PC: F4 has a 4TB SSD Hyper Cache - NVMe Disk 1
+ F:\TEST OF NAS\****** <20250910-160039 65,639,766,153>
No Errors
TotalRead = 62,598 MiB
TotalWrite = 62,598 MiB
TotalFiles = 1 (0)
TotalTime = 07:15
TransRate = 150.7 MB/s
FileRate = 0.00 files/s
Result : (ErrFiles : 0 / ErrDirs : 0) at 2026/08/25 10:16:52
==============================================================================================
(very possible 'dirty cache data' going on)
PC -> F6: F6 has a 512GB SSD Hyper Cache NVMe Disk 2
25/Aug/2026 11:06
+ \\TNAS-2\LordP666\Movies\***** <20250910-160039 65,639,766,153>
No Errors
TotalRead = 62,598 MiB
TotalWrite = 62,598 MiB
TotalFiles = 1 (0)
TotalTime = 34:59
TransRate = 31.3 MB/s
FileRate = 0.00 files/s
Result : (ErrFiles : 0 / ErrDirs : 0) at 2026/08/25 11:00:27
==============================================================================================
One hour later, hopefully no 'dirty cache data':
PC -> F6: F6 has a 512GB SSD Hyper Cache NVMe Disk 2 - Using the same file once again.
I aborted the copy. I saw no point to it when I saw 24MB/s:
-------------------------------------------------
Aborted by User
TotalRead = 4,426 MiB
TotalWrite = 2,398 MiB
TotalFiles = 0 (0)
TotalTime = 01:44
TransRate = 24.0 MB/s
FileRate = 0.00 files/s
Result : (ErrFiles : 2 / ErrDirs : 0) at 2026/08/25 12:13:14
==============================================================================================
One hour later, deleted Hypecache transferring the same exact file.
PC -> F6:
25/Aug/2026 13:22
No Errors
TotalRead = 62,598 MiB
TotalWrite = 62,598 MiB
TotalFiles = 1 (0)
TotalTime = 07:16
TransRate = 150.5 MB/s
FileRate = 0.00 files/s
Result : (ErrFiles : 0 / ErrDirs : 0) at 2026/08/25 13:19:44
==============================================================================================
Now, encouraged by the good speed, I decided to transfer some large files while the Hyper cache is disabled.
PC -> F6:
25/Aug/2026 14:29
No Errors
TotalRead = 578,030 MiB
TotalWrite = 578,030 MiB
TotalFiles = 13 (0)
TotalSkip = 22,862 MiB
SkipFiles = 1 (0)
TotalTime = 01:00:15
TransRate = 167.6 MB/s
FileRate = 0.00 files/s
Result : (ErrFiles : 0 / ErrDirs : 0) at 2026/08/25 14:26:43
==============================================================================================
Just for the hell of it, and to see if there is activity that could prevent good write speed, I am again transferring large files to the F6
I only waited a minute before starting the new transfer.
PC -> F6:
25/Aug/2026 15:02
No Errors
TotalRead = 295,528 MiB
TotalWrite = 295,528 MiB
TotalFiles = 6 (0)
TotalTime = 32:29
TransRate = 158.9 MB/s
FileRate = 0.00 files/s
Result : (ErrFiles : 0 / ErrDirs : 0) at 2026/08/25 15:02:19
==============================================================================================
And finally, transferring a few files from the F4-423 (4TB Hyper Cache) to the F6-424 (no Hyper Cache) - no waiting.
F4 -> F6:
25/Aug/2026 15:28
No Errors
TotalRead = 187,755 MiB
TotalWrite = 187,755 MiB
TotalFiles = 5 (0)
TotalTime = 22:37
TransRate = 145.0 MB/s
FileRate = 0.00 files/s
Result : (ErrFiles : 0 / ErrDirs : 0) at 2026/08/25 15:27:48
==============================================================================================
And finally, I'll delete the Hyper Cache in the F4-423 and try it again, same test, different files.
I mean F-4 (no Hyper Cache) to F6 (no Hyper Cache).
But I'll wait until tomorrow for this one. It has been a long day, and I'm tired.
Re: Constant disc activity after reboot
Posted: 26 Aug 2026, 07:21
by MikeZhang
Based on your data, Hyper Cache not only failed to accelerate performance during write operations, but actually severely hampered it (dropping from 150MB/s to 31MB/s). This is a highly unusual result.
Possible explanations include:
Cache strategy issues: Hyper Cache may be configured as "Write-Back" but its disk write strategy is too conservative, or the synchronization mechanism has flaws, causing writes to wait for the SSD cache to complete certain operations, creating a bottleneck.
Dirty data flushing mechanism anomalies: Even after testing again "an hour later," the cache still hasn't completed data write-to-disk, suggesting the system may be continuously flushing in the background, consuming significant I/O resources.
Suggested follow-up verification: Check Hyper Cache mode: Confirm whether you are configured as "Write-Back" or "Write-Through." Theoretically, write-back mode should have a speed-up effect, while write-through mode should not have a performance penalty. Your test results point to an anomaly in write-back mode.
Monitor Cache Status: When transferring files with Hyper Cache enabled, observe the TOS resource monitoring page to view the SSD's read/write IOPS and latency data. This can help determine whether the bottleneck is in the SSD itself or in the cache management logic.
You spent a whole day doing testing; you've really done a good job for the community and the official team. This data post will be very valuable for users encountering similar issues.
Once you complete the comparison test after deleting the F4-423 cache tomorrow, the entire chain of evidence will be more complete. Thank you for your hard work!