From owner-freebsd-hackers@freebsd.org  Tue Dec  8 18:44:44 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 8C2D69D42D6
 for <freebsd-hackers@mailman.ysv.freebsd.org>;
 Tue,  8 Dec 2015 18:44:44 +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 5184F1639
 for <freebsd-hackers@freebsd.org>; Tue,  8 Dec 2015 18:44:44 +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 50279D6C3;
 Tue,  8 Dec 2015 18:44:42 +0000 (UTC)
Received: by desk.des.no (Postfix, from userid 1001)
 id E29D7482E3; Tue,  8 Dec 2015 19:44:38 +0100 (CET)
From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To: Warner Losh <imp@bsdimp.com>
Cc: "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>
 <864mfssxgt.fsf@desk.des.no>
 <CANCZdfoXdcD+9jeVR1Np16gafBf0_4B2wombwxze8DvJwf7cMg@mail.gmail.com>
Date: Tue, 08 Dec 2015 19:44:38 +0100
In-Reply-To: <CANCZdfoXdcD+9jeVR1Np16gafBf0_4B2wombwxze8DvJwf7cMg@mail.gmail.com>
 (Warner Losh's message of "Tue, 8 Dec 2015 10:07:42 -0700")
Message-ID: <86wpsord9l.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 18:44:44 -0000

Warner Losh <imp@bsdimp.com> writes:
> Dag-Erling Sm=C3=B8rgrav <des@des.no> writes:
> > But the filesystem does not know whether the underlying storage is
> > electromechanical or solid-state, nor does it know whether the user
> > cares much about seek times (unless we introduce the heuristic
> > "avoid creating holes unless the file already has them, in which
> > case the userland probably does not care").
> Actually, the filesystem does know. Or has some knowledge of what
> is supported and what isn't. BIO_DELETE support is a strong indicator
> of a flash or other log-type system.

The filesystem can ask the layer below if BIO_DELETE is supported, but
should not assume anything about what it means.  For instance, I could
write a gnop-like module that translates BIO_DELETE into an all-zeroes
BIO_WRITE and passes everything else unmodified.  It would provide a
stronger guarantee than, say, SATA TRIM but would also have a completely
different performance profile (even on SSDs, since it would do its work
synchronously whereas TRIM works asynchronously).

Anyway, my point is that Maxim needs to revise his assumptions.

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