Next Previous Contents

3. Magneto Optical Technology - Daniel Kobras

3.1 Introduction

Daniel Kobras <kobras@linux.de>

Magneto optical drives use a "far field" magnetic field and a laser to change polarization of a magnetic media. At temperatures below 180-200°C (350-390°F) magnetic polarization is "frozen" into the media. However when heated above this so-called Curie-temperature a static external magnetic field can change the polarization. When the media cools down below its Curie-temperature, the information is frozen again. A high power write laser is used to heat the disk surface to the appropriate temperature at which time the "Far field" can set the polarization on the disk magnetic surface.

Read back is based on the so-called Kerr effect, i. e. depending on the direction of the magnetic field on the disk's surface, the plane of polarization of the incoming laser beam is slightly rotated and the information can be restored.

The use of a laser for polarization change allows for bit and track densities much higher than on conventional "flying" magnetic heads. The "far field" means no more "head crashes" - that is assuming your disk label doesn't peal off during the load or you don't leave one of those sticky pads on the disk cartridge. Nowadays the most commonly used 3.5" media have a capacity of 640MB[*] per platter but there are still media with 540MB, 230MB and 128MB. On some models both sides of the media are used yielding up to a capacity of 1.3GB - you must remove the media and flip it over to use the other 640MB though. There are 5.25" media with up to a total of 2.6GB, but these have to be flipped as well.

The major drawback with ordinary magneto optical media was their need for an extra erase cycle considerably slowing down write speed. That's where LIMDOW media come in. LIMDOW (Light Intensity Modulated Direct OverWrite) disks use a more sophisticated set of five different magnetic layers. Thus the erase cycle can be omitted yielding a 33% speed up, as only one write and one verify cycle have to be performed. Read back is identical to ordinary disks. Please check with your drives manual if you want to use LIMDOW media. I only have experience with Fujitsu's M2513 which works well with LIMDOW. As far as other drives are concerned I simply don't know.

Manufacturers claim the life time of magneto optical media to be 30 years and up. Disks can be rewritten at least 10 million times (1 million for LIMDOW media). Reading is claimed safe for at least 100 million times.

[*] There's a sort of religious discussion going on whether 1MB should be understood as 1x1.000x1.000 bytes or rather 1x1.024x1.024 bytes. Here we use 1MB==1.000.000 bytes, the definition preferred by vendors for obvious reasons. Don't worry if Linux reports your media to be smaller - it's just a matter of definition.

3.2 Setup

First of all, make sure your MO drive is sanely jumpered, i.e. make sure its SCSI id is unique on your system, Parity checking and SCAM mode settings resemble those of your other SCSI devices as well as your controller and do _not_ enable any weird looking options such as "Mac Mode" or the like. Your drive might be equipped with an internal write cache, but since Linux already does pretty good caching on its own, don't expect too much of a performance gain, if any. Also keep in mind that each additional level of caching is a source of possible data loss or corruption in case of failing hardware. Consequently the recommended paranoia setting is to turn off the write cache.

As long as you're not using 640MB disks, setting up the MO drive is rather straightforward. Assuming your drive is properly installed, at boot/insmod time, your SCSI-Controller should notify you of the newly added drive and configure another SCSI device like /dev/sda, /dev/sdb... (Keep in mind that the SCSI bus is scanned with increasing SCSI id, so if your SCSI hard disk for example is ID 4 and used to be /dev/sda and your MO drive has ID 3, the MO will now be /dev/sda whilst the HD is /dev/sdb.) Working with your MO is no different from working with an ordinary hard disk. You can partition it (more information on this topic is given below), create file systems, mount it as usual. Note that as long as the disk is mounted the drive is locked and you won't be able to change the disk.

Be careful when trying to get 640MB disks to work. These use a hard-sector size of 2048 bytes, 2.0.xx kernels will support only 512 and 1024 bytes per sector. However 2048 byte support has been added to 2.1.32 and up. If you for some reason have to stick to 2.0.xx, there are several patches floating around, for example at

* http://liniere.gen.u-tokyo.ac.jp/2048.html, * http://wwwcip.informatik.uni-erlangen.de/ orschaer/mo/ * http://elektra.e-technik.uni-ulm.de/ mbuck/linux/patches.html

