Hi all,
I'm experiencing some unexpected disk I/O latency on a newly built server. Here are some of the details:
- Supermicro motherboard with Intel PCH RAID [1]
- Debian 13.6 installed
- / is mounted on /dev/nvme0n1p2, which is an NVMe SSD, formatted with ext4
- /home is mounted on /dev/md125, which is a RAID 5 consisting of three disks, formatted with ext4
$ sudo mdadm -D /dev/md125
/dev/md125:
Container : /dev/md/imsm1, member 0
Raid Level : raid5
Array Size : 9279152128 (8.64 TiB 9.50 TB)
Used Dev Size : 4639576064 (4.32 TiB 4.75 TB)
Raid Devices : 3
Total Devices : 3
State : active
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-asymmetric
Chunk Size : 64K
Consistency Policy : resync

UUID : 2fbd736b:9b750e2a:e723b80c:df2f2c33
Number Major Minor RaidDevice State
2 8 0 0 active sync /dev/sda
1 8 16 1 active sync /dev/sdb
0 8 32 2 active sync /dev/sdc

I'm getting some weird latency issues with fsync on the RAID disk (/home on /dev/md125):
(Caveat: I'm doing a file transfer that is writing to /home, so I might expect some latency, but nothing like this.)
$ for i in {1..5}; do time sync; done 2>&1 | grep real
real 0m21.647s
real 0m11.770s
real 0m5.234s
real 0m3.023s
real 0m0.462s
Even when I turn off the file transfer, I still get something like this:
$ for i in {1..10}; do time sync; done 2>&1 | grep real
real 0m0.147s
real 0m0.077s
real 0m0.003s
real 0m0.004s
real 0m0.003s
I've tried turning on and off smart monitoring with smartctl to see if that would help, and it didn't seem to help.
I'm not really sure what else I might try, and I'm reaching out to the community to see if anyone has any suggestions for identifying and fixing the problem.
Thanks,
Casey
[1] https://www.supermicro.com/manuals/other/Intel_PCH_RAID_Config.pdf


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi,

On Wed, Jul 29, 2026 at 04:38:55PM -0600, Casey Deccio wrote:

- /home is mounted on /dev/md125, which is a RAID 5 consisting of three disks, formatted with ext4

I did not see anywhere in your email the details of what hardware these
disks are.

I'm not really sure what else I might try, and I'm reaching out to the community to see if anyone has any suggestions for identifying and fixing the problem.

I would start by a process of simplification. For example, does the sync
still take a long time when /home is not actually mounted? If so then
the issue is with your NVMe.

If it does occur when /home is mounted, then it is the disks in the RAID
setup or the RAID setup itself. Does each individual disk perform
anomalously?

"fio" is a good tool,to carry out performance testing of storage
devices. Have a look what the random 4k read and write I/O is like in
terms of IOPS, and the sequential disk transfer rate in MB/s for reads
or writes. You can try that on the array and then break the array and
try it on each individual disk. Obviously this is destructive to the
data.

If the performance is as expected on a per-disk basis but terrible only
with RAID, it may be time to post to the linux-raid mailing list as this
is unlikely to be a Debian-specific issue. I would then also be checking
if it happens in other RAID configurations like RAID-1.

150 IOPS of random reads (not coming from RAM) is reasonable for a
single 7.2kRPM SATA disk. You could expect 2-3x this from a RAID-5 of
three identical disks.

Write IOPS is a bit more difficult to guess and will depend on whether
you have disabled the write cache in the drives themselves. Due to the
RAID-5 write penalty (read-modify-write) you may expect only 50-70% of a
single disk's IOPS for random writes.

Of course, if your sd[abc] are SSDs then there should be plenty of IOPS available and those sync times are very weird.

"iostat -x 5" can give some more hints about what is going on.

If there is other I/O happening that you aren't expecting then "iotop"
can help identify it.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 7/29/26 15:38, Casey Deccio wrote:

Hi all,

I'm experiencing some unexpected disk I/O latency on a newly built server. Here are some of the details:

- Supermicro motherboard with Intel PCH RAID [1]
- Debian 13.6 installed
- / is mounted on /dev/nvme0n1p2, which is an NVMe SSD, formatted with ext4
- /home is mounted on /dev/md125, which is a RAID 5 consisting of three disks, formatted with ext4

$ sudo mdadm -D /dev/md125
/dev/md125:
Container : /dev/md/imsm1, member 0
Raid Level : raid5
Array Size : 9279152128 (8.64 TiB 9.50 TB)
Used Dev Size : 4639576064 (4.32 TiB 4.75 TB)
Raid Devices : 3
Total Devices : 3

State : active
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0

Layout : left-asymmetric
Chunk Size : 64K

Consistency Policy : resync

UUID : 2fbd736b:9b750e2a:e723b80c:df2f2c33
Number Major Minor RaidDevice State
2 8 0 0 active sync /dev/sda
1 8 16 1 active sync /dev/sdb
0 8 32 2 active sync /dev/sdc

I'm getting some weird latency issues with fsync on the RAID disk (/home on /dev/md125):
(Caveat: I'm doing a file transfer that is writing to /home, so I might expect some latency, but nothing like this.)

$ for i in {1..5}; do time sync; done 2>&1 | grep real
real 0m21.647s
real 0m11.770s
real 0m5.234s
real 0m3.023s
real 0m0.462s

Even when I turn off the file transfer, I still get something like this:

$ for i in {1..10}; do time sync; done 2>&1 | grep real
real 0m0.147s
real 0m0.077s
real 0m0.003s
real 0m0.004s
real 0m0.003s

I've tried turning on and off smart monitoring with smartctl to see if that would help, and it didn't seem to help.

I'm not really sure what else I might try, and I'm reaching out to the community to see if anyone has any suggestions for identifying and fixing the problem.

Thanks,
Casey

[1] https://www.supermicro.com/manuals/other/Intel_PCH_RAID_Config.pdf

What is the model number/ part number of your motherboard?


Have you disabled Intel PCH RAID in Setup -- e.g. so that the
motherboard disk interface ports appear as non-RAID ports (SATA/SAS)?


How are the disk drives connected to the motherboard? What is the speed rating of the cables? Do the cables have locking connectors? If you
are using backplanes/ racks, what is their speed rating?


Have you run SMART long tests on each of the three disk drives in the
RAID5? If not, please do so now. Please post the extended reports from
the top through and including the end of the section "SMART Attributes
Data Structure revision number: ...".


How are you transferring files? Please post your console session.


David

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Jul 29, 2026, at 6:51?PM, David Christensen

<dpchrist@holgerdanske.com> wrote:

What is the model number/ part number of your motherboard?

MBD-X12DPI-N6-O

Have you disabled Intel PCH RAID in Setup -- e.g. so that the

motherboard disk interface ports appear as non-RAID ports (SATA/SAS)?

No, I haven't tried that.

How are the disk drives connected to the motherboard? What is the

speed rating of the cables? Do the cables have locking connectors? If
you are using backplanes/ racks, what is their speed rating?

Thanks. These are all good questions. I don't have the cable specs or
speed ratings on hand (and won't be able to check them for a few days, unfortunately), but they are the cables that came with the motherboard.
In the mean time, I'll try some of the other tests that you (and others)
have kindly suggested.

As a point of reference, however, I built another machine with the same
drives and cables (different motherboard), and I haven't experienced
these issues.

Have you run SMART long tests on each of the three disk drives in the

RAID5? If not, please do so now. Please post the extended reports from
the top through and including the end of the section "SMART Attributes
Data Structure revision number: ...".

I've started the SMART long tests on the three drives in the RAID5. It
will take a few hours to run, so I'll report back.

How are you transferring files? Please post your console session.

From a different machine:

$ sudo rsync -av /home/someuser root@newmachine:/home/

Thank you!
Casey

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 7/29/26 19:01, Casey Deccio wrote:

On Jul 29, 2026, at 6:51?PM, David Christensen <dpchrist@holgerdanske.com> wrote:

What is the model number/ part number of your motherboard?

MBD-X12DPI-N6-O

That looks like a nice motherboard:

https://www.supermicro.com/en/products/motherboard/X12DPi-N6

Have you disabled Intel PCH RAID in Setup -- e.g. so that the motherboard disk interface ports appear as non-RAID ports (SATA/SAS)?

No, I haven't tried that.

I expect Intel PCH RAID is turned off, or you would not see all three
disks. But, it would be good to double check.

How are the disk drives connected to the motherboard? What is the speed rating of the cables? Do the cables have locking connectors? If you are using backplanes/ racks, what is their speed rating?

Thanks. These are all good questions. I don't have the cable specs or speed ratings on hand (and won't be able to check them for a few days, unfortunately), but they are the cables that came with the motherboard.

The motherboard has "14 SATA3 (6 Gbps)" ports and I expect the included
cables will match. I just wanted to make sure that you were not using leftover cables that could be 3 Gbps or 1.5 Gbps (been there, done that,
hated it).


For single SATA cables, I do prefer locking cables -- to prevent
accidental disconnects when I am working inside the case. These cables
are also marked "6 Gbps", so I can verify in the future:

https://www.cablematters.com/pc-187-156-3-pack-straight-60-gbps-sata-iii-cable.aspx

https://www.cablematters.com/pc-188-156-cable-matters-3-pack-90-degree-right-angle-60-gbps-sata-iii-cable-18-inches.aspx

In the mean time, I'll try some of the other tests that you (and others) have kindly suggested.

As a point of reference, however, I built another machine with the same drives and cables (different motherboard), and I haven't experienced these issues.

If that motherboard is more recent than Debian Stable, the included
Linux kernel might not support the C621A chipset and/or other chips on
the board. Please check if the Linux kernel in Debian 13.6 has support
for the Intel C621A chipset. Also check if there are bug reports for
that combination. If support is lacking, or if there are issues, you
might need a newer kernel from backports or you might need to run Testing.


Does dmesg(1) report any error messages during transfers?

Have you run SMART long tests on each of the three disk drives in the RAID5? If not, please do so now. Please post the extended reports from the top through and including the end of the section "SMART Attributes Data Structure revision number: ...".

I've started the SMART long tests on the three drives in the RAID5. It will take a few hours to run, so I'll report back.

Okay.

How are you transferring files? Please post your console session.

From a different machine:

$ sudo rsync -av /home/someuser root@newmachine:/home/

Rather than timing sync(1) commands on the destination machine, add the --progress option to rsync(1) on the source machine. Alternatively, add
the --verbose option. Understand that rsync(1) is doing a lot of work
behind the scenes and that network traffic can slow down, speed up,
pause, etc., over the course of a transfer.

Thank you!
Casey

YW.


David

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Jul 29, 2026, at 5:28?PM, Andy Smith <andy@strugglers.net>

wrote:

On Wed, Jul 29, 2026 at 04:38:55PM -0600, Casey Deccio wrote:

- /home is mounted on /dev/md125, which is a RAID 5 consisting of

three disks, formatted with ext4

I did not see anywhere in your email the details of what hardware

these

disks are.

Thanks. Correct, I omitted that. These are all:

Seagate BarraCuda 5TB Internal Hard Drive HDD ? 2.5 Inch SATA
6Gb/s 5400 RPM 128MB

I'm not really sure what else I might try, and I'm reaching out to

the community to see if anyone has any suggestions for identifying and
fixing the problem.

I would start by a process of simplification. For example, does the

sync

still take a long time when /home is not actually mounted? If so then
the issue is with your NVMe.

Thanks for the great idea. I just tested your proposed setup. I
unmounted /home and started the file transfer to /root (on the NVMe).
While the transfer was happening, I ran `time sync` again. The times
were much, much lower than what I was seeing when /home was mounted on /dev/md125.

If it does occur when /home is mounted, then it is the disks in the

RAID

setup or the RAID setup itself. Does each individual disk perform anomalously?

"fio" is a good tool,to carry out performance testing of storage
devices. Have a look what the random 4k read and write I/O is like in
terms of IOPS, and the sequential disk transfer rate in MB/s for reads
or writes. You can try that on the array and then break the array and
try it on each individual disk. Obviously this is destructive to the
data.

If the performance is as expected on a per-disk basis but terrible

only

with RAID, it may be time to post to the linux-raid mailing list as

this

is unlikely to be a Debian-specific issue. I would then also be

checking

if it happens in other RAID configurations like RAID-1.

150 IOPS of random reads (not coming from RAM) is reasonable for a
single 7.2kRPM SATA disk. You could expect 2-3x this from a RAID-5 of
three identical disks.

Write IOPS is a bit more difficult to guess and will depend on whether
you have disabled the write cache in the drives themselves. Due to the
RAID-5 write penalty (read-modify-write) you may expect only 50-70% of

a

single disk's IOPS for random writes.

Thanks for that very helpful information. I've run fio on the
still-assembled array, and here's what I get for read/write:

read: IOPS=237
write: IOPS=79

I'm not sure exactly what to make of that...

Of course, if your sd[abc] are SSDs then there should be plenty of

IOPS

available and those sync times are very weird.

Right. As mentioned above, these are not SSDs.

"iostat -x 5" can give some more hints about what is going on.

If there is other I/O happening that you aren't expecting then "iotop"
can help identify it.

Things seem to be idle when the file transfer is not happening. When it
is, iotop shows about 100% utilization for /dev/md125 and about 50 -
75% utilization of /dev/sd{a,b,c}. I haven't done comparisons with
anything else at this point to see how this compares. Thanks in the
mean time for the idea.

Casey

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Jul 29, 2026, at 10:23?PM, David Christensen

<dpchrist@holgerdanske.com> wrote:

That looks like a nice motherboard:

https://www.supermicro.com/en/products/motherboard/X12DPi-N6

Thanks :)

Have you disabled Intel PCH RAID in Setup -- e.g. so that the

motherboard disk interface ports appear as non-RAID ports (SATA/SAS)?

No, I haven't tried that.

I expect Intel PCH RAID is turned off, or you would not see all three

disks. But, it would be good to double check.

I was surprised to see the three disks also because I assumed it was a hardware RAID. But apparently Intel's PCH RAID is a software RAID
solution from everything I've read, which explains why mdadm is involved
and /dev/sd{a,b,c} show up.

How are the disk drives connected to the motherboard? What is the

speed rating of the cables? Do the cables have locking connectors? If
you are using backplanes/ racks, what is their speed rating?

Thanks. These are all good questions. I don't have the cable specs

or speed ratings on hand (and won't be able to check them for a few
days, unfortunately), but they are the cables that came with the
motherboard.

The motherboard has "14 SATA3 (6 Gbps)" ports and I expect the

included cables will match. I just wanted to make sure that you were
not using leftover cables that could be 3 Gbps or 1.5 Gbps (been there,
done that, hated it).

For single SATA cables, I do prefer locking cables -- to prevent

accidental disconnects when I am working inside the case. These cables
are also marked "6 Gbps", so I can verify in the future:


https://www.cablematters.com/pc-187-156-3-pack-straight-60-gbps-sata-iii-c able.aspx


https://www.cablematters.com/pc-188-156-cable-matters-3-pack-90-degree-rig ht-angle-60-gbps-sata-iii-cable-18-inches.aspx

Thanks for the helpful information. I'll double check when I can get a
the box, but I'm pretty sure the cables are securely seated -- if not
locked -- and that the rates are sufficient.

In the mean time, I'll try some of the other tests that you (and

others) have kindly suggested.

