Hi
I have noticed that there is not much information about
magneto-optical disks in the howto, which may be due to the fact that
these are not very popular in general. In Japan, MO drives are very
common, especially the 3.5' variety with media in 128MB (maybe not
available anymore), 230MB, and recently 640MB sizes. I suppose there
is plenty of info on usage of these drives with Linux in Japanese -
but that does not help most people for some reason ;-) MODs can be
used very much like any removable media and are handy for smaller
backups as the media are relatively inexpensive (about 10US$ / 640MB
as of 10-98). I can only comment on the usage of 230MB drives with
SCSI interface.
Drives used: several, no problems encountered (Olympus, Epson, currently
Mitsubishi MK230LK3). Drives may have strange jumper setting like "Mac
Mode" or such - naturally, disable.
If you decide to get a drive, pay attention the the
cache size - It can speed things up enormously, still speed will be
soso compared to hard disks, of course.
SCSI controllers: NCR53C810-based (Asus PCI-200), Adaptec APA-1460A,
Adaptec AHA2940.
Just install the drive as you would do with an additional SCSI hard
disk. It will show up as such. You don't need a disk in the drive when
booting.
There are two ways to format the disks:
a) A bit like a floppy. Just run mkfs on the raw device i.e. something like
sdb or sdc. I don't recommend this in general (see below).
b) Like a hard disk. Do fdisk on the raw device and then mkfs on the
partition as you would for a hard disk (like sdc0, I have never made
multiple partitions on a MOD).
What I have not tried is to boot from MOD, yet I cannot see why it
should not work. I would only recommend it for emergency system
recovery, however, due to MO drive performance.
Note: Purchased disks for Doze or Windog may be formatted "like
floppies" and cannot be used with either O(gre)S right away while MODs
formatted under linux as hard disks (partition FAT16 / type 6 and
mkdosfs) will work fine (only tested with NT 3.5/4.0). Fdisk will
issue a warning upon exit that concerned FAT16 partitions and you do
better to take it seriously (look at the fdisk man-page). The sector
size will not be automatically set properly for mkdosfs. Use "mkdosfs
-s 8". That came from some Japanese Web site in mid 1995 (Thanks to Ken
Kawabata for finding and deciphering it). Using the vfat file-system
with the disks works fine. I have only used FAT/DOSfs or Linux/ext2
formatted disks so far.
Additional Note: The media are probably a bit sensitive. Of course to
magnetic fields, but also to mechanical stress, some formats seem
to be more fragile than others (Mac format seemingly worst, data loss has
occurred when dropping disks during sneaker net traffic).
Though this does not steer anyone through particularly dense
jungle, it may be nice for completeness.
Steve
--
***********************cut*here*or*do*not********************************
S. Shuichi Haupt
email stephan@bios.t.u-tokyo.ac.jp
http://www.bios.t.u-tokyo.ac.jp/~stephan/
---------------- December 11 1998 update from Steve -------------------
OK, some problems will arise with MO disks occasionally. the safest
way to avoid them is not to use the disks "off the shelf". trying to
mount disks can even result in kernel panics. i accidentally tried to
mount a 640MB disk (format windows95 it said, so maybe FAT32) as -t
vfat, this is not a thing to try.
also, 2.0.x kernels don't support 2048b block size (also 640MB disks).
a patch for 2.0.3x kernels seems to float around somewhere in Japan,
but i have not yet gotten hold of it. here a link that certainly has
an English description:
http://elektra.e-technik.uni-ulm.de/~mbuck/linux/patches.html
or search the u-tokyo.ac.jp domain. the page of the developers is
hidden somewhere.
the best way to use these 640MB disks is therefore to do fdisk and
mkfs first. i have only done this with mke2fs on type 83 partitions:
mke2fs -b 2048 /dev/sdxy
i will check it out for FAT16 partitions and mkdosfs when i have some
spare time and disks.
my kernel version used is 2.1.124 (for all of the above).
Steve
--
***********************cut*here*or*do*not********************************
Stephan Shuichi
office: Dept. for Mechano-Informatics, Yoshizawa Lab.
Faculty for Engineering, University of Tokyo
Tel 03-3812-2111 ext 6390, FAX 03-5802-2957
email stephan@bios.t.u-tokyo.ac.jp
http://www.bios.t.u-tokyo.ac.jp/~stephan/
private: --