Be sure to use a either a patched version of fdisk available at some of the sites above or a recent enough version from the official util- linux package supporting the -b option. (Invoke with fdisk -b 2048 /dev/sdXX when partitioning 2048 byte media.)

3.3 Access

There are two alternatives of how to access your disks: the ordinary method of creating one or more partitions or just accessing the raw drive, which in Win/DOS environments is also known as the superfloppy format.

The first method will require non-640MB disks or a 2048-byte-aware fdisk, the latter is suitable for any kind of disk, however these disks cannot be read with Windows NT up to version 4.0. There's a comment on Fujitsu's web-pages that super-floppy support will be added to NT in the future.

Assume your MO drive is /dev/sdb. To create a partition simply enter fdisk /dev/sdb (or fdisk -b 2048 /dev/sdb with 640MB media and a recent copy of fdisk) as root and go on like you were to partition a hard disk. If unsure about what to do, have a look at the fdisk man page. Next create a file-system on each partition with a command like mke2fs -m 0 /dev/sdb1. For 640MB disks be sure to specify the -b 2048 flag. If you want to use super-floppies instead, leave out the fdisk part and create your file-system on the raw device, for example mke2fs -b 2048 -m 0 /dev/sdb. mke2fs will request confirmation before formatting a raw device. You might want to double check if /dev/sdb *really* is your MO drive and not your hard disk by chance. :) During the boot process (or when loading the low level SCSI module), Linux might moan about an invalid partition table if a super-floppy is in the MO drive. You can safely ignore this message.

*NOTE: Partitions on 2048 byte sectored media were broken throughout the whole 2.1 kernel series, meaning that you can happily partition your media with 2.1.xxx but will be unable to use them with any OS other than Linux 2.1! In other words: DON'T DO IT. If for any reason you still have to access your MOs on Linux 2.1 use super-floppies which do fine. This problem hopefully is completely fixed starting with Linux 2.2.2.

File-systems other than ext2 will work on non-640MB disks as well, for 640MB disks there are some caveats: 2048 byte blocks must be supported by the low level file-system code in the kernel and the appropriate mkfs tool should take an argument like -b 2048 to specify the block size. Kernel requirements are met at least for ext2 and msdos/vfat code in the 2.1.xx kernel line. The above mentioned patches should fix this as well for 2.0.xx kernels. I don't have any experience with other file-systems so I'd appreciate any comments. Of the mkfs tools mke2fs will definitely accept the -b flag. mkdosfs is trickier though: there's no top level maintainer anymore, but some distributions have their own maintainers and ship their own versions. Debian's mkdosfs is one such example. Beginning with version 1.0-17 it supports media with large sector sizes. You have to add an option -S 2048. Pass -I as well if you want to format a super-floppy. The latest Debian version of mkdosfs should always be available from ftp.debian.org. Look out for a package called dosfstools.

3.4 Speed

For the really curious but still undecided I've crammed up some figures as returned by bonnie. These are for the Fujitsu M2513 spinning at 3600 rpm, an outdated model now replaced by a version spinning at 4300 rpm. I guess the transfer rates for the new drive will scale with the spin ratio or pretty close to it. Tests were performed running a slightly patched 2.2.2pre4 kernel. (Err... looks like I've disabled verify on my drive, better not do that!)

LIMDOW - ext2-filesystem - superfloppy:

    -------Sequential Output-------- ---Sequential Input-- --Random--
    -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
 MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
400  1024 16.3  1816  2.8   620  1.7   975 13.5  1952  2.2  41.4  0.7
                            

LIMDOW - vfat-filesystem - superfloppy:

    -------Sequential Output-------- ---Sequential Input-- --Random--
    -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
 MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
400   387  8.3   410  2.9   414  3.4   669 13.4   736  5.4   5.2  3.9

The bottom line is: performance on vfat sucks like hell. If you have an option, use ext2!

3.5 Sample session

Here's an example of what accessing the MO look like on my machine:


