Date: Mon, 07 Dec 2015 11:19:59 +0100 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Maxim Sobolev <sobomax@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, Eitan Adler <lists@eitanadler.com> Subject: Re: DELETE support in the VOP_STRATEGY(9)? Message-ID: <86twnur25s.fsf@desk.des.no> In-Reply-To: <CAF6rxg=H-r=B=YHxOf_gb5KgUas1k30G4pzKzWsvygpTrJNmeA@mail.gmail.com> (Eitan Adler's message of "Sat, 5 Dec 2015 19:16:51 -0800") References: <CAH7qZftiiqM5WpT%2BDvRpjyduw2OrPseCUQpt4uCbAWfRNfDUbA@mail.gmail.com> <CAF6rxg=H-r=B=YHxOf_gb5KgUas1k30G4pzKzWsvygpTrJNmeA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Maxim Sobolev <sobomax@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. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86twnur25s.fsf>