3 ms·
It's much worse than that. For SSD, it's just the blocks need to be zeroed before being writing to, which is not even an issue if there is lot of free space. B
by mrjin 7y ago
It's much worse than that. For SSD, it's just the blocks need to be zeroed before being writing to, which is not even an issue if there is lot of free space.
But for SMR, the reading track is narrower than writing track. For example, reading track's width is 1 unit, writing track's width is 2 unit, there is a 1 unit overlap between two adjacent tracks.
And here is how it works, assuming writing sequentially:
1. Start with blank disk, and write to track #1. This is happy case, as no data there, we can simply write to it.
2. Write to track #2. Still can simply write to it. However, this will overwrite lower half of track #1, but as long as reading only need 1 unit, track #1 record is still good.
3. Write to the following tracks one by one, all good, same story with step #2, over writing half of previous track.
4. Repeat until track #n.
5. Okay, all of a sudden, now we need to change something in track #1. What would happen now: we cannot simply overwrite the stuff in track #1 as this will overwrite the top half of track #2, which is the reading track of track #2. So we'll have to read out track #2 and and write track #1 and then write back track #2, which in turn has to read out track #3 and write track #2 and write back track #3...
6. Repeat the previous operation until all impacted tracks are written back.
In reality, the situation could be slightly better: if the disk is almost empty, the firmware can always find somewhere to write to without reading out and writing back. But if the disk is relatively full, then the case could be much worse: every writing could technically trigger another reading out and writing back operation. So how long would it take to finish a writing operation can hardly be predicted.
The worse case is that the disk is full and the writing is targeting whole track #1, then almost the entire disk need to be refreshed so that it can complete the operation...
- donmcronald 7y agoWow. That’s how I had visualized it in my mind when I read how they work, but I figured I was wrong because it seemed too dumb and I thought there’s no way it could work like that. Thanks for explaining. It would be amazing for someone to come up with a “worst case write” benchmark for SMR drives.
- magicalhippo 7y agoDon't they have some non-overlapping tracks every now and then so these "write avalanches" don't continue all the way?
- donmcronald 7y agoYes. This [0] is over my head, but section 4.7 seems to indicate about 30 MiB at a time would be the worst case. I’m not certain though. [0] http://blog.schmorp.de/data/smr/fast15-paper-aghayev.pdf http://blog.schmorp.de/data/smr/fast15-paper-aghayev.pdf
- magicalhippo 7y agoVery interesting paper, thanks! The band size of 17-30MiB is a lot less than the 256MiB mentioned here by others.