[Debian-uk] Linux Expo?

Charles Briscoe-Smith charles at briscoe-smith.org.uk
Fri, 4 Oct 2002 19:17:42 +0100


On Fri, Oct 04, 2002 at 04:02:57PM +0100, Philip Hands wrote:
> I was only thinking of getting 2 drives per chasis in, and reading the
> images over the network, so only 2 IDE busses would be kept busy, rather
> than making a monster 7 CD burner.

So many ways to skin a cat... :)

> Well, if we're choking our write speed, we could actually check them
> faster than we're writing them, but I take the point.

Disks can be verified in a different drive while writing continues.
It increases the latency of the process, but, with separate hardware,
doesn't slow the overall rate of production.

> It's just that I happen to have 2000 of the blanks in question, waiting
> for a client, and apparently he only needs 500 by next week, so we can
> use as many of the remaining 1500, and replace them, with no risk of
> being lumbered with them.

Seems a reasonable idea.  I think (but I didn't keep records) the
bad unbranded disks I've had were all one particular make: Multimedia
Masters & Machinery.  (I'm not buying any more of them if I can help it.)
If my memory is correct, those Intenso blanks are made by ProDisc, and I'd
suspect the unbranded ones would be too (second guess would be Ritek).
Although I'd want to check ProDiscs and Riteks after writing them,
I'd be surprised if we had any failures.

How about: write the disks, then use a machine with 2 fast CD readers
to verify them.  Have it identify the disks (.disk/info) and queue up
appropriate labels to print, then verify the disks (md5sum < /dev/cdrom)
while the labels are printed.  (2 disks at a time because labels come 2
per sheet.)  This saves having to keep track of which disks are where;
we take the two disks from the verifier and stick on the waiting labels.
(Now that I've had the idea, I'm going to script this up for my own
use anyway.)

BTW, I use cdrdao to write Debian CDs, which is how I can verify the
disks by redirecting md5sum's input from the CD device.  With cdrecord I
wouldn't be able to do that because of the unreadable blocks you get at
the end of TAO tracks.  FYI, the cdrdao .toc files look like this:

CD_ROM
TRACK MODE1
DATAFILE "debian-30r0-i386-binary-1_NONUS.iso"

I get the impression that DAO recording is slightly quicker than TAO, too.

> Their other named brands don't seem to be competitive with your 24p
> price.  The unbranded ones claim to be good up to 40x, whereas Memorex
> and Samsung are only claiming 24x

If we're recording at below 24x, the only difference made by the differing
ratings is in credibility, IMO.

If we're verifying anyway, we may as well use the unbranded disks you
have on hand.

I don't know which to do.  I was expecting to buy some good disks,
turn up with a couple of CD burners and images and help make disks
for people.  If we're going to build a big distributed CD writing farm,
that's somewhat different...

Alternative idea: if Steve has an appropriate quantity of CD-Rs in his
posession, would he be willing to have Wookey bring some along?  That'd
have the same advantages as using Phil's stock (use what we need and
replace them afterwards) but gets us disks we shouldn't need to verify.

-- 
Charles Briscoe-Smith             Hacking Free Software for fun and profit
Do you still use counterfeit vowels?  -- Dilbert, 27 September 2002