[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4
From: |
Thomas Schmitt |
Subject: |
Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD |
Date: |
Sun, 07 Aug 2016 16:56:32 +0200 |
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
- [Bug-xorriso] CD ok, DVD failed (Re: building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD), SASANO Takayoshi, 2016/08/07
- Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD,
Thomas Schmitt <=
- [Bug-xorriso] cdrecord -VV test (Re: building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD), SASANO Takayoshi, 2016/08/08
- [Bug-xorriso] blank/formatted DVD-RW test (Re: building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD), SASANO Takayoshi, 2016/08/08
- Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD, Thomas Schmitt, 2016/08/09
- Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD, SASANO Takayoshi, 2016/08/15
- Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD, Thomas Schmitt, 2016/08/16
- Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD, Thomas Schmitt, 2016/08/17
- Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD, SASANO Takayoshi, 2016/08/26
- Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD, Thomas Schmitt, 2016/08/28
Re: [Bug-xorriso] building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD, SASANO Takayoshi, 2016/08/08
- Prev by Date:
[Bug-xorriso] CD ok, DVD failed (Re: building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD)
- Next by Date:
[Bug-xorriso] cdrecord -VV test (Re: building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD)
- Previous by thread:
[Bug-xorriso] CD ok, DVD failed (Re: building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD)
- Next by thread:
[Bug-xorriso] cdrecord -VV test (Re: building libisofs-1.4.4, libburn-1.4.4, libisoburn-1.4.4 on OpenBSD)
- Index(es):