Re: Non-RW media; WORM hopes
Gustavo Guillermo Pérez <[email protected]> Sat, 16 Jun 2007 11:15:50 -0500
| Newsgroups | gmane.linux.suse.packet-writing |
|---|---|
| Organization | www.compunauta.com |
| Message-ID | <[email protected]> |
El S=C3=A1bado, 16 de Junio de 2007, RB escribi=C3=B3: > > Again, you can not put a udf filesystem on it. You need to use cdrwtool > > to only format the track, which I believe was the -m option. > > I wish I had good news... Reading through the source of cdrwtool > (udftools-1.0.0b3) and using strace, I'm able to follow the execution > of '-m' up to the point that it actually tries to send the packet > containing the format to the CD (cdrwtool.c:424), which fails > immediately with a return value of EIO. I thought it was the fact > that cdrwtool.h tries to reference HZ in it's timeouts, but hardcoding > those to sane values did nothing for me. In three different drives > from three different manufacturers, I get the following with virgin > Imation CD-R media: > > [root@tst ~] cdrwtool -d /dev/hdc -m 359846 > using device /dev/hdc > formatting 359846 blocks > 1751KB internal buffer > setting write speed to 12x > wait_cmd: Input/output error > Command failed: 04 17 00 00 00 00 00 00 00 00 00 00 - sense 05.30.06 > format disc: Illegal seek > > Afterwards, using 'cdrwtool -i' the discs then [usually] show 295264 > free blocks, as opposed to the prior 359846, but 'dd if=3D/dev/zero > of=3D/dev/hdc bs=3D32k' gives EROFS and fails. I swear I see a 'dotted' > burn just around the center of the media (inside the area usually > burned during fixation), but the usually visible "ring o' death" I've > seen after my 'cdrecord --packet' experiments is not evident. Since when you can write directly over a cd, without executing ATA commands= ?. > I've got ide-cd.ko and cdrom.ko compiled with all the debugging > options turned up, but don't see anything in the kernel logs that give > me any indication as to why it's failing. The sense failure is as > cryptic as anything, and while I'm sure the 0x17 command is > significant (0x10, or '1 << 4' seeming to be IMMED), the 0x07 portion > seems like a magic number - I guess it came out of one of the rainbow > books, but none of the source documents it. I'm learning kernel code > as I go here, so somebody smack me if I'm being dumb. Any other > ideas? > > > > RB =2D-=20 Gustavo Guillermo P=C3=A9rez Compunauta uLinux www.compunauta.com