As a point of reference, however, I built another machine with the

same drives and cables (different motherboard), and I haven't
experienced these issues.

If that motherboard is more recent than Debian Stable, the included

Linux kernel might not support the C621A chipset and/or other chips on
the board. Please check if the Linux kernel in Debian 13.6 has support
for the Intel C621A chipset. Also check if there are bug reports for
that combination. If support is lacking, or if there are issues, you
might need a newer kernel from backports or you might need to run
Testing.

Since it's a software RAID, I wonder if this might be the issue. I'll
check the driver support to see what is in the kernel and also if there
are proprietary drivers that Intel provides.

Does dmesg(1) report any error messages during transfers?

Not that I can see.

Have you run SMART long tests on each of the three disk drives in

the RAID5? If not, please do so now. Please post the extended reports
from the top through and including the end of the section "SMART
Attributes Data Structure revision number: ...".

I've started the SMART long tests on the three drives in the RAID5.

It will take a few hours to run, so I'll report back.

Okay.

Still working on it, apparently.

How are you transferring files? Please post your console session.

From a different machine:
$ sudo rsync -av /home/someuser root@newmachine:/home/

Rather than timing sync(1) commands on the destination machine, add

the --progress option to rsync(1) on the source machine. Alternatively,
add the --verbose option. Understand that rsync(1) is doing a lot of
work behind the scenes and that network traffic can slow down, speed up, pause, etc., over the course of a transfer.

