I wanted to post an update here as I did some more experimentation.
1. I believe I saw the same behavior with the SSD cache because the "jump SSD cache" was enabled. For some reason, I was not able to disable this. It would say the operation was successful, but when reloading the UI it would still be checked.
2. I deleted the SSD cache and created a mirrored storage pool and a single volume with btrfs. Then, I made a shared folder to test with. I get more consistent, sustained speeds transferring a large file to this share. It will still dip to 0MB/s occasionally but then resume a second or two later. (I think this has to do with the write speed of flushing data to disk, as it's much faster than spinning; see #3)
3. On the transfers to the spinning disks. I observed that while the client is sending data, there is no drive activity on the spinning disks. No sound or blinking lights for the disks. Once the data transfer hangs on the client side, the disks have activity, then once data transfer resumes on the client, the disks stop having activity. This leads me to believe it is doing some reading into a memory buffer, pausing the reading to flush the buffer to disk, and then resuming the data transfer to fill the buffer again. Maybe someone from TerraMaster can say if this is how it's working and/or is expected?
4. I copied a large file using the TOS file manager from the nvme volume to the spinning volume. It maintained a 400MB/s write speed to the spinning disks for the entire transfer with no dips, etc. This metric is doubled since it's written to both disks in RAID1. So, the drives can maintain a 200MB/s sustained write speed each, and this is what I'm expecting even when transferring over the network vs data bursts from 0MB/s to aprox 300MB/s.
I was going to test Ext4 to see if btrfs played a role in all this, but I think my test in #4 shows that is probably not the case, else I would see the same behavior when transferring from the nvme volume to the spinning volume
1. I believe I saw the same behavior with the SSD cache because the "jump SSD cache" was enabled. For some reason, I was not able to disable this. It would say the operation was successful, but when reloading the UI it would still be checked.
2. I deleted the SSD cache and created a mirrored storage pool and a single volume with btrfs. Then, I made a shared folder to test with. I get more consistent, sustained speeds transferring a large file to this share. It will still dip to 0MB/s occasionally but then resume a second or two later. (I think this has to do with the write speed of flushing data to disk, as it's much faster than spinning; see #3)
3. On the transfers to the spinning disks. I observed that while the client is sending data, there is no drive activity on the spinning disks. No sound or blinking lights for the disks. Once the data transfer hangs on the client side, the disks have activity, then once data transfer resumes on the client, the disks stop having activity. This leads me to believe it is doing some reading into a memory buffer, pausing the reading to flush the buffer to disk, and then resuming the data transfer to fill the buffer again. Maybe someone from TerraMaster can say if this is how it's working and/or is expected?
4. I copied a large file using the TOS file manager from the nvme volume to the spinning volume. It maintained a 400MB/s write speed to the spinning disks for the entire transfer with no dips, etc. This metric is doubled since it's written to both disks in RAID1. So, the drives can maintain a 200MB/s sustained write speed each, and this is what I'm expecting even when transferring over the network vs data bursts from 0MB/s to aprox 300MB/s.
I was going to test Ext4 to see if btrfs played a role in all this, but I think my test in #4 shows that is probably not the case, else I would see the same behavior when transferring from the nvme volume to the spinning volume
Statistics: Posted by antislow — Today, 01:03