Date: Thu, 28 Jan 1999 06:56:29 +0200 (SAT) From: Robert Nordier <rnordier@nordier.com> To: jplevyak@inktomi.com (John Plevyak) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: raw devices and disk geometry Message-ID: <199901280456.GAA01103@ceia.nordier.com> In-Reply-To: <19990127112021.A13567@proxydev.inktomi.com> from John Plevyak at "Jan 27, 99 11:20:21 am"
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
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901280456.GAA01103>