Thanks. I think that's what "-v" is doing? The transfers look good, as
far as I can tell. They might be a bit slower than I would expect, but transferring nonetheless. The problems I have observed have seemed to
be more with the I/O while the transfer is going than with the transfer itself, though there is probably more that I haven't uncovered.

Thanks,
Casey

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi,

On Thu, Jul 30, 2026 at 07:17:01AM -0600, Casey Deccio wrote:

Seagate BarraCuda 5TB Internal Hard Drive HDD ? 2.5 Inch SATA 6Gb/s 5400 RPM 128MB

Almost all high capacity 2.5" SATA drives are SMR (shingled magnetic
recording) and are really intended for use in laptops, not for serious
server purposes. I haven't checked this model but I would be very
surprised if it's not SMR, and the 5.4kRPM also suggests not for server
use.

SMR drives have a write cache and after this write cache is filled, the
write performance is absolutely terrible. A lot of people find them
unsuitable for use in RAID arrays (or zfs pools) because even the
periodic scrub can't complete in a reasonable time period.

This could easily explain the very low performance under write load
here. Have you used these models of drive before with a better
performance outcome?

Consumer-level SATA SSDs will definitely perform better though the cost
will be eye-watering (in comparison) for 3x ~4TB or 3x ~8TB. This is an
issue I have struggled with myself - very very hard to find decently
performing 2.5" SATA drives.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 30/07/26 at 15:40, Casey Deccio wrote:

