Lukas, > My understanding always was that the request needs to be both properly > aligned and of a certain minimum size (discard_granularity) to take > effect. > > If what you're saying is true then I feel like the documentation of > discard_granularity > > Documentation/ABI/testing/sysfs-block > Documentation/block/queue-sysfs.rst > > should change because that's not how I understand the notion of > internal allocation unit. However the sentence you quoted is not > entirely clear to me either so I'll leave that decision to someone who > understands it better than me. > > Martin could you please clarify it for us ? The rationale behind exposing the discard granularity to userland was to facilitate mkfs.* picking allocation units that were friendly wrt. the device's internal granularity. The nature of that granularity depends on the type of device (thin provisioned, resource provisioned, SSD, etc.). Just like the other queue limits the discard granularity was meant as a hint (some of that hintiness got lost as a result of conflating zeroing and deallocating but that has since been resolved). It is true that some devices get confused if you submit discards that are smaller than their internal granularity. However, those devices are typically the ones that don't actually support reporting that granularity in the first place! Whereas SCSI devices generally don't care. They'll happily ignore any parts of the request that are smaller than whatever size they use internally. One of the problems with "optimizing" away pieces that are smaller than the reported granularity is when you combine devices. Say you have a RAID1 of an SSD that reports 4096 bytes and one that reports 256MB. The stacked device will then have a discard granularity of 256MB and thus the SSD with the smaller granularity won't receive any of the discards that might otherwise help it manage its media. -- Martin K. Petersen Oracle Linux Engineering
