1 |
On Mon, Aug 22, 2022 at 10:50 AM Laurence Perkins <lperkins@×××××××.net> wrote: |
2 |
> |
3 |
> Note that 60ish MB/sec is very reasonable for a rotational drive. They *can* technically go faster, but only if you keep the workload almost entirely sequential. Most filesystems require a fair amount of seeking to write metadata, which slows them down quite a bit. |
4 |
> |
5 |
> If you're desperate for performance, you can do things like tell it to ignore write barriers and turn off various bits of flushing and increase the amount of allowed dirty write cache. These can be good for a significant performance boost at the cost of almost certainly corrupting the filesystem if the system loses power or crashes. |
6 |
> |
7 |
|
8 |
I've also found that on large drives the sequential write speed varies |
9 |
based on position in the drive. If I run something like badblocks on |
10 |
a new hard drive I'll see it start out at something like 200MB/s, and |
11 |
by the end it is around100MB/s. Then at the start of the next pass it |
12 |
will jump back up to 200MB/s. This is just direct block-level |
13 |
sequential writes so it is an ideal use case. |
14 |
|
15 |
As you say, ANY seeking will dramatically reduce the throughput. Time |
16 |
spent seeking is time not spent writing. There is no opportunity to |
17 |
"catch up" as the drive's read/write bandwidth is basically just a |
18 |
function of the recording density and rotational rate and number of |
19 |
platters/etc being read in parallel. If it is seeking it is a lost |
20 |
opportunity to read/write. |
21 |
|
22 |
-- |
23 |
Rich |