If that motherboard is more recent than Debian Stable, the included Linux kernel might not support the C621A chipset and/or other chips on the board. Please check if the Linux kernel in Debian 13.6 has support for the Intel C621A chipset. Also check if there are bug reports for that combination. If support is lacking, or if there are issues, you might need a newer kernel from backports or you might need to run Testing.

Since it's a software RAID, I wonder if this might be the issue. I'll check the driver support to see what is in the kernel and also if there are proprietary drivers that Intel provides.

Have you enabled "non-free-firmware" in /e/a/sources.list to install the required Intel firmware packages?

Does dmesg(1) report any error messages during transfers?

Not that I can see.

To be absolutely sure please run:

~$ sudo journalctl -k -p 4 -b 0

Kind regards,
--
Franco Martelli

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

I'm getting some weird latency issues with fsync on the RAID disk
(/home on /dev/md125): (Caveat: I'm doing a file transfer that is
writing to /home, so I might expect some latency, but nothing
like this.)

$ for i in {1..5}; do time sync; done 2>&1 | grep real
real 0m21.647s
real 0m11.770s
real 0m5.234s
real 0m3.023s
real 0m0.462s

Why do you expect "nothing like this"?

I have no idea if your numbers are normal or not, but 21s on a 3-disk
RAID writing at max speed (i.e. 6Gb/s) is 6Gbx21 =~ 16GB.

So if the file transfer has accumulated 16GB of data in the write queue,
it's perfectly normal for `sync` to take 20s.
And if the file transfer goes at about 400MB/s, you'll have transferred
about 8GB during those 20s, so it stands to reason that the next sync
will still have 8GB to write to disk which will take another 10s,
and then 5s for the next, ...


=== Stefan

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 7/30/26 18:17, Casey Deccio wrote:

On Jul 29, 2026, at 5:28\u202fPM, Andy Smith<andy@strugglers.net> wrote:

...
If it does occur when /home is mounted, then it is the disks in the RAID
setup or the RAID setup itself. Does each individual disk perform
anomalously?

"fio" is a good tool,to carry out performance testing of storage
devices. Have a look what the random 4k read and write I/O is like in
terms of IOPS, and the sequential disk transfer rate in MB/s for reads
or writes. You can try that on the array and then break the array and
try it on each individual disk. Obviously this is destructive to the
data.

If the performance is as expected on a per-disk basis but terrible only
with RAID, it may be time to post to the linux-raid mailing list as this
is unlikely to be a Debian-specific issue. I would then also be checking
if it happens in other RAID configurations like RAID-1.

150 IOPS of random reads (not coming from RAM) is reasonable for a
single 7.2kRPM SATA disk. You could expect 2-3x this from a RAID-5 of
three identical disks.

Write IOPS is a bit more difficult to guess and will depend on whether
you have disabled the write cache in the drives themselves. Due to the
RAID-5 write penalty (read-modify-write) you may expect only 50-70% of a
single disk's IOPS for random writes.

Thanks for that very helpful information. I've run fio on the still-assembled array, and here's what I get for read/write:

read: IOPS=237
write: IOPS=79

I'm not sure exactly what to make of that...

I might add insult to the injury, but are you sure you need RAID-5 if it consists of just 3 drives?
Usually around 30% per drive's capacity will be sacrificed to hold error correction data for the array,
so maybe it will be much better to use 2 drives in RAID-1 (Mirror) configuration, if you need decent write performance.
Third drive could be used as spare device for the array, or a separate
storage without redundancy.
--
With kindest regards, Alexander.
Debian - The universal operating system
https://www.debian.org


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi,

On Fri, Jul 31, 2026 at 12:04:30AM +0500, Alexander V. Makartsev wrote:

I might add insult to the injury, but are you sure you need RAID-5 if it consists of just 3 drives?
Usually around 30% per drive's capacity will be sacrificed to hold error correction data for the array,
so maybe it will be much better to use 2 drives in RAID-1 (Mirror) configuration, if you need decent write performance.
Third drive could be used as spare device for the array, or a separate storage without redundancy.

On Linux mdadm you can also do a RAID-10 across three drives which still
allows for the loss of any single drive and provides both better read
and write performance compared to RAID-5 of the same devices. The
capacity would be 1.5 drives as opposed to 2.

However, if those really are 5.4kRPM SMR drives, I personally would not
want to use them for anything.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Jul 30, 2026, at 9:32?AM, Andy Smith <andy@strugglers.net>

wrote:

On Thu, Jul 30, 2026 at 07:17:01AM -0600, Casey Deccio wrote:

Seagate BarraCuda 5TB Internal Hard Drive HDD ? 2.5 Inch SATA

6Gb/s 5400 RPM 128MB

Almost all high capacity 2.5" SATA drives are SMR (shingled magnetic recording) and are really intended for use in laptops, not for serious
server purposes. I haven't checked this model but I would be very
surprised if it's not SMR, and the 5.4kRPM also suggests not for

server

use.

SMR drives have a write cache and after this write cache is filled,

the

write performance is absolutely terrible. A lot of people find them unsuitable for use in RAID arrays (or zfs pools) because even the
periodic scrub can't complete in a reasonable time period.

This could easily explain the very low performance under write load
here. Have you used these models of drive before with a better
performance outcome?

Consumer-level SATA SSDs will definitely perform better though the

cost

will be eye-watering (in comparison) for 3x ~4TB or 3x ~8TB. This is

an

issue I have struggled with myself - very very hard to find decently performing 2.5" SATA drives.

