From owner-freebsd-hackers@freebsd.org Mon Dec 7 10:20:14 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 712C19B95E8 for ; Mon, 7 Dec 2015 10:20:14 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 3AA6F13D5; Mon, 7 Dec 2015 10:20:13 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 48F6DDA73; Mon, 7 Dec 2015 10:20:07 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 5EDDF48179; Mon, 7 Dec 2015 11:19:59 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Maxim Sobolev , FreeBSD Hackers , Pawel Jakub Dawidek , Eitan Adler Subject: Re: DELETE support in the VOP_STRATEGY(9)? References: Date: Mon, 07 Dec 2015 11:19:59 +0100 In-Reply-To: (Eitan Adler's message of "Sat, 5 Dec 2015 19:16:51 -0800") Message-ID: <86twnur25s.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 10:20:14 -0000 Maxim Sobolev 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