Date: Mon, 16 Jan 2017 17:20:25 +0800 From: Julian Elischer <julian@freebsd.org> To: Aijaz Baig <aijazbaig1@gmail.com>, "Greg 'groggy' Lehey" <grog@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, freebsd-scsi@freebsd.org Subject: Re: Understanding the rationale behind dropping of "block devices" Message-ID: <a86ad6f5-954d-62f0-fdb3-9480a13dc1c3@freebsd.org> In-Reply-To: <CAHB2L%2Bd9=rBBo48qR%2BPXgy%2BJDa=VRk5cM%2B9hAKDCPW%2BrqFgZAQ@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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@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 >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a86ad6f5-954d-62f0-fdb3-9480a13dc1c3>