[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help: Burning multisession DVD+R with cdrecord 2.01.01a37



Hi,

Eric Wanchic:
> "BTW, I hope that is never the
> case. That would really suck if I had to -eject the DVD and re-inject it
> back into the drive everytime I did a backup :)"

Urm ... how to say it ... hem, hem:

Better -eject or use xorriso.

---------

I made experiments on my SuSE 10.2 (one year old
distro on 3 month old computer). There is a quite
reliable ill effect with burning CD-RW and reading
it without eject-load cycle.

It is not the same as described by Eric, but it is
as well a reason to eject media after burning
(unless one circumvents the block device for reading
as it has to be done for writing).

The problematic procedure on my system is this:
- insert a blank CD-RW into /dev/sr1
- burn 40 MB as first session
  ioctl(CDROM_MEDIA_CHANGED)==0 :(
- checkread via dd if=/dev/sr1 : ok 40 MB visible
  and identical to image.
- blank again
  ioctl(CDROM_MEDIA_CHANGED)==1 :)
- burn 125 MB as first session
  ioctl(CDROM_MEDIA_CHANGED)==0 :(
- checkread via dd if=/dev/sr1 : yields 40 MB
  If i do not eject, then i always get 40 MB from
  the block device buffered i/o.

This does not depend on the burn program or on
the user id. 
cdrecord as superuser has the same effect as
cdrskin as desktop user. wodim the same.
It is not their fault.

growisofs transport.hxx contains this software haiku:

1.  int is_reload_needed (int same_capacity)
2.  {   if (same_capacity && ioctl (fd,0x1261,0) == 0) // try BLKFLSBUF
            return 0;
        else
3.          return ioctl (fd,CDROM_MEDIA_CHANGED,CDSL_CURRENT) == 0;
    }

I understand the poet's intention as follows:

1. is true if the readable amount of data before burning
   is the same as after burning. (see growisofs_mmc.cpp
   and growisofs.c)

2. only then try to flush the buffers and omit eject-reload.

3. if the readable size changed (grew ?) then check whether
   the media is considered considered changed and in that
   case omit eject-reload.


Umbrella open
chase away obscuring clouds
if not sun smiling.


I watch CDROM_MEDIA_CHANGED in libburn now and i try
BLKFLSBUF in my local development version.
For my desktop user it returns -1 and errno 13 "Permission denied".
For root i get errno 38 "Function not implemented". Grmpf.

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

One needs reliable and up-to-date block device reading
if one uses mkisofs or genisoimage for multi-session.
So in this case i see no other way but ejecting and
loading the media between sessions.

This can be done either by shell commands "eject" resp.
"eject -t" or by "cdrskin ...burn-run... -eject" resp.
"cdrskin dev=/dev/sr0 -atip >/dev/null 2>&1".

Only xorriso is immune against the problem. I did never
experience any image read failure in the last three months
of testing. It would show up clearly, because after each
session commit in dialog mode it reloads the result image.
I have now written 600 MB in four sessions, the block device
shows me the first 40 MB of the first 150 MB session,
and xorriso correctly shows me the ISO directory tree
which is stored beginning at 170988s = 334 MB.

So as long as you do not want to restore the backup
that long the tray would not need to be ejected.

---------

Have a nice day :)

Thomas


Reply to: