Date: Mon, 16 Jan 2017 09:31:12 +0000 From: "Poul-Henning Kamp" <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" Message-ID: <29469.1484559072@critter.freebsd.dk> In-Reply-To: <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3@freebsd.org> References: <CAHB2L%2BdRbX=E9NxGLd_eHsEeD0ZVYDYAx2k9h17BR0Lc=xu5HA@mail.gmail.com> <20170116071105.GB4560@eureka.lemis.com> <CAHB2L%2Bd9=rBBo48qR%2BPXgy%2BJDa=VRk5cM%2B9hAKDCPW%2BrqFgZAQ@mail.gmail.com> <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-------- 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= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29469.1484559072>