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>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_76B38211-5D68-4DB3-812A-059CA44B4757 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 7, 2015, at 3:19 AM, Dag-Erling Sm=C3=B8rgrav <des@des.no> = wrote: >=20 > 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. >=20 > 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. >=20 > 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 --Apple-Mail=_76B38211-5D68-4DB3-812A-059CA44B4757 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----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----- --Apple-Mail=_76B38211-5D68-4DB3-812A-059CA44B4757--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F0C4D6E7-63C7-48CC-952E-25B7D6AD5175>