From owner-freebsd-hackers@freebsd.org  Mon Jan 16 11:04:48 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 4446FCB0A8F;
 Mon, 16 Jan 2017 11:04:48 +0000 (UTC)
 (envelope-from eugen@grosbein.net)
Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified))
 by mx1.freebsd.org (Postfix) with ESMTPS id D1E1E1111;
 Mon, 16 Jan 2017 11:04:47 +0000 (UTC)
 (envelope-from eugen@grosbein.net)
Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221])
 by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id v0GB4Zgl050449
 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
 Mon, 16 Jan 2017 12:04:36 +0100 (CET)
 (envelope-from eugen@grosbein.net)
X-Envelope-From: eugen@grosbein.net
X-Envelope-To: julian@freebsd.org
Received: from [10.58.0.10] (dadvw [10.58.0.10])
 by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id v0GB4WYA046170
 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
 Mon, 16 Jan 2017 18:04:32 +0700 (KRAT)
 (envelope-from eugen@grosbein.net)
Subject: Re: Understanding the rationale behind dropping of "block devices"
To: Julian Elischer <julian@freebsd.org>, Aijaz Baig <aijazbaig1@gmail.com>,
 "Greg 'groggy' Lehey" <grog@freebsd.org>
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>
Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, freebsd-scsi@freebsd.org
From: Eugene Grosbein <eugen@grosbein.net>
Message-ID: <587CA8BC.1070609@grosbein.net>
Date: Mon, 16 Jan 2017 18:04:28 +0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3@freebsd.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM
 autolearn=no autolearn_force=no version=3.4.1
X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1%
 *      [score: 0.0000] *  2.6 LOCAL_FROM From my domains
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net
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 11:04:48 -0000

16.01.2017 16:20, Julian Elischer wrote:

> If you want  device M, at offset N we will fetch it for you from the device, DMA'd directly into your address space,
> but there is no cached copy.
> Having said that, it would be trivial to add a 'caching' geom layer to the system but that has never been needed.

In fact, FreeBSD does have geom_cache/gcache(8) for long time. It is block-level read cache
passing write requests through transparently.

It is unmaintained, though and there were some reports that it is suspected to cause kernel panics
if there are more than one active GEOM_CACHE instances in a system.

> The added complexity of carrying around two alternate interfaces to the same devices was judged by those who did the work to be not worth the small gain available to the very few people who used raw devices.
> Interestingly, since that time ZFS has implemented a block-layer cache for itself which is of course not integrated with the non-existing block level cache in the system :-).