DELETE support in the VOP_STRATEGY(9)?

[Warner Losh]

> On Dec 7, 2015, at 3:19 AM, Dag-Erling Smørgrav <des at des.no> wrote:
> 
> Maxim Sobolev <sobomax at freebsd.org> writes:
>> Hi folks, do we support delete operation in the vnode layer? This
>> comes from observation that md(4) converts from DELETE into
>> sector-size zero buffer write before it feeds it to the vnode.
> 
> As the person who implemented this (because I needed a reliable way to
> test fsck_ffs -E): it is currently the only possible action, other than
> to ignore the request - which is actually fine since BIO_DELETE is not
> guaranteed to do anything whatsoever, except not corrupt data you didn't
> want deleted.
> 
> I'm not opposed to the idea of VOP_DELETE or similar, but don't assume
> that "punching through" is always the correct semantic, and don't assume
> that it will be easy to implement - and it will have to be implemented
> correctly at every layer, in every geom, in every storage driver etc.
> There are many details to work out and many opportunities for mistakes.
> Remember that BIO_DELETE is strictly advisory.  Should VOP_DELETE also
> be advisory, or do we want to guarantee that a VOP_DELETEd region reads
> back as all zeroes?  Remember that we can't guarantee that the data will
> be removed from the underlying medium, or verify that it was.  How do we
> handle an unaligned VOP_DELETE?  Should a VOP_DELETE create a hole if
> the filesystem support holes?  Since you mentioned VMs, this could
> result in fragmentation of initially unfragmented (preallocated) disk
> images.

http://man7.org/linux/man-pages/man2/fallocate.2.html

would answer those questions.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20151208/a51fe124/attachment.sig>