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