Fwd: DELETE support in the VOP_STRATEGY(9)?

[Steven Hartland]

On 08/12/2015 18:44, Dag-Erling Smørgrav wrote:
> Warner Losh <imp at bsdimp.com> writes:
>> Dag-Erling Smørgrav <des at des.no> writes:
>>> But the filesystem does not know whether the underlying storage is
>>> electromechanical or solid-state, nor does it know whether the user
>>> cares much about seek times (unless we introduce the heuristic
>>> "avoid creating holes unless the file already has them, in which
>>> case the userland probably does not care").
>> Actually, the filesystem does know. Or has some knowledge of what
>> is supported and what isn't. BIO_DELETE support is a strong indicator
>> of a flash or other log-type system.
> The filesystem can ask the layer below if BIO_DELETE is supported, but
> should not assume anything about what it means.  For instance, I could
> write a gnop-like module that translates BIO_DELETE into an all-zeroes
> BIO_WRITE and passes everything else unmodified.  It would provide a
> stronger guarantee than, say, SATA TRIM but would also have a completely
> different performance profile (even on SSDs, since it would do its work
> synchronously whereas TRIM works asynchronously).
>
> Anyway, my point is that Maxim needs to revise his assumptions.
Just to clarify most consumer devices process TRIM synchronously, not 
asynchronously.

Your example isn't actually just an example CAM scsi_da has a number of 
different ways it can process BIO_DELETE:
* ATA TRIM
* SCSI UMAP
* Write Same 16
* Write Same 10
* Zero

So you example is actually exists in practice in the FreeBSD code base ;-)

     Regards
     Steve