Understanding the rationale behind dropping of "block devices"

[Aijaz Baig]

Oh thank you everyone for clearing the air a bit. Although for a noob like
myself, that was mighty concise!

Nevertheless, let me re-iterate what has been summarized in the last two
mails so I know I got exactly what was being said.

Let me begin that I come from the Linux world where there has traditionally
been two separate caches, the "buffer cache" and the "page cache" although
almost all IO is now driven through the "page cache". The buffer cache
still remains however it now only caches disk blocks (
https://www.quora.com/What-is-the-difference-between-Buffers-and-Cached-columns-in-proc-meminfo-output).
So 'read' and 'write' were satisfied through the buffer cache whereas
'fwrite/read', 'mmap' went through the page cache (which was actually
populated by reading the buffer cache thereby wasting almost twice the
memory and compute cycles). Hence the merging.

Nevertheless, as had been mentioned by Julian, it appears that there is no
"buffer cache" so to speak (is that correct Julian??)
> 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.

Instead it appears FreeBSD has a generic 'VM object' that is used to
address myriad entities including disks and as such all operations have to
go through the VM subsystem now. Does that also mean that there is no way
an application can directly use raw disks? At least it appears so
> 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

Thank you for all your inputs and waiting to hear more! Al though a bit
more context would really help noobs (both to enterprise storage and
FreeBSD) like me!

On Mon, Jan 16, 2017 at 3:56 PM, Jan Bramkamp <crest at rlwinm.de> wrote:

> On 16/01/2017 10:31, Poul-Henning Kamp wrote:
>
>> --------
>> In message <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3 at freebsd.org>, Julian
>> Elischer
>> 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.
>>
>> Enabling mmap(2) on devices would be nice, but it would also create
> problems with revoke(2). The revoke(2) syscall allows revoking access to
> open devices (e.g. a serial console). This is required to securely logout
> users. The existing file descriptors are marked as revoked an will return
> EIO on every access. How would you implement gracefully revoking mapped
> device memory? Killing all those processes with SIGBUS/SIGSEGV would keep
> the system secure, but it would be far from elegant.
> _______________________________________________
> freebsd-scsi at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"
>



-- 

Best Regards,
Aijaz Baig