On Sat, Nov 16, 2024 at 6:02 AM Michael <confabul...@kintzios.com> wrote: > > I assume (simplistically) with DM-SMRs the > discard-garbage collection is managed wholly by the onboard drive controller, > while with HM-SMRs the OS will signal the drive to start trimming when the > workload is low in order to distribute the timing overheads to the system's > idle time.
I'll admit I haven't looked into the details as I have no need for SMR and there aren't any good FOSS solutions for using it that I'm aware of (just a few that might be slightly less terrible). However, this doesn't seem correct for two reasons: First, I'm not sure why HM-SMR would even need a discard function. The discard command is used to tell a drive that a block is safe to overwrite without preservation. A host-managed SMR drive doesn't need to know what data is disposable and what data is not. It simply needs to write data when the host instructs it to do so, destroying other data in the process, and it is the host's job to not destroy anything it cares about. If a write requires a prior read, then the host needs to first do the read, then adjust the written data appropriately so that nothing is lost. Second, there is no reason that any drive of any kind (SMR or SSD) NEEDS to do discard/trim operations when the drive is idle, because discard/trim is entirely a metadata operation that doesn't require IO with the drive data itself. Now, some drives might CHOOSE to implement it that way, but they don't have to. On an SSD, a discard command does not mean that the drive needs to erase or move any data at all. It just means that if there is a subsequent erase that would impact that block, it isn't necessary to first read the data and re-write it afterwards. A discard could be implemented entirely in non-volatile metadata storage, such as with a bitmap. For a DM-SMR using flash for this purpose would make a lot of sense - you wouldn't need much of it. This is probably why you have endless arguing online about whether discard/trim is helpful for SSDs. It completely depends on how the drive implements the command. The drives I've owned can discard blocks without any impact on IO, but I've heard some have a terrible impact on IO. It is just like how you can complete the same sort operation in seconds or hours depending on how dumb your sorting algorithm is. In any case, to really take advantage of SMR the OS needs to understand exactly how to structure its writes so as to not take a penalty, and that requires information about the implementation of the storage that isn't visible in a DM-SMR. Sure, some designs will do better on SMR even without this information, but I don't think they'll ever be all that efficient. It is no different from putting f2fs on a flash drive with a brain-dead discard implementation - even if the OS does all its discards in nice consolidated contiguous operations it doesn't mean that the drive will handle that in milliseconds instead of just blocking all IO for an hour - sure, the drive COULD do the operation quickly, but that doesn't mean that the firmware designers didn't just ignore the simplest use case in favor of just optimizing around the assumption that NTFS is the only filesystem in the world. -- Rich
