June 7, 20197 yr I am experiencing slow and inconsistent write speeds on my SSD cache. I am copying large movie files (~30GB) to my server to the cache drive and am seeing fluctuations from ~20MB/s to 70MB/s. I should be getting a fairly solid 111/112MB/s on my gigabit LAN. Nothing is really hitting the SSD or the net work so my top speed should be faster and much more consistent. I am using a 1 year old SanDisk Plus 240 GB which is 4% filled normally. I have verified this is not a network problem because I can get a steady 1 Gbps transfer between two other machines on the LAN. I will provide any additional information needed. I am new on the forum and am not sure what could be helpful. Thank you in advance.
June 7, 20197 yr Community Expert Go to Tools-diagnostics and attach the complete Diagnostics zip file to your next post.
June 8, 20197 yr Community Expert The diagnostics show you are running 6.7.0 rc4 which was one of the early 6.7 rc releases from the ‘next’ branch. Any reason you are not running 6.7.0 stable (or 6.7.1 rc1 from the ‘next’ branch). If not it might be worth upgrading to see if the problem persists as a lot of packages have been upgraded since the release you are running.
June 8, 20197 yr Author I had this issue on 6.6.7 (latest stable 6.6.X) as well. I switched to get Nvidia drivers installed for Plex hardware transcoding. I can try upgrading to 6.7.1 rc1 with the Nvidia drivers. I suspect the problem lies with my network setup in Unraid or with the cache settings. It could be the drive, but I doubt it. Edited June 8, 20197 yr by xl3b4n0nx typo
June 8, 20197 yr Community Expert Some ATA errors on the cache device: Jun 7 07:58:24 Tower kernel: ata4.00: exception Emask 0x0 SAct 0xf0000000 SErr 0x0 action 0x6 frozen Jun 7 07:58:24 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Jun 7 07:58:24 Tower kernel: ata4.00: cmd 60/10:e0:78:53:68/00:00:00:00:00/40 tag 28 ncq dma 8192 in Jun 7 07:58:24 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Jun 7 07:58:24 Tower kernel: ata4.00: status: { DRDY } Jun 7 07:58:24 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Jun 7 07:58:24 Tower kernel: ata4.00: cmd 60/10:e8:90:53:68/00:00:00:00:00/40 tag 29 ncq dma 8192 in Jun 7 07:58:24 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Jun 7 07:58:24 Tower kernel: ata4.00: status: { DRDY } Jun 7 07:58:24 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Jun 7 07:58:24 Tower kernel: ata4.00: cmd 60/08:f0:a8:53:68/00:00:00:00:00/40 tag 30 ncq dma 4096 in Jun 7 07:58:24 Tower kernel: res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Jun 7 07:58:24 Tower kernel: ata4.00: status: { DRDY } Jun 7 07:58:24 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Jun 7 07:58:24 Tower kernel: ata4.00: cmd 60/08:f8:08:ef:55/00:00:00:00:00/40 tag 31 ncq dma 4096 in Jun 7 07:58:24 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Jun 7 07:58:24 Tower kernel: ata4.00: status: { DRDY } Jun 7 07:58:24 Tower kernel: ata4: hard resetting link Jun 7 07:58:24 Tower kernel: ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jun 7 07:58:24 Tower kernel: ata4.00: configured for UDMA/133 Likely connection related, replace cables, also that is a TLC based SSD, don't expect more than 80/100MB/s sustained writes in the best of conditions.
June 8, 20197 yr Author Thank you for finding those. I'll swap out the cable and keep an eye out for more of them. I though TLC SSDs could handle faster sustained writes than that. What is a way I could speed that up? Add another drive? Maybe btrfs raid 10 with 4 drives?I haven't looked into any cache drive configurations beyond a single and multiple non-raid drives. I don't need a particularly large cache, 240 - 480 GB is fine. I would just like it to be able to sustain gigabit+ speeds.
June 8, 20197 yr Community Expert Raid10 pool should be enough to sustain gigagit, alternatively get a faster 3D TLC device, like the 860EVO or MX500.
Archived
This topic is now archived and is closed to further replies.