From owner-freebsd-hackers@freebsd.org  Tue Dec  8 19:02:40 2015
Return-Path: <owner-freebsd-hackers@freebsd.org>
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 CDECC9D3C99
 for <freebsd-hackers@mailman.ysv.freebsd.org>;
 Tue,  8 Dec 2015 19:02:40 +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 9528C132E
 for <freebsd-hackers@freebsd.org>; Tue,  8 Dec 2015 19:02:40 +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 BB59DD725;
 Tue,  8 Dec 2015 19:02:39 +0000 (UTC)
Received: by desk.des.no (Postfix, from userid 1001)
 id 7ACC4482EC; Tue,  8 Dec 2015 20:02:30 +0100 (CET)
From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To: Konstantin Belousov <kostikbel@gmail.com>
Cc: Warner Losh <imp@bsdimp.com>,
 "freebsd-hackers\@freebsd.org" <freebsd-hackers@freebsd.org>
Subject: Re: Fwd: DELETE support in the VOP_STRATEGY(9)?
References: <CAH7qZftSVAYPmxNCQy=VVRj79AW7z9ade-0iogv2COfo2x+a2Q@mail.gmail.com>
 <201512052002.tB5K2ZEA026540@chez.mckusick.com>
 <CAH7qZfs6ksE+QTMFFLYxY0PNE4hzn=D5skzQ91=gGK2xvndkfw@mail.gmail.com>
 <86poyhqsdh.fsf@desk.des.no>
 <CAH7qZftVj9m_yob=AbAQA7fh8yG-VLgM7H0skW3eX_S+v75E-g@mail.gmail.com>
 <86fuzdqjwn.fsf@desk.des.no>
 <CANCZdfo=NfKy51+64-F_v+Dh2wkrFYP4gXe=X9RWSSao49gO9g@mail.gmail.com>
 <CANCZdfqHoduhdCss0b6=UsBPAxfRZv4hF8vyuUVLBdP5gYUduQ@mail.gmail.com>
 <20151208175414.GB82577@kib.kiev.ua>
Date: Tue, 08 Dec 2015 20:02:30 +0100
In-Reply-To: <20151208175414.GB82577@kib.kiev.ua> (Konstantin Belousov's
 message of "Tue, 8 Dec 2015 19:54:14 +0200")
Message-ID: <86lh94rcft.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
 <freebsd-hackers.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
 <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 19:02:40 -0000

Konstantin Belousov <kostikbel@gmail.com> writes:
> Exactly. I completely agree with the statement above, and think that
> this is the only thing that should be implemented. There could be a
> request, most likely an filesystem-level ioctl, which punches holes in
> the file. Its effect on the file state should be the same as if the
> seek was done between writes, if the filesystem supports the ioctl.
> More, if supported, the lseek(SEEK_HOLE/SEEK_DATA) behaviour should
> be consistent with the request. The later might mean that we should
> restrict the interface to only accept ranges at block boundaries.

Having spent a couple of weeks recently trying to get code that uses
SEEK_HOLE to work reliably, my advice is to burn it down and salt the
earth.  Wait, am I thinking out loud again?  What I meant to say is that
there is no such thing as consistency where SEEK_HOLE is concerned, and
it might as well just be an alias for (SEEK_END, 0).

DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no