Re: newfs_msdos and dvd-ram (fwsectors, fwheads)

Please found attached a patch to newfs_msdos that allows it to work on
media for which CHS parameters do not make sense (e.g. DVD-RAM disks).
First, newfs_msdos would not try to query parameters for which a user
has provided override values via command line options.
Second, newfs_msdos would fake values for CHS parameters like "sectors
per track", "number of heads" which are not supported by the media and
for which the user has not provided any values. These numbers/logic are
borrowed from bsdlabel.c

P.S. a line in the patch marked with XXX is a legacy of current code,
not a new addition.

P.S. this is not as extensive patch as that by Bruce Evans; its only
merit is much smaller changeset versus current code/behavior.

on 21/02/2008 14:31 Andriy Gapon said the following:
> 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