Thanks for the info. For this system I did optimize for cost,
understanding that there would be some tradeoffs with regard to
performance. I didn't suspect that these issues were related to the
drives because I have another setup using the same drives, and it
doesn't have this same issue. To be clear, it has these same drives and
it is using a RAID5, but it's on a different motherboard using a
MegaRAID controller with hardware RAID.

Thanks,
Casey

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Jul 30, 2026, at 10:36?AM, Franco Martelli

<martellif67@gmail.com> wrote:

On 30/07/26 at 15:40, Casey Deccio wrote:

If that motherboard is more recent than Debian Stable, the included

Linux kernel might not support the C621A chipset and/or other chips on
the board. Please check if the Linux kernel in Debian 13.6 has support
for the Intel C621A chipset. Also check if there are bug reports for
that combination. If support is lacking, or if there are issues, you
might need a newer kernel from backports or you might need to run
Testing.

Since it's a software RAID, I wonder if this might be the issue.

I'll check the driver support to see what is in the kernel and also if
there are proprietary drivers that Intel provides.

Have you enabled "non-free-firmware" in /e/a/sources.list to install

the required Intel firmware packages?

Yes, "non-free-firmware" is enabled, and there are plenty of intel
packages installed and modules loaded, but I'm not sure which is helpful
to this:

$ dpkg --list | grep intel
ii firmware-intel-graphics 20250410-2
all Binary firmware for Intel iGPUs and IPUs
ii firmware-intel-misc 20250410-2
all Binary firmware for miscellaneous Intel devices and chips
ii intel-microcode 3.20251111.1~deb13u1
amd64 Processor microcode firmware for Intel CPUs


$ lsmod | grep intel
intel_rapl_msr 20480 0
intel_rapl_common 53248 1 intel_rapl_msr
intel_uncore_frequency 12288 0
intel_uncore_frequency_common 16384 1 intel_uncore_frequency intel_powerclamp 16384 0
kvm_intel 413696 0
kvm 1396736 1 kvm_intel
ghash_clmulni_intel 16384 0
snd_hda_intel 61440 0
snd_intel_dspcfg 40960 1 snd_hda_intel
snd_intel_sdw_acpi 16384 1 snd_intel_dspcfg
aesni_intel 122880 0
snd_hda_codec 217088 3 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec_realtek
gf128mul 16384 1 aesni_intel
snd_hda_core 143360 4 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek crypto_simd 16384 1 aesni_intel
cryptd 28672 2 crypto_simd,ghash_clmulni_intel
snd_pcm 188416 3 snd_hda_intel,snd_hda_codec,snd_hda_core intel_cstate 20480 0
intel_uncore 266240 0
intel_th_gth 24576 0
snd 151552 7 snd_hda_codec_generic,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_ realtek,snd_timer,snd_pcm
intel_th_pci 12288 0
intel_th 28672 2 intel_th_gth,intel_th_pci
intel_vsec 20480 0
intel_pch_thermal 16384 0
intel_pmc_bxt 16384 1 iTCO_wdt
crc32c_intel 16384 5

Does dmesg(1) report any error messages during transfers?

Not that I can see.

To be absolutely sure please run:

~$ sudo journalctl -k -p 4 -b 0

Thanks. I ran it and also see nothing related there.

Casey

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Jul 30, 2026, at 1:04?PM, Alexander V. Makartsev <avbetev@gmail.com> wrote:

On 7/30/26 18:17, Casey Deccio wrote:

On Jul 29, 2026, at 5:28?PM, Andy Smith <andy@strugglers.net> <mailto:andy@strugglers.net> wrote:

...
If it does occur when /home is mounted, then it is the disks in the RAID >>> setup or the RAID setup itself. Does each individual disk perform
anomalously?

"fio" is a good tool,to carry out performance testing of storage
devices. Have a look what the random 4k read and write I/O is like in
terms of IOPS, and the sequential disk transfer rate in MB/s for reads
or writes. You can try that on the array and then break the array and
try it on each individual disk. Obviously this is destructive to the
data.

If the performance is as expected on a per-disk basis but terrible only
with RAID, it may be time to post to the linux-raid mailing list as this >>> is unlikely to be a Debian-specific issue. I would then also be checking >>> if it happens in other RAID configurations like RAID-1.

150 IOPS of random reads (not coming from RAM) is reasonable for a
single 7.2kRPM SATA disk. You could expect 2-3x this from a RAID-5 of
three identical disks.

Write IOPS is a bit more difficult to guess and will depend on whether
you have disabled the write cache in the drives themselves. Due to the
RAID-5 write penalty (read-modify-write) you may expect only 50-70% of a >>> single disk's IOPS for random writes.

Thanks for that very helpful information. I've run fio on the still-assembled array, and here's what I get for read/write:

read: IOPS=237
write: IOPS=79

I'm not sure exactly what to make of that...

I might add insult to the injury, but are you sure you need RAID-5 if it consists of just 3 drives?
Usually around 30% per drive's capacity will be sacrificed to hold error correction data for the array,
so maybe it will be much better to use 2 drives in RAID-1 (Mirror) configuration, if you need decent write performance.
Third drive could be used as spare device for the array, or a separate storage without redundancy.

Great ideas. I originally did RAID5 because I wasn't sure how many drives I wanted in the array, and I wondered if I might grow the array at some point. But I'll consider RAID 1 if I settle on three drives.
Thanks,
Casey


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Jul 30, 2026, at 1:04?PM, Stefan Monnier

<monnier@iro.umontreal.ca> wrote:

I'm getting some weird latency issues with fsync on the RAID disk
(/home on /dev/md125): (Caveat: I'm doing a file transfer that is
writing to /home, so I might expect some latency, but nothing
like this.)

$ for i in {1..5}; do time sync; done 2>&1 | grep real
real 0m21.647s
real 0m11.770s
real 0m5.234s
real 0m3.023s
real 0m0.462s

Why do you expect "nothing like this"?

I have no idea if your numbers are normal or not, but 21s on a 3-disk
RAID writing at max speed (i.e. 6Gb/s) is 6Gbx21 =~ 16GB.

