[mtools] 'mformat' .vs. 'mkfs.vfat' on 230Mb MO

Discussion:

Alec Voropay

22 years ago

Hi!

I'm trying to use SCSI 230Mb MO on Linux.

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
<Adaptec 2902/04/10/15/20/30C SCSI adapter>
aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs

Vendor: FUJITSU Model: MCF3064SS Rev: 0030
Type: Optical Device ANSI SCSI revision: 02
(scsi1:A:0): 10.000MB/s transfers (10.000MHz, offset 15)

It works. Unfortunately, I have some troubles while formatting
MO. The 'mformat' utility and 'mkfs.vfat' utility produses
different format of VFAT on MO.

The 'mkfs.vfat' creates 512 root directore slots
by default, while 'mformat' 176 only.

OK, 'mkfs.vfat' has '-r 176' option. However,
these two utilities produces different format of MO :
-media descriptor byte
-sectors per fat

It seems, 'mtools' can't determine correct number of
tracks (=218)

Versions:
dosfstools-2.8
mtools-3.9.8

/etc/mtools.conf
=======================================
drive m: file="/dev/sdc"
=======================================

See logfile for more details :
=======================================
***@ns2:~# mkfs.vfat -I -r 176 -v /dev/sdc
mkfs.vfat 2.8 (28 Feb 2001)
/dev/sdc has 64 heads and 32 sectors per track,
logical sector size is 512,
using 0xf8 media descriptor, with 446324 sectors;
file system has 2 16-bit FATs and 8 sectors per cluster.
FAT size is 218 sectors, and provides 55734 clusters.
Root directory contains 176 slots.
Volume ID is 3e37d755, no volume label.
***@ns2:~# minfo m:
device information:
===================
filename="/dev/sdc"
sectors per track: 32
heads: 64
cylinders: 218

mformat command line: mformat -t 218 -h 64 -s 32 m:

bootsector information
======================
banner:" mkdosfs"
sector size: 512 bytes
cluster size: 8 sectors
reserved (boot) sectors: 1
fats: 2
max available root directory slots: 176
small size: 0 sectors
media descriptor byte: 0xf8
sectors per fat: 218
sectors per track: 32
heads: 64
hidden sectors: 0
big size: 446324 sectors
physical drive id: 0x0
reserved=0x0
dos4=0x29
serial number: 3E37D3C6
disk label=" "
disk type="FAT16 "
========================================

========================================
***@ns2:~# mformat m:
***@ns2:~# minfo m:
device information:
===================
filename="/dev/sdc"
sectors per track: 32
heads: 64
cylinders: 217

mformat command line: mformat -t 217 -h 64 -s 32 m:

bootsector information
======================
banner:"MTOOL398"
sector size: 512 bytes
cluster size: 8 sectors
reserved (boot) sectors: 1
fats: 2
max available root directory slots: 176
small size: 0 sectors
media descriptor byte: 0xf0
sectors per fat: 217
sectors per track: 32
heads: 64
hidden sectors: 0
big size: 444416 sectors
physical drive id: 0x0
reserved=0x0
dos4=0x29
serial number: 48F174F7
disk label="NO NAME "
disk type="FAT16 "
========================================

P.S. To mtools authors: change the URL for mailing list
for bugreports in ~/README file. It's hard to find
this.

--
-=AV=-

Alec Voropay

22 years ago

Permalink

-----Original Message-----
From: Hodek Roman [mailto:***@erlf.siemens.de]
Sent: Wednesday, January 29, 2003 6:50 PM
To: ***@vmb-service.ru
Subject: Re: 'mformat' .vs. 'mkfs.vfat' on 230Mb MO

The 'mkfs.vfat' creates 512 root directore slots by default, while
'mformat' 176 only.

...then they use a different algorithm how to determine the size of
the root dir :) No big trouble, though. BTW, mkdosfs always makes 512
entries for harddisk (i.e., non-floppy) filesystems.

-media descriptor byte
-sectors per fat

mkdosfs uses 0xf8 (== harddisk) for everything that isn't a floppy
device or doesn't look like a floppy-sized image. I'd say 0xf0 (==
3.5'' floppy, 1.44M or 2.88M) by mformat is somewhat incorrect, but
nobody looks at that media byte anyway :)

