![]() (fuseblk /dev/sdb1 465.8 GiB) ioping statistics -Ģ11 requests completed in 3.00 s, 844 KiB written, 70 iops, 281.6 KiB/s (ext4 /dev/sda1 457.4 GiB) ioping statistics -Ĥ16 requests completed in 2.99 s, 1.62 MiB written, 139 iops, 557.3 KiB/s I just have to make sure to change directory to the ioping directory before I run my tests. And the -R option encapsulates several other options to create a three second test which gives the behavior I want.įrom among these options, it looks like ioping -RW. I’m looking for more of a performance test. And as a precaution I created a directory for testing called ioping: /run/media/michael/Data/ioping/īy default, ioping will mimic ping and perform one operation per second until stopped. For example, the sdb file system is attached at /run/media/michael/Data/ on my computer. To use the file system, we must provide the path to a directory on sdb. To specify a write test, we use the -W option. So, I don’t need any option to specify random access. In the examples below, I only use -W with directory targets.īy default, ioping will perform random access. Note the -W option will destroy data if used with a file or device target. But the basic kinds are:įrom among these options, the ones that most closely match my issue are random writes to the file system. So, I’d like to try to reproduce that workload with ioping. The problem I noticed was huge latency while saving documents. Using these options with ioping gives the sustained transfer rate. Remember these two discs are the same model. Its average speed was 5.00 MiB/s which is pretty bad. Now look at the result for /dev/sdb which is the disc having trouble. So the performance of sda looks pretty good. The specification for the drive (ST3500320AS) lists “105 Mbytes/sec max”. I’m fortunate because I have two identical discs I can compare.īut that is not necessary. dev/sdb (block device 465.8 GiB) ioping statistics -Ħ8 requests completed in 3.42 s, 17 MiB read, 19 iops, 4.97 MiB/s dev/sda (block device 465.8 GiB) ioping statistics -ġ.27 k requests completed in 2.92 s, 316.8 MiB read, 433 iops, 108.3 MiB/s With regard to my request for troubleshooting advice, the best information I got was from ioping: sudo ioping -RL /dev/sda And I copied my data to network attached storage. And I’d like to fix the performance issue.įirst of all my issue is resolved because I ordered a replacement hard disc. Or I’d like to measure/graph the latency if that is all that can be done. I’d like to see the error that is occuring when I write to the disc. But I don’t know what troubleshooting commands are relevant. I have a feeling that some debug log would reveal the issue. I only installed Manjaro in the last few weeks. That live USB image has the same software versions I had while the hard disc was working correctly. And writing to the disc from the live system was also slow. I tried checking Linux logs, running fsck, running SeaTools, chkdsk, and accessing the disc from a bootable USB drive. I can’t explain why the problem only occurs in Manjaro. ![]() I can’t think of anything relevant which has changed in the last few days. I don’t have a problem writing to this disc in Windows. I don’t have a problem writing to other discs. I don’t have a problem reading from the disc. ![]() The information and testing routines in SeaTools 5 (Linux) goes beyond those available in Linux Mint's Disks.My secondary hard disc has had increased write latency for the past few days. Using Cinnamon's menu editor, I placed a link to run_SeaTools.sh in the Administration folder for convenient access. Use this Linux version of the SeaTools GUI to diagnose hard drives and monitor SSDs.īy default, it installs into /opt and works under both Linux Mint 20.3 and 21 Cinnamon. I then did some further research on this HDD which also led me to Seagate's Web site where I was pleased to discover a version of SeaTools for Linux on offer: Due to a catastrophic controller chip failure on a KINGSTON SUV500960G SSD which invoked and scrambled the drive's built-in encryption feature (which I never used), thus rendering the SSD permanently unreadable even by gparted, I was forced to install a 2TB Seagate-Samsung Spinpoint M9T ST2000LM003 HN-M201RAD HDD in the notebook in my signature: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |