Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!uunet!xstor!iverson
From: iverson@xstor.com (Tim Iverson)
Newsgroups: comp.periphs.scsi
Subject: Re: SLOW WRITE ON OPTICAL ERASABLES
Keywords: media, flaws, defects, format, optical
Message-ID: <1991Jun28.183539.22508@xstor.com>
Date: 28 Jun 91 18:35:39 GMT
References: <1080@camco.Celestial.COM> <1991Jun15.173019.27914@scuzzy.in-berlin.de> <1991Jun25.160859.16313@murdoch.acc.Virginia.EDU>
Reply-To: iverson@xstor.com
Organization: Storage Dimensions, Inc.
Lines: 55

In article <1991Jun25.160859.16313@murdoch.acc.Virginia.EDU> sdm7g@Virginia.EDU writes:
>In article <1991Jun15.173019.27914@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes:
>>bill@camco.Celestial.COM (Bill Campbell) writes:
>>to write a block, it takes at least one full revolution + 1 block
>>of the disk. on average 1.5 revolutions are needed, which causes
>>the slow writing you experienced.
>
>It also depends on whether the driver is doing a WRITE/VERIFY on 
>all writes. ( This SHOULD be the DEFAULT, but it is slower. ) 

Yes, but that's not all you need.

>disk. If a write verify is done, then a read is performed using only
>half of the error-correcting code capability. If it can be read, that
>ensures that you still have some head-room in the ECC to protect you
>from future data loss. If it gets an error on read, then a replacement
>block is allocated and written, and the bad block is entered into the
>Secondary Defect List.

Sounds like you're talking about the Sony MO.  Note, that reallocation
won't happen unless the AWRE bit (automatic write reallocation enable)
is set.  I'm pretty sure it is not on by default.

Also, this definitely does not happen on a MaxOptix Tahiti.  Failure of the
verify pass and AWRE does not cause a reallocation.  I don't know about
other MO's, but this is an area in which many drives are a little bit
squirrelly - they toe the line in name, but not in fact.  Check your drive
documentation to be sure before relying on this method.

>this off. If you intend it to be used for Archival Data Storage, you 
>should be using the WRITE/VERIFY. 
>Pinnacle's disks for MS_DOS DO NOT do WRITE/VERIFY. ( They were more 
>interested in improving their performance specs, than in keeping your data! ) 

Small plug: Storage Dimensions does enable verify after write by default for
MO devices (user selectable for all devices).  We also handle the reassigns
(they happen, but very infrequently) by hand; i.e. the driver turns off
AWRE, fields the error, and issues the reassign itself.  This way your data
stays healthy even if Rocky & Bullwinkle designed the device's AWRE code.

> I am going to try to prepare a horror story (posting) about what can
> happen to you with improperly formatted MO media. The contents of my disk

Actually, the worst problem isn't formatting - good software can solve that
one - it's contamination (dust).  If you leave your cartridge in the drive
when you turn it off (or even when on but not in use), the metal jacket
stays open and dust collects.  This causes read/write failures that really
shouldn't fail, which causes blocks to be reassigned that don't need to
be.  Pretty quickly, you'll run out of spares and then you're SOL.

Keep your cartridges clean folks!  Software can't fix this problem for you.


- Tim Iverson
  iverson@xstor.com -/- uunet!xstor!iverson