4 ms·

Yes, you will notice this, even if you do a simple write test with only big writes at full speed. After a while (about 2h in our tests) these drives become "tir

Yes, you will notice this, even if you do a simple write test with only big writes at full speed. After a while (about 2h in our tests) these drives become "tired". You need to leave them be for a few hours and then they are fine again. An added problem is that the usual candidate file systems (ext4, xfs,...) do not combine well with SMR. Some people might be able to put these drives to good use, but only if they know up front that it's this kind of drive they are getting.

read_if_gay_ 7y ago
> After a while (about 2h in our tests) these drives become "tired". You need to leave them be for a few hours and then they are fine again. Why does that happen?
- jsjohnst 7y ago
  > Why does that happen? Because with DM-SMR drives there is usually a non-shingled area on the drive used as a buffer. Once the buffer is full, performance tanks dramatically as tracks are being rewritten. This is especially true in my experience when writing lots of smallish files vs several very large files.
MisterTea 7y ago
That's a good way of explaining it and makes sense. I have 3x4TB WD Reds configured as an 8TB RAID 5 mdadm array in my Linux box. It's a sort of dumping grounds for backups/disk images, VMm images, etc. I would see initial write speeds of 150-200MB/sec but during large transfers moving 100's of GB, it would drop in write speed down to 50-60MB/sec. I thought it was a performance issue in the kernel or with mdadm and didn't bother to investigate further because I'm not a datacenter.
jjgreen 7y ago
I've observed exactly this behaviour on TB volumes on AWS instances, is it known if they use this sort of drive?
- gray_-_wolf 7y ago
  That is probably more relates to IOPS credits I would think.
- ciceryadam 7y ago
  Check I/O Credits and Burst Performance at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volu...
- toolslive 7y ago
  don't assume that if you hire a volume on AWS that you get a device. The thing you get is a virtual block device and is actually the entry point of a sophisticated piece of software that will spread your data over multiple devices (might be erasure coded, might be replicated, probably hierarchical, so data comes in on NVMe, is then moved to SSD and eventually to HDD). So whatever you're seeing, it's not the behaviour of a single HDD.
- jjgreen 7y ago
  Thanks for all the pointers!

read_if_gay_ 7y ago

> After a while (about 2h in our tests) these drives become "tired". You need to leave them be for a few hours and then they are fine again. Why does that happen?

jsjohnst 7y ago
> Why does that happen? Because with DM-SMR drives there is usually a non-shingled area on the drive used as a buffer. Once the buffer is full, performance tanks dramatically as tracks are being rewritten. This is especially true in my experience when writing lots of smallish files vs several very large files.

MisterTea 7y ago

That's a good way of explaining it and makes sense. I have 3x4TB WD Reds configured as an 8TB RAID 5 mdadm array in my Linux box. It's a sort of dumping grounds for backups/disk images, VMm images, etc. I would see initial write speeds of 150-200MB/sec but during large transfers moving 100's of GB, it would drop in write speed down to 50-60MB/sec. I thought it was a performance issue in the kernel or with mdadm and didn't bother to investigate further because I'm not a datacenter.

jjgreen 7y ago

I've observed exactly this behaviour on TB volumes on AWS instances, is it known if they use this sort of drive?

gray_-_wolf 7y ago
That is probably more relates to IOPS credits I would think.
ciceryadam 7y ago
Check I/O Credits and Burst Performance at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volu...
toolslive 7y ago
don't assume that if you hire a volume on AWS that you get a device. The thing you get is a virtual block device and is actually the entry point of a sophisticated piece of software that will spread your data over multiple devices (might be erasure coded, might be replicated, probably hierarchical, so data comes in on NVMe, is then moved to SSD and eventually to HDD). So whatever you're seeing, it's not the behaviour of a single HDD.
jjgreen 7y ago
Thanks for all the pointers!