Magneto optical drives use a "Far field" magnetic field and a laser to change polarization of a magnetic media. The media is of such a nature that it must be heated to the appropriate temperature before a polarization change can happen - this is where the laser comes into play. 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. After a short period of time the disk surface cools and "locks" the polarization into place. The read back I'm a little fuzzy on - someone please send me the proper wording. I think a low power laser is used for read back and the "H" field of the disk polarization interacts with the "E" and "H" field of the incident laser to produce a reflective polarization which will correspond to the disk bit polarization - I hope this is in the ball-park, it's certainly no home run. Maybe a total strike out.
The use of a laser for polarization change allows the disk bit and track densities to be higher than 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. Most media allows 650 Megs per platter and on some models both sides of the media is used yielding 1.3Gig storage media - you must remove the media and flip it over to use the other 650Megs though.
Stephan Shuichi Haupt <firstname.lastname@example.org>
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 email@example.com 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 firstname.lastname@example.org 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 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 email@example.com 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 (firstname.lastname@example.org) 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.
Закладки на сайте
Проследить за страницей
Created 1996-2023 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру