Date: Wed, 27 Jan 1999 11:20:21 -0800 From: John Plevyak <jplevyak@inktomi.com> To: Robert Nordier <rnordier@nordier.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: raw devices and disk geometry Message-ID: <19990127112021.A13567@proxydev.inktomi.com> In-Reply-To: <199901271220.OAA22838@ceia.nordier.com>; from Robert Nordier on Wed, Jan 27, 1999 at 02:19:59PM %2B0200 References: <19990126140251.G19158@proxydev.inktomi.com> <199901271220.OAA22838@ceia.nordier.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Not pretty, but it works so long as nobody changes the format of
device names.
> > 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?
john
--
John Bradley Plevyak, PhD, jplevyak@inktomi.com, PGP KeyID: 051130BD
Inktomi Corporation, 1900 S. Norfolk Street, Suite 110, San Mateo, CA 94403
W:(415)653-2830 F:(415)653-2801 P:(888)491-1332/5103192436.4911332@pagenet.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990127112021.A13567>