Re: growisofs failing on some iso files

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

> Regarding the alignment I observe growisofs always writes 16 blocks chunks,
> even the last one, no matter if the original iso was aligned to 16 blocks or
> not. So it always align data currently if speaking about burned data, not
> speaking about reserving track. If I understand it correctly, that's wrong
> behavior and the last chunk should be shorter. Right?

At least the reserved amount should not be smaller than the written
amount.

DAO on DVD-R or unformatted DVD-RW is the only DVD case where non-aligning
is allowed and would provide a benefit at read time.


But i wonder how your observation matches these lines in growisofs_mmc.cpp
if not your patch is applied:

    if (dao_blocks!=0 && (lba+nbl)>dao_blocks)
        nbl = dao_blocks-lba;

    while (1)
    {   cmd[0] = wrvfy?0x2E:0x2A;       // WRITE [AND VERIFY] (10)
        cmd[2] = (lba>>24)&0xff;        // Logical Block Addrss
        cmd[3] = (lba>>16)&0xff;
        cmd[4] = (lba>>8)&0xff;
        cmd[5] = lba&0xff;
        cmd[7] = (nbl>>8)&0xff;
        cmd[8] = nbl&0xff;
        cmd[9] = 0;

This composes a SCSI/MMC command WRITE(10). In case of DAO, the variable
dao_blocks is supposed to contain the number of 2kB blocks that was
computed from the expected number of input bytes. I.e. aligned to 2 KiB
not necessarily to 32.

Your patch rounds up the number of blocks to the next multiple of 16,
regardless whether DAO or not:

     blocks = (unsigned int)(size/2048);
+    blocks += 15, blocks &= ~15;
     if (is_dao)        dao_blocks = blocks;
-    else       blocks += 15, blocks &= ~15;

So to me it looks as if the reservation size and written size would match
in both cases, with and without your patch.


> In this case the patch from the previous post should work well.

It should work well with and without 32 KiB alignment.
It works for me without alignment on LG, Samsung, and Optiarc drives.

I still believe the problem is related to kernel and/or bus controller.

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

> > No MMC drive is supposed to emit the "Descriptor" format.

> This doesn't seem to be the case, the sense bytes look like as follows:
> 70 0 2 0 0 0 0 a 0 0 0 0 4 7 0 0 0 0

This reply may well stem from the drive itself.
It has the "Fixed" format (0x70), and its diagnostic code triple says
  KEY=2, ASC=4, ASCQ=7
which according to MMC means
  2 04 07 LOGICAL UNIT NOT READY, OPERATION IN PROGRESS

It is not unnormal to get this status reply during a loop with
command TEST UNIT READY, which is cycling while the program is
waiting for a long running operation to end.
For example when growisofs_mmc.cpp ejects the tray:

                {   cmd[0] = 0x1B;      // START/STOP UNIT
                    cmd[1] = 0x1;       // "IMMED"
                    cmd[4] = 0x2;       // "Eject"
                    cmd[5] = 0;
                    if (cmd.transport() == 0x20407) // "OP IN PROGRESS"

Searching for more 0x20407 leads several occasions in growisofs_mmc.cpp
where this status is expected and handled in various ways.


My technical point is that MMC specs do not allow the "Descriptor"
format (0x72) of the sense data. Only the more general SPC-3 specs mention
this format.
MMC-6 says in "3 Definitions, Symbols, Abbreviations, and Conventions":
  3.1.63 Sense Key (SK)
  MM drives return only fixed format sense data as defined in [SPC-3].
  In fixed format sense data, the 4-bit value stored in bits 3 - 0 of
  byte 2 of the fixed format sense data is labeled the Sense Key. In the
  case of this standard, SK is part of a 20-bit code: SK/ASC/ASCQ that
  identifies a specific error or condition.

MMC-3 is less explicit but still implicitly outrules "Descriptor" format:
  3.1.118 SK (Sense Key)
  Specifically, this refers to the value stored in the low order 4 bits
  of byte 2 of the sense information as defined in SPC-2.
  [SPC-2 does not mention "Descriptor" format at all.]

So i seriously doubt that it came from the drive.
It must come from something that obeys SPC-3 but not MMC-1 to MMC-6.
Kernel, SATA controller, ...

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


> cdrsking works fine with the same iso.

Please verify that the readable size is really not aligned to 32 KiB.

I introduced non-alignment only a year ago with version 1.0.6.
So if yours is older, then the readable size will be aligned.

The cdrskin development version in SVN meanwhile has an option to enforce
alignment:

    --obs_pad
           Pad  the  data of last write operation of a DVD-R[W] DAO session
           or stdio: pseudo-drive up to the full size of an  output  chunk.
           This  padding  has  to be applied automatically to the other DVD
           and BD media types, where it causes  e.g.  ISO  images  to  have
           trailing unclaimed blocks.
           There are reports that DAO sessions of a size that is not a mul-
           tiple of 16 blocks  abort  on  some  Linux  kernels  and/or  DVD
           drives.

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

Have a nice day :)

Thomas