Date: Thu, 15 Nov 2012 08:57:17 +0000 From: Arthur Chance <freebsd@qeng-ho.org> To: Robert Bonomi <bonomi@mail.r-bonomi.com> Cc: freebsd-questions@freebsd.org Subject: Re: 'device' representation in the filesystem questions Message-ID: <50A4AE6D.5050908@qeng-ho.org> In-Reply-To: <201211142338.qAENcEqx002393@mail.r-bonomi.com> References: <201211142338.qAENcEqx002393@mail.r-bonomi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/14/12 23:38, Robert Bonomi wrote: > > it appears that FreeBSD, at least 8.0 and later: > a) no longer uses 'raw' devices for anything > b) no longer uses 'block' devices for anything > c) randomly assigns device 'major' numbers > d) doesn't use device 'minor' numbers for anything. > e) as a result of c) and d), there is no way to > establish 'device' physical characteristics > from the 'node' information. > > Is there a wizzard who can confirm/deny? I'm not a wizard, I don't even count as a sorcerer's apprentice, but I can answer some of these. Firstly block devices were dropped when the unified VM cache came in as the semantics were incompatible. The Architecture Handbook has this rather terse entry about them: http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html As for major device numbers, in the original days of Unix the device table was just that - an array in the kernel indexed by major device number to get the device operation switch. (Actually there were two tables, one for cdevs and one for bdevs, but the principle's the same.) Device nodes in the file system were simple special inodes containing a (major, minor) pair and created statically by mknod. However, as more devices with different drivers came along it made sense to switch to the current model in which devices are discovered dynamically, both at boot and as they're plugged in and out. and /dev is a "magic" file system maintained by the kernel and daemons. It's a long time since I was very familiar with kernel internals, but I presume internally devices are now pointers and the device numbering fields returned by stat are simply for backwards compatibility. As for the rest, you need someone more familiar with current kernel internals than I am - my main kernel hacking days ran from the Sixth Edition to BSD 4.2 and faded out as System V.4 came in. If no one turns up here, maybe try freebsd-hackers@ > Or, if there's a better place to ask, can anyone point me there? > > There are significant performance and 'addressability' issues when doing > i/o directly to 'fixed block' devices, especially 'write-once' media.` > > The classical 'block' device type was a reliable indicator of 'fixed block' > behavior, how does one make that determination today? > > Is there any way to get 'classic' mag-tape behavior -- where, for example > a read(2) returned the lesser of the bytes in the block, and positioned > to the beginning of the next, regardless of whether the etire content of > the current block had been read ?` I haven't seen a real mag tape drive in over a decade, so have no hope of commenting on that.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50A4AE6D.5050908>