Date: Tue, 8 Dec 2015 12:05:51 -0700 From: Warner Losh <imp@bsdimp.com> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: 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: <F0C4D6E7-63C7-48CC-952E-25B7D6AD5175@bsdimp.com> In-Reply-To: <86twnur25s.fsf@desk.des.no> References: <CAH7qZftiiqM5WpT%2BDvRpjyduw2OrPseCUQpt4uCbAWfRNfDUbA@mail.gmail.com> <CAF6rxg=H-r=B=YHxOf_gb5KgUas1k30G4pzKzWsvygpTrJNmeA@mail.gmail.com> <86twnur25s.fsf@desk.des.no>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] > On Dec 7, 2015, at 3:19 AM, Dag-Erling Smørgrav <des@des.no> wrote: > > 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. http://man7.org/linux/man-pages/man2/fallocate.2.html would answer those questions. Warner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWZyoPAAoJEGwc0Sh9sBEAxUUQANrYKp/07D1peZqYseAGqdhj AhwT+5V0vaNyWiwH6CUVrlrqXfp5kM2Uu8AqiEW42zuUhdhl7nQDfAP1j4ipr9lA nOo+Oln4h8kChXyoz73o02te8FlWmnwPn2bt9k7U6cE1H0oMra+PDBsL5taOQmJO obj77YtjlNZ+Y7Z/kHFjePx58aathLms+E2AuvL4HKJUjLZNFhly7lK85HYEQQyL 0aUQ+ZtYKdCfGtH05BkDtvDRqM6Pklic9qp34e2hqCNZRAov5u40YUzOAFdeaRLz pUta/weAl1FvmuXxTEbGZdguBBYtYsCv5vCM5out6w8TmcyMkPGJMgHqrdQBNeDk 6kL+8iJZPVkD5itvMdb2rxJdl+TZRr+XBAd16LT83j7ZyPMzikFbUNMvPV/rTL6s ViZSzkbVmRbqmH4xRa5qIgcPx+ek1L0ZSnlA5PZAn74JTduR3KZQ+WbALYOW4Fre Aa1LGiD0A9sDDOoBzIe68vV0B1y120yxP3iWoNpo/pgsq/c0Jttl3laimb69FtP6 bWJ9tr9f7Y1CZlxYocgE5rE7DhzEje/KfhRJa49njPeeskvFnHlMo/Evlmlziihf 38eXw7NSmgQHCBPvxxTlx0Da4EQpyIg12Qylx9RCVTdsIQJ1V2eTQ0RCmxXEZToW mO7TMPAfcrSG6WZFfpB4 =h127 -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F0C4D6E7-63C7-48CC-952E-25B7D6AD5175>