On Sun, Nov 17, 2024 at 6:22 AM Michael <confabul...@kintzios.com> wrote: > > On Saturday 16 November 2024 20:13:30 GMT Rich Freeman wrote: > > > > The idea of a host-managed drive is to avoid the random writes in the > > first place, and the need to do the random reads. For this to work > > the host has to know where the boundaries of the various regions are > > and where it is safe to begin writes in each region. > > The random reads do not incur a time penalty, it is the R-M-W ops that cost > time.
We're saying the same thing. If you don't preserve data that you overwrite, then there is no need to read anything. Random reads are the same speed on CMR and SMR, but not doing a read is faster than doing a read on either platform, and any read on an HDD is very slow. > The host don't need to know where bands start and finish, only needs to > submit data in whole sequential streams, so they can be written directly to > the disk as in a CMR. As long as data and metadata are submitted and written > directly, the SMR would be alike a CMR in terms of its performance. Again, we're saying the same thing, but making different assumptions about how HM-SMR is implemented. SMR can be appended to without penalty, just like tape. In order to append and not overwrite, the host needs to know where the boundaries of the SMR domains are. > I assumed, may be wrongly, there is still an STL function performed by the > controller on HM-SMRs, to de-allocate deleted data bands whenever files are > deleted, perform secure data deletions via its firmware, etc. However, I can > see if this is managed at the fs journal layer the drive controller could be > dumb in this respect. Honestly, I don't know exactly what commands an HM-SMR implements, and since I doubt I'll ever use one, I can't really be bothered to look them up. The whole point of a HM-SMR drive is that the drive just does exactly what the host does, and doesn't try to shield the host from the details of how SMR works. That's why they can be used without performance penalties. They're just very destructive to data if they aren't used correctly. > It would be interesting to see how different fs types perform on DM-SMRs. Not that interesting, for me personally. That's like asking how well different filesystems would perform on tape. If I'm storing data on tape, I'll use an algorithm designed to work on tape, and a tape drive that actually has a command set that doesn't try to pretend that it is useful for random writes. SMR is pretty analogous to tape, with the benefit of being as fast as CMR for random reads. If anything I've been trying to migrate away from HDD entirely. NVMe will always be more expensive I'm sure but the density and endurance are continuing to improve, and of course the speed is incomparable. Cost is only a few times more. Biggest challenge is the lanes but used workstations seem to be a way to get around that. -- Rich
