Re: growisofs 7.1: problem past first layer on BD-R DL

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

Hi,

> I didn't.  Just studied the source code a bit, it's obvious what
> WRITE command it uses.

I do have a derived growisofs into which i transplanted some
older version of libburn's SCSI logging. That helped me to find
a firmware bug in a drive which hated to be asked for its buffer
fill before the buffer was completely full for the first time.


> > (Chunk size 64k seems to be a prerequisite of writing without
> > defect management. So stream_recording=on implies
> > dvd_obs=64k.)

> Hmm, even with -use-the-force-luke:spare=none (I believe that
> precludes defect management), which was in use for my two failed
> burns, growisofs source code indicates 32 KiB blocks are used
> (it simply never uses any other block size); that is reinforced
> by the fact that an error address aligns with 32 KiB but not 64
> KiB.  Are we confusing terms here?

I meant that AAh WRITE(12) with Stream Recording Bit on did not
speed up writing in an experiment by Giulio Orsero when it transferred
32 KiB per command. Switching to 64 KiB showed the desired speed.
So i made dvd_obs=64k an automatic implication of stream_recording=on.

growisofs indeed always uses 32 KiB per WRITE(10) command.

It seems that other firmware peculiarities demand 64 KiB per WRITE
for proper success. I now consider to switch all BD writing to 64k
unconditionally. But changing anything about BD-R will demand
experiments which are costly even with single layer media.


> I can strace growisofs to check what it's doing on the RESERVER TRACK front

Will strace reveil the sg_io_hdr_t.cmdp of a ioctl(SG_IO) call ?

But studying the code in growisofs_mmc.cpp makes me think that there
is RESERVE TRACK only for the DVD-R family of media.

So it looks much like your theory about the 64 KiB WRITE size is
correct.


You could try to verify it by editing growisofs.c and to divide
macro DVD_BLOCK into a DVD_BLOCK that has to stay 32 KiB and a
WRITE_PAYLOAD_SIZE which may become 64 KiB.
Not a trivial task.

My candidates for WRITE_PAYLOAD_SIZE would be the calls of
  pread64 
  pwrite64_method
and probably some calculations nearby those calls.


> note that I used streaming in only two of the three
> writes, while all three weren't affected by speed=X.

And the write progress wit growisofs reacted on your speed wishes ?
(I will have to compare the code.)


Have a nice day :)

Thomas