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 <jai...@orcon.net.nz> -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org Archive: http://lists.debian.org/20120912193850.GA16857@ubyak