8

I noted my backups were very slow so I did a speed test using sysbench like this:

$ mkdir benchmark
$ cd benchmark
$ sysbench fileio prepare
$ sysbench fileio --file-test-mode=rndrw run

These are the results:

sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)

Running the test with following options: Number of threads: 1 Initializing random number generator from current time

Extra file open flags: 0 128 files, 16MiB each 2GiB total file size Block size 16KiB Number of IO requests: 0 Read/Write ratio for combined random IO test: 1.50 Periodic FSYNC enabled, calling fsync() each 100 requests. Calling fsync() at the end of test, Enabled. Using synchronous I/O mode Doing random r/w test Initializing worker threads...

Threads started!

File operations: reads/s: 72.23 writes/s: 48.16 fsyncs/s: 153.46

Throughput: read, MiB/s: 1.13 written, MiB/s: 0.75

General statistics: total time: 10.0039s total number of events: 2741

Latency (ms): min: 0.03 avg: 3.65 max: 86.83 95th percentile: 12.30 sum: 9991.70

Threads fairness: events (avg/stddev): 2741.0000/0.00 execution time (avg/stddev): 9.9917/0.00

The hard drive is a new 4tb western digital inside a Nisuta USB 3 case .

Only partition in the drive is empty and is EXT4.

Why is it so slow?

1 Answers1

3

I recall seeing something about poor performance on Seagate 4TB drives on especially Linux machines. I've got one of these and it's a dog when you start copying lots of files. Been waiting for hours for it to copy about 60gb of files.

I read up on this some time after I got the drive and realized this. AFAIK the 4TB external I have sports SMR technology with a Cache to help mask the performance issues. But once you do write intensive tasks like try to copy several large files at once you get to notice a radical performance drop. I see each copy drop to 500kb/s. The total combined transfer rate between all the copies is slower than my Internet connection.

Here's a good explanation of SMR I found when I first tried figuring out what's happening:

https://blocksandfiles.com/2020/04/15/seagate-2-4-and-8tb-barracuda-and-desktop-hdd-smr/

Why SMR drives are sub-optimal for write-intensive workloads

Shingled magnetic recording gets more data to disk plates by partially overlapping write tracks, leaving the read track within them clear. Read IO speed is unaffected but data rewrites requires blocks of tracks to be read edited with the new data and rewritten as a new block. This lengthens data rewrite time substantially compared with conventionally recorded drives.

Write-intensive workloads are worse affected by SMR delays than read-intensive workloads. Therefore SMR drives are typically used for archival-type applications and not for real-time mixed or route-intensive use cases.

Caching writes to a non-shingled zone of the drive and writing them out to the shingled sectors in idle time will hide the slow rewrite speed effectively – until the cache fills when rewrite IO requests are still coming in.

The cache is then flushed and all the data written to the shingled area of the drive, causing a pause of potentially many seconds while this is done.

You may do well to look on Mac forums too. I'm also on Ubuntu but we're all in the same boat.

https://hardforum.com/threads/seagate-3tb-slow-write-speeds-drive-failing.1924143/

Codes216
  • 99
  • 6