Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD

[Thomas Schmitt]

Hi,

indeed, the CD-RW log looks ok.

The DVD-RW attempt using write type DAO died after the second WRITE command.
Again we see the suspicious Sense code 2,0,0, which says "not ready" and
"all seems well" at the same time.

--------------------------------------------------------------------------
Test proposals:

- Try whether cdrecord -VV can write the DVD-RW after blank=fast.
  (Catch the -VV log for the case that it works and that i need to compare
   with libburn's doings.)

- Try whether -as cdrecord option -tao brings better results on a
  thoroughly blanked DVD-RW:

     xorriso -outdev /dev/rcd0c -blank deformat

     xorriso -scsi_log on -as cdrecord -v -tao dev=/dev/rcd0c /home/uaa/install

  (This blanking lasts as long as a full 4 GB burn run.)
  (Note the difference between "-dao" and "-tao". Actually "-tao" on DVD-RW
   triggers write type "Incremental".)

- Try whether xorriso writes on formatted DVD-RW

     xorriso -outdev /dev/rcd0c -format as_needed

     xorriso -scsi_log on -as cdrecord -v dev=/dev/rcd0c /home/uaa/install

  (Formatting lasts as long as a full 4 GB burn run.)
  (Options -tao and -dao would make no difference here.)

--------------------------------------------------------------------------

If i had known that you make tests with DVD-RW i would have prepared you
for the multiple personalities of medium and xorriso.

- DVD-RW can either be sequential unformatted or overwritable formatted.
  Unformatted can be in "fully" blanked state and then is capable of taking
  multiple sessions by write type "Incremental". In "fastly" blanked
  state a DVD-RW can only take a single session by write type "Disk-At-Once"
  (DAO).
  Formatting has to be done only once. The medium stays overwritable until
  it gets deformatted by a SCSI command BLANK.

- xorriso in its main personality considers formatted DVD-RW with an ISO 9660
  filesystem as appendable, because it can read the ISO and add a session.
  Its command -blank may be used to invalidate the ISO filesystem and let
  xorriso consider the medium "blank" afterwards.

- xorriso -as cdrecord considers a formatted DVD-RW as blank, because it
  can be written from scratch without previous blanking.
  Its option blank=fast will therefore do nothing with a formatted DVD-RW
  and it is ready to write a data stream to the DVD-RW beginning at block 0.

  Its options blank=deformat and blank=deformat_quickest can bring a
  formatted DVD-RW into "fully" or "fastly" blank state.
  (blank=deformat lasts as long as a full 4 GB burn.)

- cdrecord hates both: formatted DVD-RW and write type "Incremental".
  Therefore it blanks formatted DVD-RW by blank=fast so that they only
  can take a single DAO session.

----------------------------------------------------------------------------

Now let's look at your adventure:

> # ./xorriso -outdev /dev/rcd0c -status -use_immed_bit
> ...
> -use_immed_bit default/off

Ok. OpenBSD was recognized and Immed bit is disabled by default.
That's why we get no confusion by long lasting SCSI commands.

> Media current: DVD-RW restricted overwrite
> Media status : is written , is appendable
> Media summary: 1 session, 114093 data blocks,  223m data, 4265m free

The DVD-RW is currently formatted (by dvd+rw-format out of dvd+rw-tools ?).
There is an ISO filesystem on it with size 223 MB.
You asked xorriso by its main personality. So the medium is classified as
"appendable".

A run of

  xorriso -dev /dev/rcd0c -map /some/directory /new_directory

would have put the file tree of /some/directory underneath the ISO directory
/new_directory and then have appended a new session which when mounted shows
the files of the 223 MB ISO and the files of the /new_directory tree.

Nevertheless, you could have used

  xorriso -as cdrecord -v dev=/dev/rcd0c /home/uaa/install

to burn your image file "/home/uaa/install" over the existing ISO.

Or you could have used

  xorriso -outdev /dev/rcd0c -blank as_needed

to mark the ISO as invalid and let xorriso -dev consider the medium as blank.


> # ./xorriso -as cdrecord -v dev=/dev/rcd0c blank=fast
> ...
> Media current: DVD-RW restricted overwrite
> Media status : is blank
> Media summary: 0 sessions, 0 data blocks, 0 data, 4488m free
> xorriso : NOTE : Blank medium detected. Will leave it untouched

That's because from the pure view of SCSI/MMC, nothing needs to be done
to prepare the medium for overwriting from scratch.


> # cdrecord -media-info dev=/dev/rcd0c:1,4,0
> ...
> Mounted media type:       DVD-RW restricted overwrite
> Disk Is erasable
> ...
> disk status:              complete

I wonder what cdrecord would do if you order it to write on the "complete"
medium.


> # cdrecord -v dev=/dev/rcd0c blank=fast
> ...
> Blanking time:   56.217s

Now the formatting is gone and the ISO filesystem unreachable.
(The ISO might come back if you immediately format the medium again
 by xorriso.)


> # ./xorriso -scsi_log on -outdev /dev/rcd0c -status -use_immed_bit
> ...
> Media current: DVD-RW sequential recording
> Media status : is blank , but will need -close on

The DVD-RW has changed its personality to "sequential recording".
Both xorriso personalities consider it "blank".


> #  ./xorriso -scsi_log on -as cdrecord -v dev=/dev/rcd0c blank=fast
> ...
> xorriso : NOTE : -blank: DVD-RW present. Mode 'fast' defaulted to mode 'all'.
> xorriso : HINT : Mode 'deformat_quickest' produces single-session-only media.
> xorriso : NOTE : Blank medium detected. Will leave it untouched

Now there is really no use in applying SCSI command BLANK.
(Because xorriso is a multi-session tool it would have blanked to "fully"
 blank state. As compensation it gives the user a hint how to get "fastly"
 blanked. But in the end it refuses to blank at all.)


> # ./xorriso -scsi_log on -as cdrecord -v -dao dev=/dev/rcd0c /home/uaa/install

After all the forth and back, this DAO run should have succeeded.
(Since you give input of predictable size and since you do not use option
 -multi, write type DAO would be default, anyway.)

Everything looks good until after

> RESERVE TRACK
> 53 00 00 00 00 00 01 be 43 00
>      4233 us     [ 2760939 ]

and a first successful WRITE command, the second WRITE command runs into
our old enemy:

> WRITE(10)
> 2a 00 00 00 00 10 00 00 10 00
> +++ sense data = 70 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> +++ key=2  asc=00h  ascq=00h
>      1022 us     [ 4177534 ]

It would be highly interesting to see whether cdrecord gets a better
reaction from drive and/or kernel.

It would be ok for a busy drive to emit NOT READY on a WRITE command.
But then there should be appeasing ASC and ASCQ numbers which invite the
program to retry the WRITE command with the same block address.

I am much reluctant to repeat the WRITE command on Sense code 2,0,0.
Especially because with our old BLANK experiments the reply NOT READY
continued even after the blanking was obviously completed.
It looks like we have lost as soon as the first 2,0,0 arrives. :((


We need to find out whether drive or kernel are to blame for these
strange Sense data.


Have a nice day :)

Thomas