Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Jul 2002 00:17:08 -0400
From:      Chuck McCrobie <mccrobie@cablespeed.com>
To:        "J. Kanowitz" <jkanowitz@snet.net>
Cc:        freebsd-scsi@freebsd.org
Subject:   Re: OT: Magneto-Optical formatting, partitioning, 2940UW quirks?
Message-ID:  <3D2FA9C4.68633583@cablespeed.com>
References:  <3D2FA699.8030807@snet.net>

next in thread | previous in thread | raw e-mail | index | archive | help
"J. Kanowitz" wrote:
> 
> I know this is likely not the best list, but where else am I going to
> find people who've actually encountered MO systems in practice, eh?
> 
> In my case, I'm fighting with a Fujitsu M2512A.  Dated by modern
> standards, yes, but at $2/ea off eBay, I'm rather happy about the pile
> I've picked up.  The main 'problem' I've got has nothing to do with
> SCSI, but rather, the bizarre partitioning and formatting buzzwords
> developed by Fujitsu and the MO consortium.  I'd like to get some
> feedback from someone else using the critters, to know if any of what
> I've guessed is accurate.
> 
> Basically, it sounds like there are 3 ways to partition and format an MO
> disk; "NSR," which appears to be the spec whence UDF springs, and
> amounts to UDF plus a proscribed partitioning scheme I've yet to
> understand, "SuperFloppy" - which may or may not amount to newfs_msdos
> /dev/da#c, and something I've forgotten the TLA for, which amounts to
> creating a regular x86-style? partition table, and formatting the
> partition as desired.  The "mo230" entry in /etc/disktab seems to mesh
> with the last point; luckily, these M2512s seem to be what IBM rebadged
> as the MTA-3230, or I wouldn't have gotten that far.
> 
> Now, sadly, all the noob-documentation for this sort of thing seems to
> be 1. in Japanese, and 2. written for 3.x.  I'm not as stupid as I sound
> here, but I put aside the partitioning/formatting headache for a while,
> and now it's biting me as I run out of space on my main disks.  (Yes,
> I'm broke, so no shiny new 80gbs for me.)
> 
> There are 2 main tasks that likely anyone with an MO would like to
> perform, these are:
> 
> 1. Partitioning and formatting a sane and optimized UFS for personal
>     storage, and..
> 2. Partitioning and formatting a proper FAT for interoperability with
>     Windows and other systems, especially until UDF support trickles into
>     releases.
> 
> If anyone knows about any aspect of this- what's "accepted practice" in
> terms of format on consumer-grade MO, is the mo230 entry still "the
> right thing" for UFS use, what does Windows produce/expect to see when
> an MO's formatted with its built-in support?- I'd be much appreciative,
> and be glad to try to congeal all this into a FAQ or HOWTO when I'm
> done.  (For the record... I'm no stranger to partitioning, but I *am* a
> cluebie when it comes to UFS/FFS-the-filesystem.)
> 
> ---
> 
> While I'm at this, I do notice one small, unusual SCSI behavior with the
>   MO drive hooked up.  My small mess of a setup consists of the following:
> 
> FreeBSD obie 4.6-RC FreeBSD 4.6-RC #0: Thu May 30 22:35:22 EDT 2002
> floid@obie:/usr/obj/usr/src/sys/OBIE  i386
> 
> ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xe800-0xe8ff mem
> 0xd9000000-0xd9000fff irq 11 at device 9.0 on pci0
> 
> da2 at ahc0 bus 0 target 3 lun 0
> da2: <FUJITSU M2512A 1510> Removable Optical SCSI-2 device
> da2: 5.000MB/s transfers (5.000MHz, offset 8)
> da2: 217MB (446325 512 byte sectors: 64H 32S/T 217C)
> 
> da1 at ahc0 bus 0 target 1 lun 0
> da1: <SEAGATE ST32272W 0876> Fixed Direct Access SCSI-2 device
> da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing
> Enabled
> da1: 2157MB (4419464 512 byte sectors: 255H 63S/T 275C)
> 
> da0 at ahc0 bus 0 target 0 lun 0
> da0: <SEAGATE ST32272W 0876> Fixed Direct Access SCSI-2 device
> da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing
> Enabled
> da0: 2157MB (4419464 512 byte sectors: 255H 63S/T 275C)
> 
> ...it seems that, even when booted into DOS, having the MO drive on the
> chain causes the two Seagates to give a small "chug" once every 30
> seconds or so- not in perfect sync, but on a fairly regular basis.  The
> bus activity LED doesn't flash, at least not visibly- the 2940UW doesn't
> quite put out enough current for the LED in my case, so it's fairly dim
> unless I'm doing sustained activity.
> 
> I don't get any errors on the FreeBSD console, nor am I losing any data
> or really suffering for performance, so I'm not concerned enough to have
> tried to chase the issue down... but anyone want to make a guess for the
> sake of it?
> 
> --
> 
> Hope I haven't distracted anyone for too long from their day jobs; I
> *know* this is about the most malformed way to post on a list, but I'm
> burnt out and at least hoping I can find an MO guru to have educated
> conversation with.
> 
> CCs are appreciated, as are private responses if this is as OT as I
> think it is.
> 
> -Thanks!
> -Joe Kanowitz
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-scsi" in the body of the message

The low level SCSI format (SCSI command "4") is just like any other
magnetic disk - let the drive handle it.  On some MO drives, one could
specify a different low level format.

What you're talking about is the file system / partitioning scheme to
lay out on the disk.  You can do this in many ways, depending on what
you want to do ;)  You could put UFS on the entire disk using /dev/da2c
- or make a "true" disklabel with an "a", "d", "e", etc. partition and
newfs each one individually.

I tend to treat one surface as one file system, so I newfs all my MO
media using the "c" partition.

Note, with UDF, you can have one and only one Unix partition - UDF
expects the "super-blocks" (AVDP's in UDF parlance) to be written at
block 256, n-256, and n (where n is the last addressable block on the
surface).

I suppose one can "newfs_msdos" after doing "fdisk" on the surface. 
Given the write-state of UDF on various platforms, if you want to
"transport" the media between lesser machines and write to it with those
machines, FAT may be your best bet.

Chuck McCrobie
mccrobie@cablespeed.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D2FA9C4.68633583>