Fwd: DELETE support in the VOP_STRATEGY(9)?

[Steven Hartland]

On 08/12/2015 19:06, Konstantin Belousov wrote:
> On Tue, Dec 08, 2015 at 08:58:18PM +0200, Konstantin Belousov wrote:
>> On Tue, Dec 08, 2015 at 07:44:38PM +0100, 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).
>> I again agree.  This is how UFS issues TRIM.  When the data block is freed
>> and there are no dandling pointers in the inode copy on disk pointing to
>> the block, BIO_DELETE is issued if volume reports it.  Everything else
>> is up to the geom stack and driver.
> I am sorry for the followup mail, but I probably have to explain more.
> The freed block, for which BIO_DELETE is issued, is not marked as free
> in the bitmap, until the BIO_DELETE completion is reported. In other
> words, we do not reuse the freed block while TRIM command is possibly
> executed.
This is the same for ZFS.