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 <jaimor@orcon.net.nz>
Reply to: