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.
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.)
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.
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!
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
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
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
/dev/sda /mnt/mo ext2 defaults,noauto 0 0
yksi:/mnt/mo# umount /mnt/mo # (Whoops!) umount: /mnt/mo: device is busy yksi:/mnt/mo# cd .. yksi:/mnt# umount /mnt/mo yksi:/mnt#