Re: Disk I/O slowness

David Christensen <[email protected]> Thu, 30 Jul 2026 19:43:36 -0700
Newsgroups gmane.linux.debian.user
Message-ID <[email protected]>
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