You've probably already received a number of messages regarding the
Fujitsu DynaMO 640 - I have the 640SZI, which is the internal version;
the model number given in a SCSI probe is M2513-MCC3064SS. I recently
installed this drive practically without a hitch. I say practically
because the sector size of the 640 MB disks is 2048 bytes, which is
not supported in the Linux 2.0.x kernel but is supported in the
development kernels. A patch for 2.0.x is available at
http://wwwcip.informatik.uni-erlangen.de/~orschaer/mo/
-- also at this site is a patched fdisk to use in conjunction with it.
Otherwise, installing the drive was no different from installing a
SCSI hard drive. It runs well, and I'm very happy with it.
Phil Garcia

Dear Skip,
hoping that this is interesting for other Linux-Users, I want to tell You
about my experiences
with optical disks under Linux:
I use an internal 640 MB MO-Drive with IDE-Interface from Fujitsu with
Linux-Kernel 2.2.x and
in the meantime it works fine. At Germany this drive is sold as DYNAMO 640
AI but according
to it's firmware it is a MCC 3064 AP.
Booting kernel 2.2.x the drive is detected like "hdx: FUJITSU MCC3064AP,
ATAPI OPTICAL drive". No driver is loaded, as there still is no ATAPI-
driver for optical disks. Older kernels
(2.0.x) do not detect the drive correctly and surely need some patches.
To use the drive I need kernel support for SCSI-emulation. So I compile
this (ide-scsi.o)
as a module together with the SCSI-disk-support (sd_mod.o). Making a
"modprobe ide-scsi",
the drive shows up in /proc/scsi/scsi. If it isn't done by kerneld I have
to make
"modprobe sd_mod" to be ready to mount the preformatted MO-disk.
If I want to use the disks with Dos/Windows, I use the Dos/Windows-tools
for formatting. I tried
mkdosfs under Linux too, but then most files on the disk seemed to be
corrupted for Dos.
They were still o.k. for Linux and could be restored without problems. With
the Dos-tools I
prefer the Superfloppy-Format as this can be used with most
operating-systems and it is slightly
faster in comparison to a partitioned disk. This disks can be mounted like
other
Windows-Disks (e.g. "mount -t vfat /dev/sdx /mountpoint").
Disks for Linux should be in ext2-Format. The 640 MB disks are hardsectored
with
2048 bytes/sector (smaller media aren't.) . This is no problem for kernel
2.2.x, but fdisk and mke2fs do not agree in how to manage this geometry. So
I don't use fdisk anyway and format
the disks with "mke2fs -b 2048 /dev/sdx". I have to tell mke2fs about the
2048 bytes/sector with
the "-b"-option, otherwise the format will fail. Mke2fs than asks to really
do his job, as it has do
format the whole disk not a single partion and I answer with "y".
Now the disk can be mounted with "mount -t ext2 /dev/sdx /mountpoint",
which gives a warning
in /var/log/messages about a nonexisting partion-table. This is o.k. as
fdisk wasn't used and
I can now use the disk. The MO-Disks are slow, but the most reliable media
available.
Smaller disks (230 MB) are hardsectored for 512 bytes/sector and can be
partioned with fdisk.
before formatting. This should be true for the 512 MB disks, but I didn't
test it.
Best regards and thanks for Your support for Linux,
Guido Brunner

Dear Skip,
I recently aquired a LF-7010 for a project.
My experience getting it up for Linux under ext2 mirrors what you
already have.
The msdos and vfat file systems also worked.
The project I was working on was based on a SunOS/Solaris formatted MO
disk. While it *should* have worked under the ufs file system, using
Redhat 5.2 and the stock 3.0.36 kernel it didn't.
I got, installed, debugged and compiled the u2fs into the kernel and it
DID mount the SunOS/Solaris MO disk.
Please write if you need/want additional details.
-Donald
Donald Kerns <dkerns@cruzio.com>

Hi Skip,
I've used your 'Linux-Optical Disk HOWTO' to setup our magneto-optical
drive.
You mentioned somewhere in the HOWTO that you'd like to receive
additional informations, and since I've used a drive which was not
included, I'd like to tell you about it. Hope it can help someone!
Used hardware:
INTEL Pentium 90
SCSI-Controller ADAPTEC 2940
MO-Drive Fujitsu MCD3130SS (1.3 GB Capacity)
Software:
S.u.S.E.-LINUX 6.1, Kernel-Version 2.2.5
There is no "native" driver for the 2940AU, so I used the "aic7xxx"
which I load as a module during bootup (I didn't want to compile a new
kernel, because I need many other features, and expect of the MO-Drive,
everything worked fine before. So, why "change a running system"?!)
I can mount the MO-Disk, no matter what filesystem is used, entirely.
In addition to that, I set up autofs to ease my work:
in /etc/auto.misc, I added the line:
==================/SNIP/===============
/misc/mo-disk -fs auto /dev/sda1
==================/SNAP/==============
With that, I even don't need to mount the drive, I can access it
whenever I want, no matter what filesystem is used (tested with MSDOS
and ext2-fs)
Finally, I used SAMBA to export the drive to our WIN95-Clients with the
following inserted in /etc/smb.conf:
=======================/SNIP/======================
[mo-disk]
path = /misc/mo-disk
public = yes
writeable = yes ;write-only can of course still be controlled by
flipping the
;write-protect-switch at the MO-Disk!
readable = yes
browseable = yes
=======================/SNAP/=======================
(for further details abt. SAMBA, refer to the excellent HOWTO)
Now, every WIN-Client can use the MO-Drive as if it was a local hdd,
with one (minor) caveat:
When you map the exported SAMBA-Drive to a drive letter in WIN Explorer,
it's impossible to umount it under LINUX! Everytime you try, you get a
"device busy"...
So, unfortunately I can't map the drive during startup in WIN95, but I
think with some hacking in the SAMBA-Code this problem could be
solved...
I don't have the time at the moment, but perhaps somewhat later I will
try to "dig into the code" to do the hack.
Of course you can include my e-amil-address in the HOWTO, but please use
my private one:
dh9dat@cityweb.de instead of ds@leiterplattentechnik.de!
with regards,
Harald Husemann
LINUX - the operating system for people whose IQ is greater than 98...
Harald Husemann <ds@www.leiterplattentechnik.de>

Hi,
Just stumbled across your page on Tucows (dated Dec '98 so I hope this
still reaches you). You asked if anyone had any experience with optical
storage etc. under Linux, which I have, so here it is!
I worked for Ericsson (UK) Ltd. and some of their telephone switches use
optical media for system backups. I have used these optical drives on
i386 Linux boxes for some years now, with no problems whatsoever.
The units in question are the Ricoh RO-5031E (scsi) and it's bigger
brother, which unfortunately I cannot remember that name of (also Ricoh
+ scsi). The RO-5031E is a full-height, 5.25in magneto-optical drive
that uses 650Mb disk cartridges (325Mb per side), such as Sony's
EDM-650B. The other drive has similar spec but can use both 1.3Gb and
650Mb disks. Ricoh's website may have more on these drives, but they're
quite long in the tooth now and may not feature anymore.
Usage was very simple - The drives were treated almost as scsi fixed
disks. Pop a new disk in, use fdisk to create your filesystem (I've
tried both ext2 & msdos) then format with mkfs. That's it!
The one weird thing I did find was that a RedHat 6.x system (2.2.x
kernel) would not read a filesystem that had been created on an old
Slackware (2.0.x kernel) system, and vice versa. Other than that, 100
million re-writes... thankyou very much!!!
All the best // Jem
P.S. Please feel free to include my email if I've been of any help.
jem <jem@monty.ericsson.se>

Maxoptix TMT3-1300 Magneto Optical drive.
Accepts 1Gb and 1.3Gb magneto-optical read/write cartridges,
these are double sided, so half the capacity is on each side,
and the cartridge needs to be ejected to access the opposing side.

When configuring a Maxoptix drive for Linux, it should be configured such that
the Removable Media Report Disable switch is OFF
(the dip switch bank S2, switch 3 is OFF, i.e. in down position).

When configuring a Maxoptix drive for Linux, it should NOT be configured such
that Removable Media Report Disable is switched ON
(the dip switch bank S2, switch 3 is ON, i.e. in up position).

Setting this switch ON will set the RMB (removable media bit) to 0.
This would indicate to Linux that the media is NOT removable, but
Linux of course still allows one to eject it using the command
eject /dev/sda
or by pressing the invitingly large button on the drive itself.
This could have the consequence of accidentally corrupting any
of the good data stored on cartridges inserted subsequently, since
Linux has still cached the directory information of the previous disk.

When the RMB is 0, even after the cartridge is ejected, it is possible
to perform the mount command, and have it 'succeed', since Linux has
still got the directory structure of the previous disk cached in its buffers,
which have not been flushed. One way to force Linux to flush its buffers
in this situation, is to do the following sequence:
eject /dev/sda
(do NOT insert a new cartridge before performing the next two steps)

Alexander supplied me with some very informative points.
He has ask me to pass that information on to you. Without
fully understanding all areas that he knows, I am attempting
to pass it on to you as best I can;

Type of 3.5" MO drives

There are two kind of 3.5" Magneto Optical drives :
DynamMO and GigaMO