yksi:~# modprobe scsi_mod
scsi: ***** BusLogic SCSI Driver Version 2.1.15 of 17 August 1998 *****
scsi: Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>
scsi0: Configuring BusLogic Model BT-930 PCI Ultra SCSI Host Adapter
scsi0:   Firmware Version: 5.02, I/O Address: 0xDE00, IRQ Channel: 18/Level
scsi0:   PCI Bus: 0, Device: 15, Address: 0xFE00F000, Host Adapter SCSI ID: 7
scsi0:   Parity Checking: Enabled, Extended Translation: Enabled
scsi0:   Synchronous Negotiation: Ultra, Wide Negotiation: Disabled
scsi0:   Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled
scsi0:   Driver Queue Depth: 255, Scatter/Gather Limit: 128 segments
scsi0:   Tagged Queue Depth: Automatic, Untagged Queue Depth: 3
scsi0:   Error Recovery Strategy: Default, SCSI Bus Reset: Enabled
scsi0:   SCSI Bus Termination: Disabled, SCAM: Disabled
scsi0: *** BusLogic BT-930 Initialized Successfully ***
scsi0 : BusLogic BT-930
scsi : 1 host.
Vendor: PLEXTOR   Model: CD-ROM PX-32TS    Rev: 1.03
Type:   CD-ROM                             ANSI SCSI revision: 02
Vendor: FUJITSU   Model: M2513A            Rev: 1300
Type:   Optical Device                     ANSI SCSI revision: 02
scsi0: Target 1: Queue Depth 3, Synchronous at 20.0 MB/sec, offset 15
scsi0: Target 3: Queue Depth 3, Synchronous at 10.0 MB/sec, offset 10

As you can see, I have two SCSI devices attached: one CD-ROM drive and one MO drive. As CD-ROMs do have SCSI devices of their own (/dev/scdX), the MO is assigned to /dev/sda.

Let's create an ext2-based super-floppy on the media:


yksi:~# mke2fs -m 0 -b 2048 /dev/sda
mke2fs 1.12, 9-Jul-98 for EXT2 FS 0.5b, 95/08/09
/dev/sda is entire device, not just one partition!
Proceed anyway? (y,n) y
Detected scsi removable disk sda at scsi0, channel 0, id 3, lun 0
SCSI device sda: hdwr sector= 2048 bytes. Sectors= 310352 [606 MB] [0.6 GB]
sda: Write Protect is off
 sda:
Linux ext2 filesystem format
Filesystem label=
155344 inodes, 310352 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Block size=2048 (log=1)
Fragment size=2048 (log=1)
19 block groups
16384 blocks per group, 16384 fragments per group
8176 inodes per group
Superblock backups stored on blocks:
         16384, 32768, 49152, 65536, 81920, 98304, 114688,
         131072, 147456, 163840, 180224, 196608, 212992, 229376,
         245760, 262144, 278528, 294912

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

Now mount the media to directory /mnt/mo (which already exists).
yksi:~# mount -t ext2 /dev/sda /mnt/mo
yksi:~# ls /mnt/mo
lost+found
yksi:~# df
Filesystem         1024-blocks  Used Available Capacity Mounted on
/dev/hda6             124407   48963    69020     42%   /
/dev/hda7             256592      30   243310      0%   /tmp
/dev/hda8             124407   31750    86233     27%   /var
/dev/hda9             505440  174092   305244     36%   /home
/dev/hda10           2028098 1278972   644304     66%   /usr
/dev/hda11           2028098 1551617   371659     81%   /usr/local
/dev/sda              601134      26   601108      0%   /mnt/mo

/mnt/mo can now be used like any ordinary hard disk. You may also choose to add a line like the following to your /etc/fstab:
/dev/sda    /mnt/mo    ext2 defaults,noauto 0 0

Then mount /mnt/mo will suffice to mount any ext2-formatted media. Before removing the media from your MO drive, don't forget to unmount it.
yksi:/mnt/mo# umount /mnt/mo            # (Whoops!)
umount: /mnt/mo: device is busy
yksi:/mnt/mo# cd ..
yksi:/mnt# umount /mnt/mo
yksi:/mnt#

Pretty easy, isn't it?


Next Previous Contents

mirror server hosted at Truenetwork, Russian Federation.