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

On Wed, Sep 12, 2012 at 04:32:17PM +0200, Thomas Schmitt wrote:

[...]

 > 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.

Perhaps.

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

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

I straced growisofs -dry-run right after the two DL coasters,
and that showed both the command buffer being sent and the
response buffer being received.

 > 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.

Well, it looks it MAY be 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.

Could do next time I have to burn BD-R DL...  Can practise on a
BD-RE SL, no worries.

Had I a BD-RE DL, I could test the 32k vs 64k theory with more
certainty and ease, straight with cdrskin. =)

 >> 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.)

Yes, growisofs reacted to speed=X properly, provided X was
within drive's abilities.

 > Have a nice day :)

 > Thomas

Cheers,

-- 
/Dennis Vshivkov <[email protected]>


-- 
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/20120912193850.GA16857@ubyak