So if the file transfer has accumulated 16GB of data in the write

queue,

it's perfectly normal for `sync` to take 20s.
And if the file transfer goes at about 400MB/s, you'll have

transferred

about 8GB during those 20s, so it stands to reason that the next sync
will still have 8GB to write to disk which will take another 10s,
and then 5s for the next, ...

Good thoughts. And fair enough. The sync output was not the original problem; that was something I was using to try to narrow things down,
but I can see how it might be a red herring.

The problem originally manifested itself when I was running commands
that called the fsync() system call, inducing long I/O delays. For
example, running `sudo -e ...` or even `man ...` (because of writing to `lesshst` in home directory). What helped me narrow it down a bit was noticing the `sudo man foo` seemed to have no delay issues (because it
wrote to /root, not on RAID), while `man foo` experienced major delays (because it wrote to /home on RAID). I used strace to narrow it down to
calls to fsync(). I was using sync to reproduce the issues from the
command line.

Casey

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 7/30/26 06:17, Casey Deccio wrote:

[The disk drives] are all:

Seagate BarraCuda 5TB Internal Hard Drive HDD ? 2.5 Inch SATA 6Gb/s 5400 RPM 128MB

https://www.seagate.com/products/hard-drives/barracuda-2-5-hard-drive/?sku=ST1000LM048


On 7/30/26 08:32, Andy Smith wrote:

Almost all high capacity 2.5" SATA drives are SMR (shingled magnetic recording)

Likely so:

https://www.seagate.com/products/cmr-smr-list/

and are really intended for use in laptops, not for serious
server purposes. I haven't checked this model but I would be very
surprised if it's not SMR, and the 5.4kRPM also suggests not for
server use.

I agree.


Seagate markets the Barracuda as a desktop disk drive. Exos is their
server drive.


On 7/30/26 13:30, Casey Deccio wrote:

Thanks for the info. For this system I did optimize for cost,

understanding that there would be some tradeoffs with regard to
performance. I didn't suspect that these issues were related to the
drives because I have another setup using the same drives, and it
doesn't have this same issue. To be clear, it has these same drives and
it is using a RAID5, but it's on a different motherboard using a
MegaRAID controller with hardware RAID.


On 7/30/26 13:46, Casey Deccio wrote:

The problem originally manifested itself when I was running commands

that called the fsync() system call, inducing long I/O delays. For
example, running `sudo -e ...` or even `man ...` (because of writing to `lesshst` in home directory). What helped me narrow it down a bit was noticing the `sudo man foo` seemed to have no delay issues (because it
wrote to /root, not on RAID), while `man foo` experienced major delays (because it wrote to /home on RAID). I used strace to narrow it down to
calls to fsync(). I was using sync to reproduce the issues from the
command line.


Perhaps the MegaRAID card caches writes to battery-backed RAM, reports synchronous write completion to the OS, and then writes the cache to the
disk drives later (?). This would allow OS and application synchronous
writes to complete quickly.


If the OP has unused space on the NVMe drive, perhaps they could use
that space to cache the RAID5 (?):

https://html.duckduckgo.com/html?q=linux%20ssd%20cache


David

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 7/30/26 14:49, Casey Deccio wrote:

On Jul 30, 2026, at 1:04?PM, Alexander V. Makartsev <avbetev@gmail.com> wrote:

On 7/30/26 18:17, Casey Deccio wrote:

On Jul 29, 2026, at 5:28?PM, Andy Smith<andy@strugglers.net> wrote:

...
If it does occur when /home is mounted, then it is the disks in the RAID >>>> setup or the RAID setup itself. Does each individual disk perform
anomalously?

"fio" is a good tool,to carry out performance testing of storage
devices. Have a look what the random 4k read and write I/O is like in
terms of IOPS, and the sequential disk transfer rate in MB/s for reads >>>> or writes. You can try that on the array and then break the array and
try it on each individual disk. Obviously this is destructive to the
data.

If the performance is as expected on a per-disk basis but terrible only >>>> with RAID, it may be time to post to the linux-raid mailing list as this >>>> is unlikely to be a Debian-specific issue. I would then also be checking >>>> if it happens in other RAID configurations like RAID-1.

150 IOPS of random reads (not coming from RAM) is reasonable for a
single 7.2kRPM SATA disk. You could expect 2-3x this from a RAID-5 of
three identical disks.

Write IOPS is a bit more difficult to guess and will depend on whether >>>> you have disabled the write cache in the drives themselves. Due to the >>>> RAID-5 write penalty (read-modify-write) you may expect only 50-70% of a >>>> single disk's IOPS for random writes.

Thanks for that very helpful information. I've run fio on the still-assembled array, and here's what I get for read/write:

read: IOPS=237
write: IOPS=79

I'm not sure exactly what to make of that...

I might add insult to the injury, but are you sure you need RAID-5 if it consists of just 3 drives?
Usually around 30% per drive's capacity will be sacrificed to hold error correction data for the array,
so maybe it will be much better to use 2 drives in RAID-1 (Mirror) configuration, if you need decent write performance.
Third drive could be used as spare device for the array, or a separate storage without redundancy.

Great ideas. ÿI originally did RAID5 because I wasn't sure how many drives I wanted in the array, and I wondered if I might grow the array at some point. ÿBut I'll consider RAID 1 if I settle on three drives.

A bit of analysis suggests this is a low performance server, mainly if not entirely because of the disks. The server board surely is not the bottleneck. As an earlier post suggested, the sync times noted are quite as should be expected.

The bottleneck almost certainly is the 6GBit/Sec consumer disks. The 6GBits/Sec transfer speed is only attainable on the cables from the system board to the individual disks. It implies a maximum transfer rate around 600 MBytes/Sec. but in sustained transfers, the disks cannot write that fast. AI query suggests 100-180 MB/Sec (depending on what part of the disk is being accessed) for CMR disks and 10-30 MB/Sec(!) for SMR disks. Raid 5 with 3 disks will reduce those to around 50% -75%, around 8-24 MB/sec so the expected average sustained write speed is unlikely to be more than 100MB/Sec. even with CMR disks. That is about, or slightly above, what is available from a Gigabit Ethernet transfer; for SMR disks, expect no more than around 25 MB/Sec. Large writes will take a while.