The different sectors per FAT (218 vs. 217) seems to come from a
different view on the device size. mkdosfs detects it to have 446324
sectors, whereas mformat assumes 444416 (== 217*32*64). It it looks to
me as mformat simply multiplies tracks*heads*sectors. mkdosfs instead
makes a real seek test how far it can go and thus how big the
device/image is. And since it has more sectors, it has more clusters,
and then it needs more FAT space to manage those clusters.

Roman

Alec Voropay

22 years ago

Permalink

Hi!

It seems, I have found the source of difference.
Nor 'mformat' nor 'mksfs.vfat' can't determine
_real_ Geometry of SCSI MO.

I found one MS-DOS factory formatted 230Mb MO
media, it shows me :

***@ns2:~# minfo m:
device information:
===================
filename="/dev/sdc"
sectors per track: 25
heads: 1
cylinders: 17853

mformat command line: mformat -t 17853 -h 1 -s 25 m:
....

It seems, it's more close to reality (no geometry
translation), the real Fujitsu drive has only _1_ head.
:-)

P.S. I will try to setup real geometry via
Linux kernel LILO boot line:
image=/boot/vmlinuz-2.4.18-10
label=linux
read-only
root=/dev/sda1
append="sdc=17853,1,25"

--
-=AV=-

Hodek Roman

22 years ago

Permalink

It seems, I have found the source of difference. Nor 'mformat' nor
'mksfs.vfat' can't determine _real_ Geometry of SCSI MO.

Sure... it's a SCSI disk, so it has no geometry. C/H/S geometries have
been invented by ancient IDE and PC BIOSes, SCSI never had that
concept and used the same thing known als LBA in the IDE world from
the beginning... :)

But the SCSI host adapter driver has to report a geometry, so it
either reports some default one, or tries to determine it from the
partition table, or something else... But it never can be a real
geometry.

It seems, it's more close to reality (no geometry translation), the
real Fujitsu drive has only _1_ head. :-)

There's no such thing as a "real geometry", even for IDE disks (at
least ones not older than 8 years). All of them use a different number
of sectors depending on the track number, but hide that from the
interface. But IDE drives were forced to report some geometry by the
ATA interface. But also this geometry is virtual (though software
can't tell the difference...)

Roman

Alec Voropay

22 years ago

Permalink

Hi!

Yes, I agree about SCSI.

There is no partition table on MO, so it is impossible
to determine geometry from disk BPB.

Unfortunately, 'mkfs.vfat' has no options to setup
C/H/S manually.

This is possible to define geometry in 'mformat' via
/etc/mtools.conf
=====
drive m:
file="/dev/sdc"
cylinders=17853 heads=1 sectors=25
mformat_only
=====

One bad thing in 'mformat' is incorrect Media Descriptor
Byte. Factory formatted media has 0xf8 there.

However, AFAIK 128Mb and 230Mb MO Medias _has_ the
real geometry (to confom ECMA-145 and ISO 13963 [??])
Heads=1 , Sectors=25

Unfortunately, I can't find full spec, only
brochures from Varbatim and BASF :
http://www.verbatim.com/products/images/90545.pdf
http://products.emtec-group.com/Media/20300/application/pdf/info/

--
-=AV=-

-----Original Message-----
From: Hodek Roman [mailto:***@erlf.siemens.de]
Sent: Wednesday, January 29, 2003 7:28 PM
To: ***@sensi.org
Cc: ***@yggdrasil.com; ***@tux.org
Subject: Re: 'mformat' .vs. 'mkfs.vfat' on 230Mb MO

It seems, I have found the source of difference. Nor 'mformat' nor
'mksfs.vfat' can't determine _real_ Geometry of SCSI MO.

It seems, it's more close to reality (no geometry translation), the
real Fujitsu drive has only _1_ head. :-)

Hodek Roman

22 years ago

Permalink

There is no partition table on MO, so it is impossible to determine
geometry from disk BPB.

So the geometry under Linux is probably invented by the SCSI host
driver...

Unfortunately, 'mkfs.vfat' has no options to setup C/H/S manually.

Hm, it would make sense to be able to override H and S, because those
values end in the DOS bootsector. (Though they're just needed by DOS
bootloaders.) The number of tracks/cylinders isn't needed by mkdosfs.

Roman

Alexander Voropay

22 years ago

Permalink

--
-=AV=-