LDP/LDP/howto/linuxdoc/Optical-Disk-HOWTO.sgml

1480 lines
58 KiB
Plaintext
Raw Blame History

<!doctype linuxdoc system>
<article>
<!-- Title information -->
<title>Linux - Optical-Disk-HOWTO
<author>Skip Rye, <htmlurl url="mailto:abr@preferred.com"
name="abr@preferred.com">
<date>v1.7, 26 Novenber 2000
<abstract>
This document describes the installation and configuration of
optical disk drives for Linux.
Please, if any one has experiences with optical storage under Linux, send
it and I will update it in SGML and forward it to the Linux community.
Please let me know if it's OK to include your E-mail address!
</abstract>
<!-- Table of contents -->
<toc>
<!-- Begin the document -->
<p>
<sect>Disclaimer
<p>
Neither the author nor the distributors, or any other contributor of this HOWTO are in any way
responsible for physical, financial, moral or any other type of damage
incurred by following the suggestions in this text.
<sect>Copyright 1996,1997,1998,2000
<p>
The "Optical-Disk-HOWTO" and "LF1000 mini-HOWTO" are copyrighted.
<sect1>LF1000 mini-HOWTO
<p>
(C) 1996,1997 by Skip Rye, abr@brspc_0064.msd.ray.com
<sect1>Optical-Disk-HOWTO
<p>
(C) 1997,1998,2000 by Skip Rye, abr@preferred.com
<p>
Linux HOWTO documents may be reproduced and
distributed in whole or in part, in any medium physical or electronic, as long
as this copyright notice is retained on all copies. Commercial redistribution
is allowed and encouraged. The author, however, would like to be notified
of any such distributions. All translations, derivative works, or aggregate
works incorporating any Linux HOWTO documents must be covered under
this copyright notice. In other words, you may not produce a derivative work
from a HOWTO and impose additional restrictions on its distribution.
Exceptions to these rules may be granted under certain conditions. In short
we wish to promote dissemination of this information through as many
channels as possible. However, we do wish to retain copyright on the
HOWTO documents, and would like to be notified of any plans to
redistribute the HOWTOs. Should you have any questions, please contact
Greg Hankins, the Linux HOWTO coordinator, at gregh@sunsite.unc.edu.
You may finger his address for phone number and additional contact
information.
<sect>Optical Disk HOWTO Development Page
<p>
<htmlurl url="http://pages.preferred.com/~abr/lf1000.html"
name="Optical-Disk-HOWTO Homepage">
This link may contain more up-to-date information!!!
<sect>Magneto Optical Technology - Daniel Kobras
<p>
<sect1>Introduction
<p>
<htmlurl url="mailto:Daniel Kobras <kobras@linux.de>" name="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<30>C (350-390<39>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.
<p>
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.
<p>
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.
<p>
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 drive's 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.
<p>
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.
<sect1>Setup
<p>
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 lossage or
corruption in case of failing hardware. Consequently the recommended
paranoia setting is to turn off the write cache.
<p>
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 while 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.
<p>
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
<p>
* 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
<p>
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.)
<p>
<sect1>Access
<p>
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 super-floppy
format.
<p>
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.
<p>
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 filesystem 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 filesystem 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.
<p>
*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.
<p>
Filesystems 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 filesystem 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.
<sect1>Speed
<p>
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!)
<verb>
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
</verb>
The bottom line is: performance on vfat sucks like hell. If you have
an option, use ext2!
<sect1>Sample session
<p>
Here's an example of what accessing the MO look like on my machine:
<code>
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
</code>
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.
<p>
Let's create an ext2-based superfloppy on the media:
<code>
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
</code>
Now mount the media to directory /mnt/mo (which already exists).
<code>
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
</code>
/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:
<code>
/dev/sda /mnt/mo ext2 defaults,noauto 0 0
</code>
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.
<code>
yksi:/mnt/mo# umount /mnt/mo # (Whoops!)
umount: /mnt/mo: device is busy
yksi:/mnt/mo# cd ..
yksi:/mnt# umount /mnt/mo
yksi:/mnt#
</code>
Pretty easy, isn't it?
<sect>Other Technical URLs
<p>
<htmlurl url=" http://www.one.ne.jp/teijin/indexe.html" name="JEIJIN Recording Media">
<sect>Magneto Optical Drives Under Linux
<sect1>Fujitsu DynaMO 640 - Phil Garcia
<p>
<htmlurl url="mailto:pgarcia@execpc.com" name="pgarcia@execpc.com">
<verb>
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
</verb>
<sect1>Panasonic LF-7010 - Philip Kerr
<p>
<htmlurl url="mailto:philip_kerr_at_wmc__brsf2@wmcmail.wmc.ac.uk" name="philip_kerr_at_wmc__brsf2@wmcmail.wmc.ac.uk">
<verb>
Dear Skip
In your Optical HOWTO, you asked for anyone else's experiences of
installing optical drives under Linux.
Please find below details of how I managed to get a Panasonic LF-7010
(SCSI) working on my Sparc Classic.
I'm using Redhat, 4.2 and 5.1
Regards
Philip Kerr
philip.kerr@wmc.ac.uk
ps I'm now trying to get the drive to work under Solaris 2.6... it's
not an easy a job as it was under Linux!!
------------------------
plugged the drive in (on id5)...
powered up the Sparc...
the following came up....
scsi0 : Sparc ESP100A-FAST
scsi : 1 host.
Vendor: SAMSUNG Model: WN32162U Rev: 0100
Type: Direct-Access ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 3, lun 0
Vendor: MATSHITA Model: LF-7010 (00:06) Rev: 1.42
Type: Optical Device ANSI SCSI revision: 02
Detected scsi removable disk sdb at scsi0, channel 0, id 5, lun 0 scsi
: detected 2 SCSI disks total.
esp0: target 3 [period 100ns offset 15 10.00MHz FAST SCSI-II]
SCSI device sda: hdwr sector= 512 bytes. Sectors= 4236661 [2068 MB]
[2.1 GB]
esp0: target 5 [period 248ns offset 4 4.03MHz synchronous SCSI] sdb :
READ CAPACITY failed.
sdb : status = 0, message = 00, host = 0, driver = 28 sdb : extended
sense code = 2
sdb : block size assumed to be 512 bytes, disk size 1GB.
sunlance.c:v1.9 21/Aug/96 Miguel de Icaza (miguel@nuclecu.unam.mx)
eth0: LANCE 08:00:20:04:3d:cf
eth0: using auto-carrier-detection.
Partition check:
sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8
sdb:scsidisk I/O error: dev 08:10, sector 0, absolute sector 0 unable
to read partition table
I edited my fstab, adding the entry for the drive (on sdb)
==========
/etc/fstab
==========
/dev/sda1 / ext2 defaults 1 1
/dev/sda2 swap swap defaults 0 0
/dev/fd0 /mnt/floppy msdos noauto,user 0 0
/dev/sr0 /mnt/cdrom iso9660 noauto,ro,user 0 0
/dev/sdb /mnt/optical ext2 noauto,rw,user 0 0
none /proc proc defaults 0 0
Then mkfs'ed a blank disc as follows...
[root@localhost me]# /sbin/mkfs -t ext2 /dev/sdb
mke2fs 1.10, 24-Apr-97 for EXT2 FS 0.5b, 95/08/09 /dev/sdb is entire
device, not just one partition! Proceed anyway? (y,n) y
Linux ext2 filesystem format
Filesystem label=
118320 inodes, 472448 blocks
23622 blocks (5.00%) reserved for the super user First data block=1
Block size=1024 (log=0)
Fragment size=1024 (log=0)
58 block groups
8192 blocks per group, 8192 fragments per group 2040 inodes per group
Superblock backups stored on blocks:
8193, 16385, 24577, 32769, 40961, 49153, 57345, 65537, 73729, 81921,
90113, 98305, 106497, 114689, 122881, 131073, 139265,
147457,
155649, 163841, 172033, 180225, 188417, 196609, 204801,
212993, 221185,
229377, 237569, 245761, 253953, 262145, 270337, 278529,
286721, 294913,
303105, 311297, 319489, 327681, 335873, 344065, 352257,
360449, 368641,
376833, 385025, 393217, 401409, 409601, 417793, 425985,
434177, 442369,
450561, 458753, 466945
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
rebooted...
mounted the drive...
I've since then edited the fstab, adding the following mount-point...
/dev/sdb /mnt/dostical msdos noauto,rw,user 0 0
I can now mount ext2 or dos formatted optical carts by mounting either
optical or dostical.
</verb>
<sect1>LF-7010 - Donald Kerns
<p>
<verb>
Dear Skip,
I recently acquired 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 <dkerns@cruzio.com>
</verb>
<sect1>Olympus, Epson, currently Mitsubishi MK230LK3 - Stephan Shuichi Haupt
<p>
<verb>
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
so so 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 Website in mid 1995 (Thanks to Ken
Kawabata for finding and deciphering it). Using the vfat filesystem
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
S. Shuichi Haupt
email stephan@bios.t.u-tokyo.ac.jp
http://www.bios.t.u-tokyo.ac.jp/~stephan/
----------------------------------------------------------------------------------
hi
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 blocksize (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
--
Stephan Shuichi ($B<~0l(B) Haupt ($B%O%&%W%H(B or $B%O%*%W%H(B)
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: --
</verb>
<sect1>DEC RZ01 - Megan Gentry
<p>
<verb>
I'm not sure this counts... but I am successfully using a
DEC RWZ01 magneto-optical drive, external, connected via
the SCSI bus.
I have been able to successfully mkfs and ext2 file system
on it, and have copied files to it...
I plan on using it as a backup medium. The disks are two-sided,
with about 295 MB available each side...
Oh yeah, this is on RHL-5.2 on an AMD5x86-160 system...
SCSI adapter is an AHA-1540CF
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com|
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/|
| Nashua, NH 03062 | "pdp-11 programmer - some assembler|
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
</verb>
<sect1>Maxoptix 520 - Zed Shaw
<p>
<htmlurl url="mailto:shawz@imap1.asu.edu" name="shawz@imap1.asu.edu">
<sect2>Zed's Original E-Mail - Feb 13 1998
<p>
<verb>
Hi,
I was reading your HOWTO (a life saver, thanks) and I was wondering what
kind of jukebox you were running? I have a Maxoptix 520 Jukebox (20
disks at 2.6G each, nice!) and I would like to connect it to a Linux box
and serve the drives up to my users, but I'm having problems accessing
the individual drives. Currently I can only access the two drives and
something called MAXLYB which I think is a controller device of some
sort.
Basically, I'm wondering if the jukebox you had was the same or similar
and how you set it up. I know that you did it under HP-UX, but any help
right now would be nice. Hey, I'll even let you log into my linux
server if you want to take a look at the jukebox and see what it does.
You can't beat 52Gig of storage!
Anyway, I'd really appreciate your help.
Zed A. Shaw
Application Systems Analyst
Arizona State University
</verb>
<sect2>E-Mail with Zed on Mon, 16 Feb 1998:
<p>
<verb>
> It sounds like your Maxoptix 520 is a jukebox with two physical disk.
Yep, that's the one.
>
> All jukeboxes have a carriage controller. This is probably your MAXLYB
> device.
> ...
What I've come to find out is that Maxoptix is pretty stingy when it
comes to drivers. Apparently, they don't make driver software for any of
their Jukebox carriage controller interfaces! I don't know how some of
these companies stay in business. I'm going to pester them again soon,
but you are right, this thing will need a carriage controller driver to
operate. The cool thing is that this MX520 (that's the model number of
the juke) emulates a whole slew of other carriage controllers, so maybe
one of those other guys has a driver. I'll be looking into that too.
>
> You might want to get a-hold of Maxoptix and see if they have a install
> package for your linux kernel version. If not ask them for the programmers
> specification for the carriage controller and maybe we can write one!
>
Hey, if I can't find any driver software, and I can convince Maxoptix to
give me the specs, I'd be more than glad to write a driver. I'd could
sure use the help too since I haven't got enough time to do it on my
own. Also, do you know of anyone else doing this that we might be able
to hack off of?
> Any information you find, let me know and we will roll the information
> into the Optical HOWTO, acknowledgments of course!
>
Sure, but let me get some new information first. So far things are
looking pretty bleak.
>
> >Basically, I'm wondering if the jukebox you had was the same or similar
> >and how you set it up. I know that you did it under HP-UX, but any help
> >right now would be nice. Hey, I'll even let you log into my linux
> >server if you want to take a look at the jukebox and see what it does.
> >You can't beat 52Gig of storage!
>
> Nice. At home I can use PPP to mount my 84 platter HP-UX jukebox.
> It's slow though - I wish I had it at home.
Oh, I don't have this thing at home. There's no way I could afford the
$30,000 my boss paid for this thing. But he's stuck with it and has had
it sitting around collecting dust for a year, so he's letting me play
with it and try to find a use for it.
I'll get back with you when I have some more information. It should be
sometime this week when I find out if I can get it to work or not.
Zed
</verb>
<sect1>Sony MO - Not sure what version - Gregory Hosler
<p>
<verb>
Hi there,
I have a Sony MO drive. I'll have to dig up model info at home.
It works swell under Linux. only glitch is that when I fdisk
I have to set the geometry. This is with an older (RH 4.2)
installation. do not know if this has been corrected w/ newer
distributions.
What can I tell you, as respect to the MO drive, and Linux.
This was virtually a no brainer, no multiple lun issues.
worked outta da box. no need to reboot after fdisking (just
remove the media. the insertion will cause a "disk change detected"
which will flush any cached partition table :)
-Greg
----------------------------------
E-Mail: Gregory Hosler <gregory.hosler@eno.ericsson.se>
Date: 10-Feb-99
Time: 13:47:399
"We've heard that a million monkeys at a million keyboards could produce
the Complete Works of Shakespeare; now, thanks to the Internet, we know
this is not true." Robert Wilensky, University of California
----------------------------------
</verb>
<sect1>HP Surestore Optical 5200ex - Bertrand JACQUIER
<p>
<verb>
Hi there !
I bring you my modest contribution to the optical disks
project under linux.
Well, an that's the good news, I haven't much to say.
I plugged a HP Surestore Optical 5200ex and a MATSHITA
LF 7010, respectively id 3 and 4 on our Adaptec 72xxx
SCI card.
I compiled the kernel (SCSI card was out of the box),
and booted.
that's it. I can mount respectively /dev/sda and
/dev/sdb, even format...
Note that I have no other device on my SCSI bus.
Hope it'll be useful,
Bertrand JACQUIER (France)
===
---------------
bj
---------------
bjacq@yahoo.com
</verb>
<sect1>FUJITSU MCC3064AP or DYNAMO 640 - Guido Brunner
<p>
<verb>
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 hard-sectored
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 partition 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 partition-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 hard-sectored for 512 bytes/sector and can be
partitioned 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 <GuidoBrunner@compuserve.com>
</verb>
<sect1> Fujitsu MCD3130SS (1.3 GB Capacity) - Harald Husemann
<p>
<verb>
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! Every time 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...
</verb>
<sect1>Ricoh RO-5031E - Jeremy Hosford
<p>
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, Olympus OD 1.3Gb drive model number is: MOS520E.
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.
begin:vcard
n:Hosford;Jeremy
tel;cell:(+44) 7831 112550
tel;fax:(+44) 1444 234970
tel;home:(+44) 1273 821394
tel;work:(+44) 1444 234577
x-mozilla-html:FALSE
org:TSS Ltd.;Telecom Software & Statistics
adr:;;TSS Ltd. TC4 Ericsson Way;Burgess Hill;W. Sussex;RH15 9UB;UK
version:2.1
email;internet:jem@monty.ericsson.se
title:Software Development & Systems Support
x-mozilla-cpt:;-8512
fn:Jeremy Hosford
end:vcard
<sect1>Pinnacle-Micro Vertex 2.6GB - Martin
<p>
Hi Skip
My name is Martin and I installed a Linux system on my Toshiba
Tecra 730CDT laptop without major problems (SuSE distribution
6.2). Connected to an Adaptec APA-1460A SCSI controller
I run a Pinnacle-Micro Vertex 2.6 GB magneto-optical disk drive
which works perfectly (1024 KB sector).
I also wanted to express my respect in relation to your work
you've done for the Linux community !
Regards
Martin
PS: if you have the time, have a look to our website(it's
probably worth the effort... ;-))
-----------------------------------------------------------------
E-Mail: mailto:info@globetrotters.ch
-----------------------------------------------------------------
Website: http://www.globetrotters.ch
-----------------------------------------------------------------
<sect1>Maxoptix T6-5200 - Donovan Allen
<p>
<verb>
I have used a Maxoptix T6-5200 with re-writeable MO media without any
problems.
Donovan Allen <admin@robot-factory.net>
</verb>
<sect>Optical Jukeboxes
<p>
I have no experience with optical jukeboxes with Linux!!!!
I have had experiences with Optical jukeboxes under HP-UX. In this
setup the the jukebox had a SCSI address of it's own. Each slot in
the jukebox had an associated LUN number. A device name was assigned
for each disk slot A side and B side. The mount command was run against
the appropriate device name. I had a jukebox with just one drive and
16 optical disk slots - 20 Gig. I thought it was going to be a real hassle
to write a disk mount manager to share this drive among users until
I discovered you can mount as many disk as you want and the jukebox
driver takes care of arbitration - what a nice feature. Granted, you
only want archive type data here and your overall system configuration
to be such that not too many processes will be accessing the jukebox at the
same time. The disk spin down, carriage load, carriage move, carriage unload,
carriage move to the next disk, carriage next disk load, carriage move,
optical drive load, and spin up takes about 12 seconds - "seek-from-hell".
<sect1>SCSI Changer Support for a Magneto Optical Jukebox Using "scsi-changer" - Jon Gerdes
<p>
<verb>
Some notes on firing up SCSI changer support for a Magneto Optical jukebox
using "scsi-changer"
==============================================================
LSM entry from distribution used:
Title: scsi-changer
Version: 0.14
Entered-date: 9 May 1998
Description: SCSI Media Changer device driver (for the robot mechanism
of MO/CD Jukeboxes, tape libraries, ...).
autofs support included. This is a BETA version.
Keywords: scsi jukebox changer driver
Author: Gerd Knorr <kraxel@cs.tu-berlin.de>
Maintained-by: Gerd Knorr <kraxel@cs.tu-berlin.de>
Primary-site: sunsite.unc.edu /pub/Linux/kernel/patches/scsi
22kB scsi-changer-0.14.tar.gz
627 scsi-changer.lsm
Alternate-site: none
Original-site: none
Platform: Linux
Copying-policy: GNU GPL
===============================================================
Latest version from here:
http://www.in-berlin.de/User/kraxel/linux.html
Tested on:
HP SurestoreOptical 40fx (1 drive 15x2.4Gb MO disks)
Adaptec 1520B (dodgy ISA 10MBs-1 SCSI II card)
Linux Mandrake 6.1
Kernel 2.2.13 and 2.2.14
tar -xzvf changer-0.14.tar.gz
read the README
Note that this program should work for most SCSI devices involving a robotic
picker and media slots.
patch kernel:
copy ch-2.2.7.diff to /usr/src/linux (ie kernel source)
patch -p1 < ch-2.2.7.diff
Compile in changer support to kernel:
make xconfig or menuconfig or just config
go to scsi section and tick changer support
put in NFS and automounter (see below) while you are at it.
If your using it as a module then add this to /etc/conf.modules:
alias char-major-86 ch
(no problems found using it as a module - recommended method of use)
run /usr/src/linux/drivers/MAKEDEV.sch (created by .diff) to create the
changer dev entries, one for the changer and one for the reader if you have
more than one reader, you will need more /dev/schx's (see
<src>/Documentation/devices.txt - again added by .diff)
Run make in the changer source directory
I had to copy scsi_ioctl.h to changer source directory and amend the Makefile.
Not sure why, so read and change the Makefile if compiler gives errors about
such a file not found (find /usr/src/linux -name <file_to_find> might be
handy)
copy binaries to /sbin (or /usr/sbin or whatever to taste)
mover load 0
fdisk /dev/sda (create sda1)
mke2fs -b 1024 /dev/sda1 1273011
mover unload 0
mover load 1
fdisk ...
etc
"mover mv d0 d0 1" will rotate disk in drive 1
etc etc
fdisk was OK but mke2fs had problems determining the correct geometry.
the number of blocks came from dmesg report hence specifying everything
explicitly - your mileage may vary. The block size was printed on the disks as
well as from "dmesg"
The above is crying out for a quick script to shuffle through the lot. mover
without switches will show the contents of the box.
make sure that scsi supports > 1Gb
on Adaptec 1520B - aha152x needs (in /etc/lilo.conf):
append="aha152x=0x340,10,7,1,1,0,100,1"
check source for meaning of parameters.
I also had a weird problem where the Adaptec driver appeared to caused Lilo
to forget much of the append= line - pretty esoteric but it may afflict
someone else. I had a Frame Buffer init string in there as well and after
swapping these around (ie SCSI bit first then the video bit it worked)
The adapter BIOS had to be adjusted slightly in the CTRL-A menu on boot to
also enable extended translation.
If the geometry is wrong then mke2fs will attempt to access incorrect
addresses. This causes the kernel to go absolutely mad, printing lots of
errors to the root console and filling up the system log. I had to use
shift-alt-sysreq-b to re-boot after synching disks, when I got it wrong :-(
My console was totally unusable with hundreds of messages scrolling up it. So
if this might happen to you, make sure that the "Magic Syskey" is enabled (see
kernel docs.) Alternatively do it in X from an xterm, that way you can kill
the job from another one ...
Now dig out the automounter (instructions in README). The devices are
/dev/sda1 and /dev/sdb1 (or similar) not the /dev/schx jobs. Remember to
have automounter and nfs support in the kernel. Attempting to cd /jukebox/0
will get the jukie to dig out the first disk and pop it into a spare drive and
even mount it.
Not sure what the problems I had were actually caused by. On boot the devices
were found and reported correctly but mke2fs wasn't going to play. I even
managed to wreck one side of my first MO disk so that even fdisk refuses to
play. You have been warned <g> Still I do have a ridiculously large amount
of filesystem space to play with at home.
Incidently, if you put a FAT f/s on a disk and leave it in the drive, then
Win98 can read it, if you happen to dual-boot (pah !)
Check the contents of the .diff file and the source itself - the author has
been pretty thorough with documentation.
Performance is not blistering but beats the heck out of a CDRW.
Finally, thanks to Mr Knorr for giving me an endless file system
Jon Gerdes - 17 January 2000
mailto:jon.gerdes@virgin.net
</verb>
<sect1> SCSI Changer Devices - Michael Heydenblut
<p>
Hi,
I have read your correspondance in the Optical Disk HOWTO. This
correspondance has been 2 1/2 years ago, so are you still interested in
jukebox specs?
I have the ANSI SCSI-II specs. Changer devices are described here.
Basically, changers are independent devices which respond to commands like:
Install disk in slot 7 in drive 2
Remove disk from drive 1 and store it in slot 13
Count all disks in the slots
and so on.
Btw. the SCSI specs make no differences between tape changers, od
jukeboxes, cd changers. These are all changer devices with the same command
set. The jukebox running under HP-UX seems to work differently from the
SCSI specs, where no LUNs for the slots/sides are defined. Three
possibilities:
1. LUNs for the disk sides are defined in SCSI-III specifications (I don't
know because I do not have them)
2. The jukebox and its driver is older than the SCSI specs, so the
manufacturer had to go its own way. This is the way my jukebox works, but
in my case the commands are similar.
3. The manufacturer choosed to ignore any specifications
Long time ago I have tried to make my jukebox work with linux. It worked
with the generic scsi driver /dev/sg*, some lines of C and a handful of
shell scripts, but I did not have the time (and knowledge) to build a real
kernel module from that.
There is still another problem: One has to write a new filesystem type for
write-once media. The ext2 filesystem can not be used because it writes
superblocks all over the disk and modifies them when data is written to the
disk. Sectors which have been written to are definitively lost. They can be
overwritten but in fact the new data is written to spare blocks and the old
data is discarded. This old data can be retrieved with special commands for
optical drives. There must be some kind of "append-only filesystem" to make
it really useful.
Greeting
Michael Heydenbluth
mh@heywei.de
<sect>Phase Change Optical Technology
<p>
<sect1>Introduction
<p>
Optical Phase Change technology is used to create "In Phase" or "Out of
Phase" bits on a special media for phase change writing. The drive uses a
LASER of different power levels or LASER intensities to produce this effect.
One power level allows the media to flow into a crystalline form while the
other creates an "Out of Phase" condition. The crystallized areas reflect the
read Lasers beam with a different coefficient of reflectivity than the
non-crystallized areas. Thus, data can be read from the disk.
<p>
What makes the phase change optical disk special is that it the disk is
formated with concentric cylinders or tracks with each track being sectored
much like a magnetic disk or read/write optical disk. The tracks are very close
so a lot of data can be stored on a disk. This is different from a CD-ROM in
that it gives your system the look and feel of a magnetic disk. CD-ROMs
have a spiraling track much like a audio record. Having tracks and sectors
alone would not make the phase change drive special from optical disk but the
drive has some very special properties; The phase change drive allows for
direct overwrite of data which magneto optical can't do inexpensively and the
media has the very special property of NOT being susceptible to magnetic
fields or as sensitive to static discharge which gives the media a very long
shelf life.
<sect1>Panasonic LF1000
<p>
<sect2>POINTS OF INTEREST
<p>
<itemize>
<item> Read/Write optical disk.
<item> Can read CD-ROMs at 4X speed.
<item> Can read Kodak PhotoCDs.
<item> Media has a 15 Year shelf life.
<item> SCSI-2 Interface.
<item> Track/sector format as opposed to CD-ROMs spiraling record format.
<item> 165ms access time - much better than a tape file restore.
<item> 650Mb data storage per diskette.
<item> Diskettes are about &dollar;50 each.
</itemize>
<sect2>THINGS YOU SHOULD KNOW
<p>
<itemize>
<item>Optical disk format not compatible with any other disk drive.
<item>Vendors don't seem to support UNIX very well - marketing is
targeted for DOS/Windows and Macintosh.
<item>Do NOT purchase the PD drive which uses the parallel port
interface - To my knowledge there is no Linux driver for it.
<item>There has been some reports of SCSI DID resets using this
drive with Adaptec 1542C cards. It was reported that upgrading
to a 2940 card fixed this problem.
</itemize>
<sect2>Installation
<p>
The LF1000 is SCSI-2 compatible device. It features a block size of 512 bytes
and is compatible with the Linux SCSI drivers. This drive was installed on a
PC compatible AMD 100MHZ 486 with an Adaptec 1542C SCSI bus-master
controller. To install and mount a disk the following steps were taken;
<sect2>Installation steps
<p>
<itemize>
<item> Install the drive and set the SCSI address to not interfere with other
SCSI devices. Reconnect all cabling.
<item> Boot the computer. Your SCSI controller should note the new drive.
<item> During the Linux kernel boot, you should see an additional SCSI
device. In my case, having a magnetic system disk for device /dev/sda
it shows up as /dev/sdb.
<item> I did NOT partition the device because fdisk issued an overwrite
warning and I did not want to change anything from a dosemu
standpoint.
<item> mkfs -t ext2 /dev/sdb
<item> mkdir /pd
<item> mount -t ext2 -o ro,suid,dev,exec,auto,nouser,async /dev/sdb /pd -
Read only
<item> mount -t ext2 -o defaults /dev/sdb /pd - Mount drive W/R
</itemize>
<em/Your ready to "Rock'n'Roll"/
<sect2>Usage hints
<p>
<itemize>
<item>The media which comes with the drive is reported be re-writable about
500,000 times. This means that it is not advisable to install a live operating
system such as Linux on the phase change optical drive. These live operating
systems tend to cache processes to and from disk. Over time this can easily
approach the phase change media life.
<item>Mount drive read only as much as possible.
<item>When writing to the drive do so in large chunks. This will help
reduce any file fragmentation which will require more read seeks.
<item>This is however an excellent media for backups, gifs, mpeg or storing
large programs which you don't use that often. The restore from backup is much
faster that tape. Backups can be performed using the cp -rp command without
the need for the ftape driver. This however, will replace symbolic links with
the actual file.
<item>If while using the PD for writing, You find that the file you just
wrote to the disk are not there, chances are that the disk write
protect tab is in write protect mode and you mounted it in read/write mode.
</itemize>
<sect1>Additional Configuration concerns by Jeff Rooze
<p>
Hello,
I read your article on configuring the Panasonic LF-1000 for
Linux. I have configured my system so that the optical drive
has its own device name and the CD-ROM has its own device name.
This has allowed me to mount either media at any time. I do not
require any media in the drive when I boot Linux. Also I am using
the optical drive as an ext2 formatted media.
<p>
I had a couple of minor difficulties in doing so.
<p>
First, I had configured my hard drive at SCSI ID 6 and my PD
at SCSI ID 4. (I wanted to have the hard drive at a higher priority
that the PD). This caused a problem with the Linux SCSI driver. The
driver scans the SCSI devices from the Lower SCSI id's to the higher
(eg: 0 .. 6). Consequently my logical device names were assigned
differently depending on which type of media was installed in the
PD drive. This caused a big problem. My Linux partition is on my
SCSI hard drive and the root device name would change! I corrected
this problem by modifying the software in the kernel SCSI driver to
scan the devices in reverse order.
<p>
Second, the distribution Linux kernel does not scan all SCSI LUNS.
The PD/CD drive has a mode that establishes the CD-ROM at LUN 1 and
the PD at LUN 0. This mode is selected by the configuration switches
on the PD/CD drive. Switch &num;2 should be down (off?). If this switch
is up (on?), the signature of the device is dependent upon the media
that is installed and it only reports this device on LUN 0. If no
media is installed I think it defaults to CD-ROM.
I am using an Future Domain 16-xx SCSI interface card and the
software in Linux kernel driver supports an optical device signature
when scanning the LUNS. I assume that this is standard for most of
the SCSI drivers. I reconfigured the kernel to enable the "scan all
LUNS" switch. The kernel then assigns different device names for each
device. The following is an excerpt from by boot log. You will note a
series of errors in this log. This is because I did not have the
optical media installed in the drive and the driver was attempting to
look at the partition table to determine the block size. Fortunately
it defaults to 512. I am planning on modifying the Future Domain SCSI
driver to not do this when it detects the optical device.
<tscreen><verb>
> scsi0 <fdomain>: BIOS version 3.2 at 0xde000 using scsi id 7
> scsi0 <fdomain>: TMC-18C50 chip at 0x140 irq 12
> scsi0 : Future Domain TMC-16x0 SCSI driver, version 5.28
> scsi : 1 host.
> Vendor: CONNER Model: CP30545 545MB3.5 Rev: A9AF
> Type: Direct-Access ANSI SCSI revision: 02
> Detected scsi disk sda at scsi0, id 6, lun 0
> Vendor: MATSHITA Model: PD-1 LF-1000 Rev: A109
> Type: Optical Device ANSI SCSI revision: 02
> Detected scsi disk sdb at scsi0, id 4, lun 0
> Vendor: MATSHITA Model: PD-1 LF-1000 Rev: A109
> Type: CD-ROM ANSI SCSI revision: 02
> Detected scsi CD-ROM sr0 at scsi0, id 4, lun 1
> fdomain: Selection failed
> scsi : detected 1 SCSI cdrom 2 SCSI disks total.
> SCSI Hardware sector size is 512 bytes on device sda
> fdomain: REQUEST SENSE Key = 2, Code = 3a, Qualifier = 0
> last message repeated 3 times
> sdb : READ CAPACITY failed.
> sdb : status = 0, message = 00, host = 0, driver = 28
> sdb : extended sense code = 2
> sdb : block size assumed to be 512 bytes, disk size 1GB.
> .
> .
> .
> Partition check:
> sda: sda1 sda2 sda3
> scsidisk I/O error: dev 0810, sector 0
> unable to read partition table of device 0810
</verb></tscreen>
<p>
Third, I modified my file system table (/etc/fstab) to list each
device but do not attempt to auto mount when booting. I have
included an excerpt from my fstab. The most important options
are the noauto, rw(ro), and the checkpass flag.
<p>
To create a ext2 file system on the PD, I used the command
"mkfs.ext2 -i 2048 /dev/sdb".
<tscreen><verb>
# fstab - List of file systems
#
# device mount type options dumpfrequency
checkpass
/dev/sdb /optd ext2 rw,user,suid,noauto,sync,exec,dev,umask=0 0 2
/dev/sr0 /dist iso9660 ro,user,suid,noauto,sync,exec,dev 0 2
</verb></tscreen>
<p>
After making these changes, I have had no problems with mounting
either media. All I need to do is to load the media and type
"mount /optd" or "mount /dist" and the system does all the rest.
<p>
I hope this information is useful.
<tscreen><verb>
Jeff
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\ Jeff Rooze -- http://www.treknet.net/~jrooze -- jrooze@treknet.net /
/ If builders built buildings the way some programmers write \
\ programs, then the first woodpecker that came along would destroy /
/ civilization. GERALD WEINBERG \
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
</verb></tscreen>
<p>
I tried Jeff's suggestion. Here are the steps I performed;
<itemize>
<item>Modify my kernel using "make xconfig" in the /usr/src/linux directory
and installed it.
<item>Change the mode jumper on the PD drive to non-DOS mode. I soldered
a switch across the mode jumper connections and routed it the the
back panel. I figured out which switch position was the open position
and labeled this one for DOS. The other position is of course Linux.
So before I boot my system I decide which OS I'll be using and set the
switch accordingly. History shows it staying in the Linux position
more and more.
<item> Reboot your system. You should now see multiple LUN show up
during boot for the PD SCSI device number - It works great!!! If you have
an older kernel modify the "/usr/src/linux/drivers/scsi/config.in" file.
<item>Update the fstab for both CD and PD drives.
<item>Use appropriate mount command.
<item>"df" to make sure your ready.
</itemize>
I did try moving my primary SCSI drive to 6 but experienced some
difficulties. Can't remember exactly what it was but it may have
been that my controller "Adaptec 1542" with "Corel SCSI" requires a
bootable disk and SCSI 0 for the BIOS install to work properly with
DOS. So I switched it back and enjoyed playing with my properly
install PD drive! With this configuration "workman" - the audio
CD player util - works fine.
</article>