newfs_msdos and dvd-ram (fwsectors, fwheads)

Bruce Evans brde at
Thu Feb 21 14:56:19 UTC 2008

On Thu, 21 Feb 2008, Andriy Gapon wrote:

> on 21/02/2008 16:27 Bruce Evans said the following:
>> On Thu, 21 Feb 2008, Andriy Gapon wrote:
>>> 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.
>> Also, it needs the BIOS geometry, but has been broken to ask for, and

> you lost me after this. I understand that you speak about a general
> case, but is there a "BIOS geometry" for DVD-RAM disk ?

Probably not.   Docs say "for interrupt 0x13... only relevant for media
that have a geometry".

> Would any information about physical structure of DVD-RAM disk prove
> useful for FAT on it ?

The geometry fields might only be used by the bootstrap even on media
that has a geometry.  Since newfs_msdos writes a dummy bootstrap that
doesn't support media accesses, we don't have to initialize them for

> I thought that all those CHS parameters were useful only in times when
> CHS was the disk access mode (and maybe for performance optimizations).
> I don't see how those parameters can be of any real use now.

That is probably correct, but since we don't control all uses of these
fields, we should try to initialize them correctly.


More information about the freebsd-current mailing list