From owner-freebsd-hackers@freebsd.org  Mon Jan 16 09:31:21 2017
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 DBEC4CB2BF2;
 Mon, 16 Jan 2017 09:31:21 +0000 (UTC)
 (envelope-from phk@phk.freebsd.dk)
Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222])
 by mx1.freebsd.org (Postfix) with ESMTP id A4EF8109A;
 Mon, 16 Jan 2017 09:31:21 +0000 (UTC)
 (envelope-from phk@phk.freebsd.dk)
Received: from critter.freebsd.dk (unknown [192.168.55.3])
 by phk.freebsd.dk (Postfix) with ESMTP id 41EA2273AC;
 Mon, 16 Jan 2017 09:31:14 +0000 (UTC)
Received: from critter.freebsd.dk (localhost [127.0.0.1])
 by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id v0G9VC81029470;
 Mon, 16 Jan 2017 09:31:13 GMT (envelope-from phk@phk.freebsd.dk)
To: Julian Elischer <julian@freebsd.org>
cc: Aijaz Baig <aijazbaig1@gmail.com>,
 "Greg 'groggy' Lehey" <grog@freebsd.org>,
 FreeBSD Hackers <freebsd-hackers@freebsd.org>, freebsd-scsi@freebsd.org
Subject: Re: Understanding the rationale behind dropping of "block devices"
In-reply-to: <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3@freebsd.org>
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
References: <CAHB2L+dRbX=E9NxGLd_eHsEeD0ZVYDYAx2k9h17BR0Lc=xu5HA@mail.gmail.com>
 <20170116071105.GB4560@eureka.lemis.com>
 <CAHB2L+d9=rBBo48qR+PXgy+JDa=VRk5cM+9hAKDCPW+rqFgZAQ@mail.gmail.com>
 <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29468.1484559072.1@critter.freebsd.dk>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 16 Jan 2017 09:31:12 +0000
Message-ID: <29469.1484559072@critter.freebsd.dk>
X-Mailman-Approved-At: Mon, 16 Jan 2017 12:08:45 +0000
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.23
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: Mon, 16 Jan 2017 09:31:22 -0000

--------
In message <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3@freebsd.org>, Julian Elis=
cher =

writes:

>Having said that, it would be trivial to add a 'caching' geom layer to =

>the system but that has never been needed.

A tinker-toy-cache like that would be architecturally disgusting.

The right solution would be to enable mmap(2)'ing of disk(-like)
devices, leveraging the VM systems exsting code for caching and
optimistic prefetch/clustering, including the very primitive
cache-control/visibility offered by madvise(2), mincore(2), mprotect(2),
msync(2) etc.

-- =

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    =

Never attribute to malice what can adequately be explained by incompetence=
.