newfs_msdos and dvd-ram (fwsectors, fwheads)

Andriy Gapon avg at icyb.net.ua
Thu Feb 21 12:32:08 UTC 2008


on 17/02/2008 13:39 Andriy Gapon said the following:
> Should newfs_msdos be able to work on "whole" cdX/acdX device ?
> [ufs/ffs] newfs can do it.
> But with newfs_msdos I had to run disklabel first and then I could
> create a filesystem on cdXa, but I couldn't do it on the whole disk.

It seems that the reason for this newfs_msdos behavior is in the
following lines:
if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1)
    errx(1, "Cannot get sector size, %s", strerror(errno));
if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1)
    errx(1, "Cannot get number of sectors, %s", strerror(errno));
if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1)
    errx(1, "Cannot get number of heads, %s", strerror(errno));

While a failure to get sector size is a serious situation indeed, number
of sectors per track and number of heads are just relics of the past and
are not applicable to all types of should-be-supported media.
What's even more funny is that those values can be set via command line
options and in that case values from ioctl are not used at all.

Because those numbers are used by msdosfs on-disk structures we have to
provide some reasonable values for them even if they are meaningless
with respect to physical media organization.
An example of simple calculations can be found in bsdlabel.c.
I see two approaches:
1) fake those properties in device drivers, primarily cd(4) and acd(4);
   benefit: this can help other utilities besides newfs_msdos
2) fake those properties in newfs_msdof;
   benefit: this would help with other physical devices that can host
   FAT;

Or maybe do both.

-- 
Andriy Gapon


More information about the freebsd-current mailing list