desktop-packages team mailing list archive

[Thomas Schmitt <scdbackup@xxxxxxx>]

Public bug reported:

Hi,

firstly: thanks for taking care of
  https://bugs.launchpad.net/ubuntu/+source/dvd+rw-tools/+bug/1113679

Secondly: I hate to say it now, but i think a Debian user
just complained about the problem's little brother:

  http://forums.debian.net/viewtopic.php?f=10&t=120566

reports that an oversized burn attempt used up the
medium and finally ended by

  :-[ WRITE@LBA=b87400h failed with SK=5h/END OF USER AREA ENCOUNTERED
ON THIS TRACK]: Input/output error

I believe that the not-yet-aware bug reporter in
forums.debian.org tried to squeeze data for the capacity of
an unformatted BD-R into a then formatted BD-R with not
enough capacity.

growisofs.c has code to prevent the start of such a burn:

  off64_t        capacity=0, ... ;
  ...
    if (ioctl_handle!=INVALID_HANDLE)
        capacity = get_capacity (ioctl_handle);
  ...
        if (capacity && progress.final > capacity)
        {   fprintf (stderr,":-( %s: %"LLD" blocks are free, "
                            "%"LLD" to be written!\n",
                            ioctl_device,
                            (capacity-outoff)/2048,tracksize/2048);

  ...
        pwrite64_method = poor_mans_setup (ioctl_handle,
                                           outoff+tracksize);

But the BD-R gets automatically formatted not before the
call to growisofs_mmc.cpp : poor_mans_setup()

        case 0x41:      // BD-R SRM
            if ((disc_info[2]&3) == 0)  // blank
                bd_r_format (cmd);

This lets the capacity shrink from 25,025,314,816 to
24,220,008,448 = 0xb87400 * 2048.

I will have to think about possible remedies.
Problem is that one has to reliably predict the formatted
capacity in order not to format the BD-R and to then say
"Hey ! Now your data do not fit any more !"

But that would mean to derive a predictor function
from bd_r_format(). This will not be as small a patch
as the one in bug 1113679.
And not be developped in half an hour, i fear.
It does not only have to predict the size but also
whether auto-formatting will happen at all.

In any case i'd need a tester who's willing to burn
a few tightly filled BD-R (hopefully sucessfully).

Have a nice day :)

Thomas

** Affects: dvd+rw-tools (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to dvd+rw-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1424215

Title:
  growisofs BD-R overflow error despite capacity check

Status in dvd+rw-tools package in Ubuntu:
  New

Bug description:
  Hi,

  firstly: thanks for taking care of
    https://bugs.launchpad.net/ubuntu/+source/dvd+rw-tools/+bug/1113679

  Secondly: I hate to say it now, but i think a Debian user
  just complained about the problem's little brother:

    http://forums.debian.net/viewtopic.php?f=10&t=120566

  reports that an oversized burn attempt used up the
  medium and finally ended by

    :-[ WRITE@LBA=b87400h failed with SK=5h/END OF USER AREA ENCOUNTERED
  ON THIS TRACK]: Input/output error

  I believe that the not-yet-aware bug reporter in
  forums.debian.org tried to squeeze data for the capacity of
  an unformatted BD-R into a then formatted BD-R with not
  enough capacity.

  growisofs.c has code to prevent the start of such a burn:

    off64_t        capacity=0, ... ;
    ...
      if (ioctl_handle!=INVALID_HANDLE)
          capacity = get_capacity (ioctl_handle);
    ...
          if (capacity && progress.final > capacity)
          {   fprintf (stderr,":-( %s: %"LLD" blocks are free, "
                              "%"LLD" to be written!\n",
                              ioctl_device,
                              (capacity-outoff)/2048,tracksize/2048);

    ...
          pwrite64_method = poor_mans_setup (ioctl_handle,
                                             outoff+tracksize);

  But the BD-R gets automatically formatted not before the
  call to growisofs_mmc.cpp : poor_mans_setup()

          case 0x41:      // BD-R SRM
              if ((disc_info[2]&3) == 0)  // blank
                  bd_r_format (cmd);

  This lets the capacity shrink from 25,025,314,816 to
  24,220,008,448 = 0xb87400 * 2048.

  I will have to think about possible remedies.
  Problem is that one has to reliably predict the formatted
  capacity in order not to format the BD-R and to then say
  "Hey ! Now your data do not fit any more !"

  But that would mean to derive a predictor function
  from bd_r_format(). This will not be as small a patch
  as the one in bug 1113679.
  And not be developped in half an hour, i fear.
  It does not only have to predict the size but also
  whether auto-formatting will happen at all.

  In any case i'd need a tester who's willing to burn
  a few tightly filled BD-R (hopefully sucessfully).

  Have a nice day :)

  Thomas

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dvd+rw-tools/+bug/1424215/+subscriptions