On Friday 15 November 2024 22:13:27 GMT Rich Freeman wrote: > On Fri, Nov 15, 2024 at 10:35 AM Michael <confabul...@kintzios.com> wrote: > > Host managed SMRs (HM-SMR) require the OS and FS to be aware of the need > > for sequential writes and manage submitted data sympathetically to this > > limitation of the SMR drive, by queuing up random writes in batches and > > submitting these as a sequential stream. > > > > I understand the ext4-lazy option and some patches on btrfs have improved > > performance of these filesystems on SMR drivers, but perhaps f2fs will > > perform better? :-/ > > IMO a host-managed solution is likely to be the only thing that will > work reliably.
I think HM-SMRs may be used in commercial applications and DM-SMRs fed to the unaware retail consumer, not that we can tell without the OEMs providing this rather vital piece of information. 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. > If the drive supports discard/trim MAYBE a dumber > drive might be able to be used with the right filesystem. Even if > you're doing "write-once" workloads any kind of metadata change is > going to cause random writes unless the filesystem was designed for > SMR. Ideally you'd store metadata on a non-SMR device, though it > isn't strictly necessary with a log-based approach. I've considered the flash storage trim operation to be loosely like the SMR behaviour of read-modify-write and similarly susceptible to write- amplification, but with SSD the write speed is so much faster it doesn't cause the same noticeable slowdown as with SMR. > If the SMR drive tries really hard to not look like an SMR drive and > doesn't support discard/trim then even an SMR-aware solution probably > won't be able to use it effectively. The drive is going to keep doing > read-before-write cycles to preserve data even if there is nothing > useful to preserve. > > -- > Rich Sure, trimming nudges by the OS won't have an effect on the DM-SMR drive since small changes to shingled bands are managed internally by the onboard STL controller and the persistent SMR cache. However, there are some things a filesystem driver can still provide to improve performance. For example, compression, caching-batching to facilitate sequential writing directly in whole bands rather than random small regions within a band, etc. In the case of ext4 'lazy writeback journaling' the allocated journaling space is increased upfront and the metadata are written once only with a mapping inserted in memory to join the location of the metadata in the journal itself instead of writing it twice. The two links at the bottom of this page explain it better: https://www.usenix.org/conference/fast17/technical-sessions/presentation/ aghayev I'm not sure if this happens automatically, or if some mkfs and mount option(s) need to be called upon. With up to 30x faster write speed, perhaps this is something Dale may want to investigate and experiment with.
signature.asc
Description: This is a digitally signed message part.
