Understanding the rationale behind dropping of "block devices"

[Julian Elischer]

On 16/01/2017 4:49 PM, Aijaz Baig wrote:
> Oh yes I was actually running an old release inside a VM and yes I had
> changed the device names myself while jotting down notes (to give it a more
> descriptive name like what the OSX does). So now I've checked it on a
> recent release and yes there is indeed no block device.
>
> root at bsd-client:/dev # gpart show
> =>      34  83886013  da0  GPT  (40G)
>          34      1024    1  freebsd-boot  (512K)
>        1058  58719232    2  freebsd-ufs  (28G)
>    58720290   3145728    3  freebsd-swap  (1.5G)
>    61866018  22020029       - free -  (10G)
>
> root at bsd-client:/dev # ls -lrt da*
> crw-r-----  1 root  operator  0x4d Dec 19 17:49 da0p1
> crw-r-----  1 root  operator  0x4b Dec 19 17:49 da0
> crw-r-----  1 root  operator  0x4f Dec 19 23:19 da0p3
> crw-r-----  1 root  operator  0x4e Dec 19 23:19 da0p2
>
> So this shows that I have a single SATA or SAS drive and there are
> apparently 3 partitions ( or is it four?? Why does it show unused space
> when I had used the entire disk?)
>
> Nevertheless my question still holds. What does 'removing support for block
> device' mean in this context? Was what I mentioned earlier with regards to
> my understanding correct? Viz. all disk devices now have a character (or
> raw) interface and are no longer served via the "page cache" but rather the
> "buffer cache". Does that mean all disk accesses are now direct by passing
> the file system??

Basically, FreeBSD never really buffered/cached by device.

Buffering and caching is done by vnode in the filesystem.
We have no device-based block cache.  If you want file X at offset Y, 
then we can satisfy that from cache.
VM objects map closely to vnode objects so the VM system IS the file 
system buffer cache.

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.

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 :-).

>
> On Mon, Jan 16, 2017 at 12:41 PM, Greg 'groggy' Lehey <grog at freebsd.org>
> wrote:
>
>> On Monday, 16 January 2017 at  8:10:16 +0530, Aijaz Baig wrote:
>>> But when I check the disk nodes under /dev I get this
>>> [CODE]ls -l /dev/*disk0
>>> brw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/disk0
>>> crw-r----- 1 root operator 14, 0 Jan 2 09:39 /dev/rdisk0[/CODE]
>> Are you sure that this is FreeBSD?  The naming convention looks more
>> like Mac OS, though the major device number doesn't match.  FreeBSD
>> has been through a number of disk naming conventions, but I'm pretty
>> sure that we never had anything as straightforward as 'disk'.
>>
>>> what was there earlier in FreeBSD before 'block device support' was
>>> dropped?
>> Apart from the name, things used to look similar.  Here a quote from
>> "The Complete FreeBSD", written some time at the end of the last
>> century:
>>
>> crw-r-----  1 root  operator    3, 131072 Oct 31 19:59 /dev/rwd0s1a
>> brw-r-----  1 root  operator    0, 131072 Oct 31 19:59 /dev/wd0s1a
>>
>> The minor number included partition encoding, thus the large number.
>>
>> Greg
>> --
>> Sent from my desktop computer.
>> Finger grog at FreeBSD.org for PGP public key.
>> See complete headers for address and phone numbers.
>> This message is digitally signed.  If your Microsoft mail program
>> reports problems, please read http://lemis.com/broken-MUA
>>
>
>