The pattern of sync times reported is consistent with that, suggesting that rsync makes the data available for writing somewhat faster than it can be written to the disk surfaces. Note that this doesn't apply to reading; the RAID will read and deliver data roughly twice as fast as a single disk and continue to do so on sustained reads as long as the data read is consumed at least as fast. Once the bulk data is transferred, performance may be satisfactory even with the low-spec drives.

The system with the Megaraid card would appear to perform better due to its internal cache: it will report write completion as soon as the data is in its cache (thus unblocking sync) and handle transfer to the disks internally. AI suggestion for the new server: set Write-Back rather than Write-Through for PCH Cache settings if that is not already done; that will allow the Intel driver to treat main memory as cache. It will not, however, make the data transfer any more quickly to the disks in the array.

AI was used here, but not extensively.

Regards,
Tom Dial

Thanks,
Casey

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 7/31/26 01:09, Andy Smith wrote:

Hi,

On Fri, Jul 31, 2026 at 12:04:30AM +0500, Alexander V. Makartsev wrote:

I might add insult to the injury, but are you sure you need RAID-5 if it
consists of just 3 drives?
Usually around 30% per drive's capacity will be sacrificed to hold error
correction data for the array,
so maybe it will be much better to use 2 drives in RAID-1 (Mirror)
configuration, if you need decent write performance.
Third drive could be used as spare device for the array, or a separate
storage without redundancy.

On Linux mdadm you can also do a RAID-10 across three drives which still allows for the loss of any single drive and provides both better read
and write performance compared to RAID-5 of the same devices. The
capacity would be 1.5 drives as opposed to 2.

That is an interesting idea.
The RAID-10 configuration you proposing should then consist of 3 RAID-1 (mirror) groups, so 3 drives must be partitioned in halves and to finish RAID-10 array, there should be a RAID-0 (stripe) array created across
all 3 groups.
Will the RAID-0 (stripping) layer of RAID-10 configuration significantly improve the write performance of the array in comparison to a basic
RAID-1 array?
With the today's abysmal prices of storage devices of any kind, I don't
think I will be able to test this any time soon...
--
With kindest regards, Alexander.
Debian - The universal operating system
https://www.debian.org


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Jul 31, 2026, at 12:40?AM, Tom Dial <tddial@comcast.net> wrote:

On 7/30/26 14:49, Casey Deccio wrote:

On Jul 30, 2026, at 1:04?PM, Alexander V. Makartsev <avbetev@gmail.com> wrote:

On 7/30/26 18:17, Casey Deccio wrote:

On Jul 29, 2026, at 5:28?PM, Andy Smith<andy@strugglers.net> wrote:

...
If it does occur when /home is mounted, then it is the disks in the RAID >>>>> setup or the RAID setup itself. Does each individual disk perform
anomalously?

"fio" is a good tool,to carry out performance testing of storage
devices. Have a look what the random 4k read and write I/O is like in >>>>> terms of IOPS, and the sequential disk transfer rate in MB/s for reads >>>>> or writes. You can try that on the array and then break the array and >>>>> try it on each individual disk. Obviously this is destructive to the >>>>> data.

If the performance is as expected on a per-disk basis but terrible only >>>>> with RAID, it may be time to post to the linux-raid mailing list as this >>>>> is unlikely to be a Debian-specific issue. I would then also be checking >>>>> if it happens in other RAID configurations like RAID-1.

150 IOPS of random reads (not coming from RAM) is reasonable for a
single 7.2kRPM SATA disk. You could expect 2-3x this from a RAID-5 of >>>>> three identical disks.

Write IOPS is a bit more difficult to guess and will depend on whether >>>>> you have disabled the write cache in the drives themselves. Due to the >>>>> RAID-5 write penalty (read-modify-write) you may expect only 50-70% of a >>>>> single disk's IOPS for random writes.

Thanks for that very helpful information. I've run fio on the still-assembled array, and here's what I get for read/write:

read: IOPS=237
write: IOPS=79

I'm not sure exactly what to make of that...

I might add insult to the injury, but are you sure you need RAID-5 if it consists of just 3 drives?
Usually around 30% per drive's capacity will be sacrificed to hold error correction data for the array,
so maybe it will be much better to use 2 drives in RAID-1 (Mirror) configuration, if you need decent write performance.
Third drive could be used as spare device for the array, or a separate storage without redundancy.

Great ideas. I originally did RAID5 because I wasn't sure how many drives I wanted in the array, and I wondered if I might grow the array at some point. But I'll consider RAID 1 if I settle on three drives.

A bit of analysis suggests this is a low performance server, mainly if not entirely because of the disks. The server board surely is not the bottleneck. As an earlier post suggested, the sync times noted are quite as should be expected.

The bottleneck almost certainly is the 6GBit/Sec consumer disks. The 6GBits/Sec transfer speed is only attainable on the cables from the system board to the individual disks. It implies a maximum transfer rate around 600 MBytes/Sec. but in sustained transfers, the disks cannot write that fast. AI query suggests 100-180 MB/Sec (depending on what part of the disk is being accessed) for CMR disks and 10-30 MB/Sec(!) for SMR disks. Raid 5 with 3 disks will reduce those to around 50% -75%, around 8-24 MB/sec so the expected average sustained write speed is unlikely to be more than 100MB/Sec. even with CMR disks. That is about, or slightly above, what is available from a Gigabit Ethernet transfer; for SMR disks, expect no more than around 25 MB/Sec. Large writes will take a while.

The pattern of sync times reported is consistent with that, suggesting that rsync makes the data available for writing somewhat faster than it can be written to the disk surfaces. Note that this doesn't apply to reading; the RAID will read and deliver data roughly twice as fast as a single disk and continue to do so on sustained reads as long as the data read is consumed at least as fast. Once the bulk data is transferred, performance may be satisfactory even with the low-spec drives.

