Date: Wed, 28 Aug 1996 14:33:39 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rnordier@iafrica.com (Robert Nordier) Cc: hackers@FreeBSD.org Subject: Re: Determining disk type & size Message-ID: <199608282133.OAA27517@phaeton.artisoft.com> In-Reply-To: <199608282008.WAA00279@eac.iafrica.com> from "Robert Nordier" at Aug 28, 96 10:08:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Could anyone tell me if there is a quick and easy way to do the > following: > > For a given (block special) device, determine whether it represents > > (1) a floppy disk > (2) a hard disk slice that contains a filesystem (probably not ufs) > (3) anything else (not interested, but could be cdrom, tape, etc) > > and, given this info, the size (in bytes or 512-byte sectors) of the > disk or slice itself. For example: > > device blocks > ---------- ------ > /dev/fd1 2400 > /dev/wd0s1 65457 > /dev/wd0 (error) > > Most of the userland code I've looked at doesn't seem to handle this > very elegantly, where it checks. And some of my attempts to do the > obvious seem to produce inconsistent results (below). Do you really care about the type, or just about the size? I hate to sound like a broken record, but devfs... 8-). There are really three classes of device: 1) Raw physical device 2) Logical-to-physical mapping device 3) Logical device I think that most FS work should not care about types 1 and 2 specifically. Each device, no matter what type, should have an ioctl() which returns: o Number of blocks on device o Geometry hints for use in laying out the logical device I'm sure there are other things which it would be nice to know about, but I can't think of any off hand. 8-). The logical-to-physical mapping devices create the logical device instances by mapping a partition scheme onto another logical-to-physical device, or on a physical device. The logical-to-physical device should have an ioctl() which returns: o Number of blocks in domain managed by logical-to-physical device o Max number of domains the device can be divided into o Current number of domains o Activity level (active/inactive) for a given domain o A mechanism for iterating the current domains using a context cookie (simple "long" value) starting at 0 and monotonically increasing (not necessarily in integer 1 increments) o A mechanism for removing the domain, if it is not locked by mount or other reference to the logical device for the domain o A mechanism for exporting the domains as logical devices o Geometry hints, per domain, for use in laying out the logical device The raw physical device should have an ioctl which returns o Number of blocks on physical device Examples of logical-to-physical device drivers which can be stacked on a physical device or a logical device: o Media perfection o BAD144 o Other o Partitioning o DOS partition table o DOS extended partition table o VFAT32/LBA partition table o PReP/CHRP partition table o BSD disklabel o Solaris Disklabel o SVR3 VTOC o SVR4 VTOC o AIX VTOC o Volume spanning o Simple spanning o Striping o Mirroring o Raid Stacking is implemented through 1:N fan out using directory hierarchy; a directory can be used as a device by divorcing VOP_READDIR/VOP_READ in the devfs FS implementation. So as an FS author, you should worry about o The logical device And not worry about o The raw device with DOS partitioning o The DOS extended partition in one of the DOS partitions o The BSD disklabel in an extended partition o The 'a' "slice" in the BSD disklabel Assume the device management will catch up, independently. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608282133.OAA27517>