4 ms·

My understanding is that the SMR drives are like SSD to a degree that they needs rather intelligent firmware to place the information on the disk. At the momen

My understanding is that the SMR drives are like SSD to a degree that they needs rather intelligent firmware to place the information on the disk. At the moment everything is sitting behind the bogo SATA disk interface which was never designed for this type of storage - rapid burst writes to the 20GB onboard buffer area and than very slow I/O as it is emptied out. Surely a native OS interface would be better for these drives.

nicoburns 7y ago
It's worse than that. SMR drives can't do random writes without rewriting large sections. So they are entirely unsuitable for general purpose workloads.
- eru 7y ago
  Weren't journalling filesystems supposed to help with bad random write performance?
  - tveita 7y ago
    File system journaling typically refers to a log that helps ensure filesystem consistency by recording attempted operations before they happen, but the system still has to do all the same random writes to the disk afterwards. Some file systems (notably ZFS and Btrfs) use a copy-on-write approach that should in theory not require many random writes, but I don't think any of them are adapted for the large blocks you need to write to for SMR. (256MB?) It should be possible to make a filesystem with drastically better performance on SMR drives given the right low-level access, probably based on something more like a log-structured merge-tree, like e.g. LevelDB. One interesting example I found was Dropbox which seems to store data on SMR in big immutable chunks using raw Zoned Block Command access. https://dropbox.tech/infrastructure/smr-what-we-learned-in-our-first-year https://dropbox.tech/infrastructure/smr-what-we-learned-in-o...
    - klodolph 7y ago
      > It should be possible to make a filesystem with drastically better performance on SMR drives given the right low-level access, probably based on something more like a log-structured merge-tree, like e.g. LevelDB. The filesystem would need to do periodic compaction. You would necessarily encounter situations where a write to “allocated” data would fail because the disk is out of space, which is a new, surprising error that would undoubtedly confuse some user-space programs.
      - eru 7y ago
        You could go around that error by claiming a lower capacity. All file systems take up a bit of space to store their own metadata etc. So users are already used to 'lose' a bit of space on formatting.
        klodolph 7y ago
        That wouldn’t fix it. As long as programs can write faster than the compaction algorithm frees space, you can run out of space. The only solutions I see here are to block IO until the compaction algorithm frees space, or return ENOSPC. Both options violate assumptions that real-world programs make.
  - brandmeyer 7y ago
    I think you actually mean log-structured filesystems. They help with poor random write performance only at the cost of poor sequential read performance. Both SMR drives and SSDs benefit greatly from sequential reads. A file that was randomly written will be read back in random order regardless of the reader's interest.
    - eru 7y ago
      Yes, I meant log-structured filesystems.
- eeZah7Ux 7y ago
  > SMR drives can't do random writes without rewriting large sections Sounds like a perfect use-case for log-based filesystems.
- lallysingh 7y ago
  Sounds like the same problem SSDs have, only really slow and shitty.
isatty 7y ago
It seems like a rotational disk that supports TRIM is SMR but not all SMR disks support TRIM[0]. [0] https://github.com/openzfs/zfs/issues/10182 https://github.com/openzfs/zfs/issues/10182
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 ago
  Wow. 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 ago
  Don't they have some non-overlapping tracks every now and then so these "write avalanches" don't continue all the way?

nicoburns 7y ago

It's worse than that. SMR drives can't do random writes without rewriting large sections. So they are entirely unsuitable for general purpose workloads.

eru 7y ago
Weren't journalling filesystems supposed to help with bad random write performance?
- tveita 7y ago
  File system journaling typically refers to a log that helps ensure filesystem consistency by recording attempted operations before they happen, but the system still has to do all the same random writes to the disk afterwards. Some file systems (notably ZFS and Btrfs) use a copy-on-write approach that should in theory not require many random writes, but I don't think any of them are adapted for the large blocks you need to write to for SMR. (256MB?) It should be possible to make a filesystem with drastically better performance on SMR drives given the right low-level access, probably based on something more like a log-structured merge-tree, like e.g. LevelDB. One interesting example I found was Dropbox which seems to store data on SMR in big immutable chunks using raw Zoned Block Command access. https://dropbox.tech/infrastructure/smr-what-we-learned-in-our-first-year https://dropbox.tech/infrastructure/smr-what-we-learned-in-o...
  - klodolph 7y ago
    > It should be possible to make a filesystem with drastically better performance on SMR drives given the right low-level access, probably based on something more like a log-structured merge-tree, like e.g. LevelDB. The filesystem would need to do periodic compaction. You would necessarily encounter situations where a write to “allocated” data would fail because the disk is out of space, which is a new, surprising error that would undoubtedly confuse some user-space programs.
    - eru 7y ago
      You could go around that error by claiming a lower capacity. All file systems take up a bit of space to store their own metadata etc. So users are already used to 'lose' a bit of space on formatting.
      - klodolph 7y ago
        That wouldn’t fix it. As long as programs can write faster than the compaction algorithm frees space, you can run out of space. The only solutions I see here are to block IO until the compaction algorithm frees space, or return ENOSPC. Both options violate assumptions that real-world programs make.
- brandmeyer 7y ago
  I think you actually mean log-structured filesystems. They help with poor random write performance only at the cost of poor sequential read performance. Both SMR drives and SSDs benefit greatly from sequential reads. A file that was randomly written will be read back in random order regardless of the reader's interest.
  - eru 7y ago
    Yes, I meant log-structured filesystems.
eeZah7Ux 7y ago
> SMR drives can't do random writes without rewriting large sections Sounds like a perfect use-case for log-based filesystems.
lallysingh 7y ago
Sounds like the same problem SSDs have, only really slow and shitty.

isatty 7y ago

It seems like a rotational disk that supports TRIM is SMR but not all SMR disks support TRIM[0]. [0] https://github.com/openzfs/zfs/issues/10182 https://github.com/openzfs/zfs/issues/10182

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 ago
Wow. 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 ago
Don't they have some non-overlapping tracks every now and then so these "write avalanches" don't continue all the way?