Constant disc activity after reboot

[Gremlin]

The problem is always relative when Hyper Cache is enabled. Hyper Cache synchronizes the cache with the disks every boot, and there are read/write operations between the 1GB M.2 drive where Hyper Cache is located and the hard drives.

But I don't understand Terramaster's hypercache method of synchronization. I've had other NAS devices, and they worked very well without generating this disk wear and noise.
The only solution is to not use hypercache and forget that it exists.

Is there a correlation between between this activity and the file system in use? {I don't use Hyper-cache, so was just wondering.}

[rfbjr]

On one of my devices (F4-425 Plus) I have TerraSync installed and for me that's what is busy for hours after each reboot. That has been reported and is being fixed. I only reboot them once a week before I head out the door, granted might not be possible for other folks and their usage.

[luismartin]

That's not my case;
I don't have any application that generates that activity.
I reboot the enclosure once at day.
It only happens when hypercache is installed.

[MikeZhang]

1. Please provide your hyper cache mode: balanced mode or R-W mode
2. Did you force a hard restart by power button or click reboot in TOS "Start"?
3. Before it reboots, is there data transfer activity?
4. You may enter command line

Code: Select all

lvdisplay | grep -E "Cache dirty blocks"

in TOS terminal, test for several reboots and provide us with output for analysis.

[luismartin]

1. Please provide your hyper cache mode: balanced mode or R-W mode
2. Did you force a hard restart by power button or click reboot in TOS "Start"?
3. Before it reboots, is there data transfer activity?
4. You may enter command line

Code: Select all

lvdisplay | grep -E "Cache dirty blocks"

in TOS terminal, test for several reboots and provide us with output for analysis.

1. Balanced mode for Hypercache
2. No. Always Shutdown command is used.
3. No. The NAS is only used by me with not external activity
4. While disk activity is frantic when I boot the NAS, starting at 100%, it drops to 0% when that activity stops.

(I replaced the M.2 drive with a 1TB one in case that was the problem, but the problem persists.)


emby@TNAS-EMBY:/# lvdisplay | grep -E "Cache dirty blocks"
Cache dirty blocks 95.66%
emby@TNAS-EMBY:/# lvdisplay | grep -E "Cache dirty blocks"
Cache dirty blocks 95.10%
emby@TNAS-EMBY:/# lvdisplay | grep -E "Cache dirty blocks"
Cache dirty blocks 93.39%
emby@TNAS-EMBY:/# lvdisplay | grep -E "Cache dirty blocks"
Cache dirty blocks 90.13%
emby@TNAS-EMBY:/# lvdisplay | grep -E "Cache dirty blocks"
Cache dirty blocks 85.86%
emby@TNAS-EMBY:/# lvdisplay | grep -E "Cache dirty blocks"
Cache dirty blocks 80.42%
emby@TNAS-EMBY:/# lvdisplay | grep -E "Cache dirty blocks"
Cache dirty blocks 71.20%
emby@TNAS-EMBY:/# lvdisplay | grep -E "Cache dirty blocks"
Cache dirty blocks 32.96%
emby@TNAS-EMBY:/# lvdisplay | grep -E "Cache dirty blocks"
Cache dirty blocks 6.30%
emby@TNAS-EMBY:/# lvdisplay | grep -E "Cache dirty blocks"
Cache dirty blocks 0.00%
emby@TNAS-EMBY:/#

Out of curiosity, in TOS5 and 6, Hypercache needed to use RAM, and if there wasn't enough RAM, the full capacity of, for example, a 1TB M.2 drive couldn't be used.
TOS7 Hypercache apparently doesn't use RAM.
Is this normal behavior?

[EriChan]

Regarding the issue you encountered, here is a detailed explanation:

Persistent hard drive read/write activity following system reboot

When the cache mode is set to Write-Back Mode, data written to the NAS is first stored at high speed in the M.2 SSD. Data blocks that have been written to the SSD but not yet synchronized back to the mechanical hard drive are referred to as "Dirty Blocks" in storage technology.

According to the logs, the proportion of dirty blocks in the cache reached as high as 95.10% after the system rebooted. This means a large volume of the most recent data remained trapped in the SSD. To ensure absolute data security and file system consistency, the underlying synchronization daemon of the TOS system will immediately and fully flush and safely write these "dirty data" from the SSD to the mechanical hard drive once the system finishes booting. As the read/write process continues, the dirty block proportion drops steadily from 95.10% -> 93.39% -> 71.20% -> 6.30% until it finally reaches 0.00%. Under normal circumstances, this indicates that the system is safely synchronizing cached data, which is a normal system protection mechanism. Please do not forcibly power off or shut down the device, and wait patiently until the proportion drops to zero.

Hyper Cache memory usage

Yes, in versions prior to TOS 6.0.694, the capacity of Hyper Cache was limited by factors such as available system memory. This limitation has been lifted in TOS 6.0.694 and all subsequent versions.

[luismartin]

Regarding the issue you encountered, here is a detailed explanation:

Persistent hard drive read/write activity following system reboot

When the cache mode is set to Write-Back Mode, data written to the NAS is first stored at high speed in the M.2 SSD. Data blocks that have been written to the SSD but not yet synchronized back to the mechanical hard drive are referred to as "Dirty Blocks" in storage technology.

According to the logs, the proportion of dirty blocks in the cache reached as high as 95.10% after the system rebooted. This means a large volume of the most recent data remained trapped in the SSD. To ensure absolute data security and file system consistency, the underlying synchronization daemon of the TOS system will immediately and fully flush and safely write these "dirty data" from the SSD to the mechanical hard drive once the system finishes booting. As the read/write process continues, the dirty block proportion drops steadily from 95.10% -> 93.39% -> 71.20% -> 6.30% until it finally reaches 0.00%. Under normal circumstances, this indicates that the system is safely synchronizing cached data, which is a normal system protection mechanism. Please do not forcibly power off or shut down the device, and wait patiently until the proportion drops to zero.

Hyper Cache memory usage

Yes, in versions prior to TOS 6.0.694, the capacity of Hyper Cache was limited by factors such as available system memory. This limitation has been lifted in TOS 6.0.694 and all subsequent versions.

Thank you so much, EriChan, for your excellent explanation of how Hypercache works.
Previously, with versions prior to TOS7, I don't recall such a long and cumbersome synchronization process with the hard drives, perhaps because the M.2 shared data with RAM.
Hypercache is definitely not for me because it doesn't justify the hours of activity it causes after a boot.
Since all I wanted was faster harddisk enabled after hibernation (which dropped from 1 minute 30 seconds to 35 seconds) and for it to remember the directory tree in SMB.
Perhaps later I'll buy a much smaller 32 or 64GB M.2 and try using Hypercache again and check if that meets my expectations.

Thanks to support

[erikcsellers]

I too have this issue, same system F4-424 Pro with balance 500 GB hypercache. Every reboot there is massive read and writes with the same processes you mentioned. This seems massively excessive.

[MikeZhang]

1. Please provide your hyper cache mode: balanced mode or R-W mode
2. Did you force a hard restart by power button or click reboot in TOS "Start"?
3. Before it reboots, is there data transfer activity?
4. You may enter command line

Code: Select all

lvdisplay | grep -E "Cache dirty blocks"

in TOS terminal, test for several reboots and provide us with output for analysis.

[MikeZhang]

On which TOS version did you observe this constant disc activity?