On Sat, Nov 16, 2024 at 2:47 PM Michael <confabul...@kintzios.com> wrote: > > As I understand it from reading various articles, the constraint of having to > write sequentially a whole band when a random block changes within a band > works the same on both HM-SMR and the more common DM-SMR.
Correct. > What differs with > HM-SMR instructions is the host is meant to take over the management of random > writes and submit these as sequential whole band streams to the drive to be > committed without a read-modify-write penalty. I suppose for the host to have > to read the whole band first from the drive, modify it and then submit it to > the drive to write it as a whole band will be faster than letting the drive > manage this operation internally and getting its internal cache full. I doubt this would be any faster with a host-managed drive. The same pattern of writes is going to incur the same penalties. 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. Sure, a host could just use software to make the host-managed drive behave the same as a drive-managed drive, but there isn't much benefit there. You'd want to use a log-based storage system/etc to just avoid the random writes entirely. You might not even want to use a POSIX filesystem on it. > This > will not absolve the drive firmware from having to manage its own trim > operations and the impact metadata changes could have on the drive, but some > timing optimisation is perhaps reasonable. Why would a host-managed SMR drive have ANY trim operations? What does trimming even mean on a host-managed drive? Trimming is the act of telling the drive that it is safe to delete a block without preserving it. A host-managed drive shouldn't need to be concerned with preserving any data during a write operation. If it is told to write something, it will just overwrite the data in the subsequent overlapping cylinders. Trimming is helpful with drive-managed SMR because if the drive isn't told to trim a block that is about to be overwritten due to a write to a different block, then the drive needs to first read, and then rewrite the block. Trimming tells the drive that this step can be skipped, assuming ALL the blocks in that region have been trimmed. > I don't know if SMRs use flash to record their STL status and data allocation > between their persistent cache and shingled storage space. I would think yes, > or at least they ought to. Without metadata written to different media, for > such a small random write to take place atomically a whole SMR band will be > read, modified in memory, written to a new temporary location and finally > overwrite the original SMR band. Well, drive-managed SMR drives typically have CMR regions for data caching, and they could also be used to store the bitmap. Cheap drives might not support trim at all, and would just preserve all data on write. After all, it isn't performance that is driving the decision to sneak SMR into consumer drives. Flash would be the most sensible way to do it though. -- Rich
