From owner-freebsd-hackers Wed Jan 27 20:57:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA10914 for freebsd-hackers-outgoing; Wed, 27 Jan 1999 20:57:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ceia.nordier.com (m1-40-dbn.dial-up.net [196.34.155.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA10902 for ; Wed, 27 Jan 1999 20:57:10 -0800 (PST) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.7/8.6.12) id GAA01103; Thu, 28 Jan 1999 06:56:31 +0200 (SAT) From: Robert Nordier Message-Id: <199901280456.GAA01103@ceia.nordier.com> Subject: Re: raw devices and disk geometry In-Reply-To: <19990127112021.A13567@proxydev.inktomi.com> from John Plevyak at "Jan 27, 99 11:20:21 am" To: jplevyak@inktomi.com (John Plevyak) Date: Thu, 28 Jan 1999 06:56:29 +0200 (SAT) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I think you need to look at the code of an actual utility that does > > this stuff, and that you can also try out. I'd suggest newfs_msdos(8), > > which will allow you to specify any of > > > > o the whole physical disk > > o a slice (what DOS calls a partition) > > o a partition (what BSD calls a partition) > > Thanx. That code parses the device file name and pulls the > slice and partition from the filename: > > /dev/rwd2cs4 > ^ slice > ^ partition It's /dev/rwd2s4c (unit, slice, partition), but the principle's the same. > > Not pretty, but it works so long as nobody changes the format of > device names. It's the standard BSD way (in userland). Device naming is not arbitrary but has a rigid format in order to make the internal information accessible to utilities precisely to support this approach. > > > > Also, why shouldn't lseek work on a device? Is this something > > > we would like FreeBSD to do, or is the current undefined behavior > > > what we want? Given that this would solve my problem I would consider > > > making a patch if there was some expectation that it would be accepted. > > > > You can't expect lseek(fd, 0, SEEK_END) to work as you expect unless > > the file descriptor is associated with a regular file. For other file > > types, file size information is not available at that level. "It's > > a UNIX thing," and there's no patching it now. Size information > > usually is available -- in the FreeBSD case, via ioctl -- but not very > > portably across UNIX-like systems. > > I see that lseek is using vop_getattr to determine the size of the file > via the 'va_size' field which is 0 for devices. > > The structure vattr contains: > > u_quad_t va_size; /* file size in bytes */ > and > u_quad_t va_bytes; /* bytes of disk space held by file */ > > In the function devfs_getattr in sys/miscfs/devfs_vnops.c > these are both set to file_node->len (0). While it is clear > that va_bytes should be 0, but there seems to be > no reason for va_size to not be the size of data on the disk > (modula other code which depends on it being 0). > > The code would be something like: > > switch (file_node->type) { > case DEV_CDEV: > vap->va_rdev = file_node->by.Cdev.dev; > vap->va_size = (u_quad_t)(*file_node->by.Cdev.cdevsw.d_size)(vap->va_rdev) << DEV_BSHIFT; > break; > case DEV_BDEV: > vap->va_rdev = file_node->by.Bdev.dev; > vap->va_size = (u_quad_t)(*file_node->by.Bdev.cdevsw.d_size)(vap->va_rdev) << DEV_BSHIFT; > break; > default: > vap->va_size = file_node->len; > break; > } > > Of course someone might be counting on va_size being 0 for devices. > > Comments? Without going into design decisions, va_size (or, rather, st_size in the external sys/stat.h interface) is explicitly described in standards as defined only for regular files. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message