[9fans] scuzz doesn't like CD-RW?

[9fans] scuzz doesn't like CD-RW?

[cej]

hi,

scuzz (even this friday's pull, compiled from source) seems to hate CD-RW's, with this error message:
       bus timeout

the drive is CD-RW/DVD-R, and everything goes ok on linux.
i would like to burn raw tarfile to /dev/sdD0/data.      
       
any hint appreciated,
thanks, regards,

 ++pac

Re: [9fans] scuzz doesn't like CD-RW?

[geoff]

Are you using CD-R or CD-RW media?  Have you tried "scuzz -r
/dev/sdD0"?

I've just hooked up a CD-R drive so I'll verify that that still works.

Re: [9fans] scuzz doesn't like CD-RW?

[geoff]

I just burned a CD-R using a SCSI drive and cdfs.

I don't think I normally use scuzz to talk to CD drives, but

	scuzz -r /dev/sd11
	ready
	inquiry

works.

RE: [9fans] scuzz doesn't like CD-RW?

[cej]

I can also burn ISO CD-RW on plan9 with that drive, I forgot to mention it.
The problem is that I can§t burn a tar file directly, i.e., without cdfs,
so I could read it thus:
tar tvf /dev/sdD0/data

aftr blanking the cd, I got rid of that 'bus timeout' message,
probe
ready
inquiry
rewind 

all work, but I still can't write

My problem is that I don't trust ISO-9660 and companion very much.
writing .tar instead of .iso using cdfs would probably work, but would force me to use the cdfs overhead. 

Reasoning is that if something goes wrong, I can get most of the data back from tar, not so from iso.

Thanks for the response,
best regards,

 ++pac


-----Original Message-----
From: 9fans-bounces+cej=gli.cas.cz@cse.psu.edu [mailto:9fans-bounces+cej=gli.cas.cz@cse.psu.edu] On Behalf Of geoff@plan9.bell-labs.com
Sent: Monday, October 09, 2006 8:34 PM
To: 9fans@cse.psu.edu
Subject: Re: [9fans] scuzz doesn't like CD-RW?

I just burned a CD-R using a SCSI drive and cdfs.

I don't think I normally use scuzz to talk to CD drives, but

	scuzz -r /dev/sd11
	ready
	inquiry

works.

Re: [9fans] scuzz doesn't like CD-RW?

[Bruce Ellis]

the tar is not keeping up with your drive. slow it down or tar to
a raw partition, which is as fast a feed as you'll get.

brucee

On 10/10/06, cej@gli.cas.cz <cej@gli.cas.cz> wrote:
> I can also burn ISO CD-RW on plan9 with that drive, I forgot to mention it.
> The problem is that I can§t burn a tar file directly, i.e., without cdfs,
> so I could read it thus:
> tar tvf /dev/sdD0/data
>
> aftr blanking the cd, I got rid of that 'bus timeout' message,
> probe
> ready
> inquiry
> rewind
>
> all work, but I still can't write
>
> My problem is that I don't trust ISO-9660 and companion very much.
> writing .tar instead of .iso using cdfs would probably work, but would force me to use the cdfs overhead.
>
> Reasoning is that if something goes wrong, I can get most of the data back from tar, not so from iso.
>
> Thanks for the response,
> best regards,
>
>  ++pac
>
>
> -----Original Message-----
> From: 9fans-bounces+cej=gli.cas.cz@cse.psu.edu [mailto:9fans-bounces+cej=gli.cas.cz@cse.psu.edu] On Behalf Of geoff@plan9.bell-labs.com
> Sent: Monday, October 09, 2006 8:34 PM
> To: 9fans@cse.psu.edu
> Subject: Re: [9fans] scuzz doesn't like CD-RW?
>
> I just burned a CD-R using a SCSI drive and cdfs.
>
> I don't think I normally use scuzz to talk to CD drives, but
>
>        scuzz -r /dev/sd11
>        ready
>        inquiry
>
> works.
>
>

Re: [9fans] scuzz doesn't like CD-RW?

[Charles Forsyth]

i sometimes put the contents for the cd in ramfs -p (if there's enough physical memory).
in any case, i find that
	sourceofimage | dd -obs 32k | dd -bs 32k >/mnt/cd/wd/blat
works well, with one dd to collect to a good block size, and another to double buffer
through the pipe.

RE: [9fans] scuzz doesn't like CD-RW?

[cej]

do you mean i can tar cf foo > /dev/sdD0/raw ??
would be great!

++pac

>

RE: [9fans] scuzz doesn't like CD-RW?

[Charles Forsyth]

> do you mean i can tar cf foo > /dev/sdD0/raw ??
> would be great!

i thought the suggestion was to buffer the tar image in a free partition on a normal drive,
then copy (eg, with dd) from there (but you'd need to get the count right).

RE: [9fans] scuzz doesn't like CD-RW?

[Charles Forsyth]

> i thought the suggestion was to buffer the tar image in a free partition on a normal drive,

the reason being that tar has to go off to fetch the data, which might
take more time than the cdrw is willing to grant.

RE: [9fans] scuzz doesn't like CD-RW?

[Charles Forsyth]

yet another point about cdrw: it's often sensible to reduce the
writing speed.  first, it gives the data source more time to provide
the data.  second, i've found i stand a better chance of reading it
on any old cd (not just the one that wrote it).

Re: [9fans] scuzz doesn't like CD-RW?

[Bruce Ellis]

exactly, slow it down as previously suggested.

it's far to optimistic.

brucee

On 10/10/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> yet another point about cdrw: it's often sensible to reduce the
> writing speed.  first, it gives the data source more time to provide
> the data.  second, i've found i stand a better chance of reading it
> on any old cd (not just the one that wrote it).
>

RE: [9fans] scuzz doesn't like CD-RW?

[geoff]

Depending on the drive, you may also need to write multiples of 2048
bytes, padded if necessary.  tar writes multiples of 512 bytes, so
using dd to pad it might be necessary.  Even then, if you write
directly to /dev/sdD0/data, you'll need to fixate (close) the disc.

I'm not sure what there is to fear about iso 9660 format.  It doesn't
encrypt your data and files tend to be written contiguously (I'm not
sure if that's required by the format or just a good idea to make
reading faster), so digging the data out by hand shouldn't be
difficult if suddenly all the world's 9660-reading programs stopped
working.

Note that using cdfs doesn't imply use of 9660 format, and using cdfs
would take care of fixating the disc at least.

Re: [9fans] scuzz doesn't like CD-RW?

[Paweł Lasek]

On 10/10/06, geoff@plan9.bell-labs.com <geoff@plan9.bell-labs.com> wrote:
> Depending on the drive, you may also need to write multiples of 2048
> bytes, padded if necessary.  tar writes multiples of 512 bytes, so
> using dd to pad it might be necessary.  Even then, if you write
> directly to /dev/sdD0/data, you'll need to fixate (close) the disc.

Typical drives accept only 2048 bytes/sector (or variations for
certain types of recording where you write not only data but also have
to supply all that additional data which makes CD a 700 MB instead of
full 1 GB :>).

IIRC 2048 b/s is standard sector size for data in CD-ROM standard

>From what I know, drives supporting 512 bytes/sector are mostly (If
not only) SCSI (and similar, although I don't think anybody made
FiberChannel CD-RW ;-) ) drives.

On such drives you can find additional jumper which sets either 512 or
2048 bytes per sector. Example of such drive is Yamaha 16x4x4 Fast
SCSI-II CD-RW. AFAIK the only system which requires such setting is
VMS, which uses only 512 mode. I'm not sure, but I think that
specification doesn't have option for switching sector size on the fly
and propably has fixed data structures which break if incompatible
modes are selected.

> I'm not sure what there is to fear about iso 9660 format.  It doesn't
> encrypt your data and files tend to be written contiguously (I'm not
> sure if that's required by the format or just a good idea to make
> reading faster), so digging the data out by hand shouldn't be
> difficult if suddenly all the world's 9660-reading programs stopped
> working.

As long as nobody starts to put important data in subchannels or uses
some of the wierder aspects of ISO9660 (Multiple disk filesystems? Is
there any program which is capable of making those at all??). Most
common, single session CD's have metadata at the beginning, then
files. Multi-session add pointer for 'updated descriptor' or something
like that which is address of next descriptor in chain (next session).

At least I think it should be much easier to decode (as long as it's
pure-data track, without any subchannel craziness) than NTFS (which,
to my big surprise, was much easier to decode by hand than ext2....).

-- 
Paul Lasek

Re: [9fans] scuzz doesn't like CD-RW?

[Martin Neubauer]

* Pawe?? Lasek (pawel.lasek@gmail.com) wrote:
> On 10/10/06, geoff@plan9.bell-labs.com <geoff@plan9.bell-labs.com> wrote:
> >Depending on the drive, you may also need to write multiples of 2048
> >bytes, padded if necessary.  tar writes multiples of 512 bytes, so
> >using dd to pad it might be necessary.  Even then, if you write
> >directly to /dev/sdD0/data, you'll need to fixate (close) the disc.
> 
> Typical drives accept only 2048 bytes/sector (or variations for
> certain types of recording where you write not only data but also have
> to supply all that additional data which makes CD a 700 MB instead of
> full 1 GB :>).
> 
> IIRC 2048 b/s is standard sector size for data in CD-ROM standard

Actually, the sector size is 2352 bytes, 2048 of which is data. The rest is
mainly for error correction (which is vital for data and not needed for
audio).

RE: [9fans] scuzz doesn't like CD-RW?

[cej]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

Wow! Yup! Yummmm..!
 
Yep, I used cdfs to cp foo /mnt/cd/wd, fixed the cd, and cat /dev/sdD0/data gave me the file! (I thought that cdfs is bound somehow to 9660... so i tried to use scuzz.) 
Thanks to all who responded. Now i'm going to try the same with DVD disc. Hopefully, the 2GB limit is gone...
 
Regards,
++pac.
 

 

[-- Attachment #2.1: Type: text/plain, Size: 292 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: application/ms-tnef;
	name="winmail.dat"
	Content-Transfer-Encoding: base64

[-- Attachment #2.2: winmail.dat.suspect --]
[-- Type: application/octet-stream, Size: 3426 bytes --]