The system with the Megaraid card would appear to perform better due to its internal cache: it will report write completion as soon as the data is in its cache (thus unblocking sync) and handle transfer to the disks internally. AI suggestion for the new server: set Write-Back rather than Write-Through for PCH Cache settings if that is not already done; that will allow the Intel driver to treat main memory as cache. It will not, however, make the data transfer any more quickly to the disks in the array.

AI was used here, but not extensively.

Thanks for the assessment. And also thanks to all the other respondents for their contributions.
I can't really change the hardware I have, but this is helpful for figuring out how to move forward, both with my current system and for future system design.
Casey


--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, Jul 30, 2026 at 07:43:36PM -0700, David Christensen wrote:

Perhaps the MegaRAID card caches writes to battery-backed RAM, reports >synchronous write completion to the OS, and then writes the cache to
the disk drives later (?). This would allow OS and application
synchronous writes to complete quickly.

Yes, raid 5/6 is basically only usable for write-heavy loads if there's
a write cache. A single block write requires a read of any other blocks
in a stripe in order to generate checksum data. In an application that
syncs data to disk that turns a series of writes into read-write-read-write-read-write which will kill performance. With a non-volatile cache that remains write-write-write (assuming the writes
can be consolidated so an entire block + parity can be written without
needing to read in stale data) or at least hides the latency issues if
the cache doesn't fill completely. You could theoretically cache the
writes without the nv memory, but the chances of corruption on power
failure or crash are very, very high.

As others have suggested, a small array on consumer hardware is much
more useful as a raid 1 than a raid 5.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 7/30/26 14:49, Casey Deccio wrote:

Great ideas. ÿI originally did RAID5 because I wasn't sure how many
drives I wanted in the array, and I wondered if I might grow the array
at some point. ÿBut I'll consider RAID 1 if I settle on three drives.

Something over 10yr ago I was running RAID5 on a Windows 7 box, as I
recall, the disks were probably 500GB Seagate Baracuda as that is what I tended to buy in that era.ÿ This was my second stab at RAID setup, and I
was unimpressed with the performance. Writes were way slow and the pool
kept randomly dropping disks.

My next RAID was RAIDZ with ZFS filesystem on FreeNAS (now TrueNAS),
running the same disks moved from the Win7 box wiped+reformatted, much
better performance. Now in recent years moved to Debian, and I've rarely
tried anything else since, except for the occasional odd RAID0 or RAID1
setup.

If your disks are SMR type then you might want to avoid ZFS. I think eventually, newer SMR disks will play nicer with ZFS than the first generations did. Maybe they're already there, I haven't followed SMR
news recently.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi,

On Fri, Jul 31, 2026 at 12:41:24PM +0500, Alexander V. Makartsev wrote:

On 7/31/26 01:09, Andy Smith wrote:

On Linux mdadm you can also do a RAID-10 across three drives which still allows for the loss of any single drive and provides both better read
and write performance compared to RAID-5 of the same devices. The
capacity would be 1.5 drives as opposed to 2.

That is an interesting idea.
The RAID-10 configuration you proposing should then consist of 3 RAID-1 (mirror) groups, so 3 drives must be partitioned in halves and to finish RAID-10 array, there should be a RAID-0 (stripe) array created across all 3 groups.

No, Linux mdadm just does it natively. Just as you do not need to make
sets of RAID-1 and then put RAID-0 on top for RAID-10 of even numbers of drives, so you do not need to do any partitioning tricks with odd
numbers of drives. mdadm just directly works it out.

The biggest downside is that mdadm RAID-10 is hard to alter the shape of
if you add or remove drives later.

This is all pretty old tech by now of course. Copy-on-write filesystems
like btrfs and zfs do things in a much better way. I had high hopes for bcachefs, alas?

Will the RAID-0 (stripping) layer of RAID-10 configuration significantly improve the write performance of the array in comparison to a basic RAID-1 array?

It's not going to be dramatic when you compare a 2 drive RAID-1 to a 3
drive RAID-10 to a 3 drive RAID-5, but yes because stripes go across
multiple drives whereas with RAID-1 there is only ever one drive worth
of write IOPS.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi,

On Fri, Jul 31, 2026 at 09:59:54AM -0500, nwe wrote:

If your disks are SMR type then you might want to avoid ZFS. I think eventually, newer SMR disks will play nicer with ZFS than the first generations did. Maybe they're already there, I haven't followed SMR news recently.

I think it is more likely that *ZFS* will end up able to play nicer with
SMR disks, by altering (lowering) its expectations and specifically
catering to devices with pitiful random write performance! There's very
little motivation for manufacturers of SMR drives to make them work
better in ZFS and RAID setups because their target market is
desktop/laptop users. They'd much rather sell their more expensive
enterprise models! But as far as I understand there is some interest in
making ZFS work better with weird storage backends like SMR and even
remote block storage (e.g. S3-compatible).

With ZFS you can already get some way by putting the ZFS intent log
(ZIL) on a pair of fast power-loss-protected storage like (part of)
decent NVMe drives, then forcing all writes to be sync so they go
through the ZIL, only hitting the slow storage as streaming writes at 5
second intervals. That's a bit like what the non-volatile write cache is
doing in a hardware RAID HBA. We still can't get away from the fact that
even streaming sequential writes are slow on SMR drives though.

There aren't any good software solutions for this outside of ZFS at the
moment as far as I have found. lvmcache exists but hasn't seen
development in ages, was really clunky and underwhelming when I last
tried it. I had some hopes for bcachefs.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 7/31/26 06:45, Casey Deccio wrote:

... thanks to all the other respondents for their contributions.

I can't really change the hardware I have, but this is helpful for figuring out how to move forward, both with my current system and for future system design.

Thank you for the interesting question and hardware.


What is your computing/ network environment?


What is the purpose of the server?


What other components are in the server -- chassis, power supplies, processors, memory modules, add-on cards, modules, keys, interfaces, etc.?


What is your budget?


What is your schedule?


David

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)