Re: growisofs 7.1: problem past first layer on BD-R DL
On Wed, Sep 12, 2012 at 08:48:50AM +0200, Thomas Schmitt wrote:
>> I've recorded the output of -vvv -V on each. The first two
>> runs differed from growisofs in at least two aspects: 0xAA
>> write command, and 64 KiB block size.
> The option -tao also omitted RESERVE TRACK. (How did you
> watch the SCSI output of growisofs ?)
I didn't. Just studied the source code a bit, it's obvious what
WRITE command it uses.
>> the certain difference is down to 64 KiB block size.
> To get a confirmation, you should try a run with option -sao,
> which will issue a RESERVE TRACK command.
Yes, but given the cost of the BD-R DL blanks, it may take a
while until I feel keen to. =) I'm glad enough that cdrskin
helped me around more co[a]sters.
> (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?
>> But who knows. I am not sure if other potentially relevant
>> differences existed (e.g., in pre-write track setup, etc).
> Not much chance except RESERVE TRACK which you avoided by
> -tao. The write procedure for unformatted BD-R has not much
> room for variations. I studied growisofs source code when
> enabling libburn for DVD and BD. At some points i
> deliberately deviated after having compared growisofs' doing
> with MMC specs. About half of those deviations had to be
> revoked some time later. Some of them seem to be helpful,
> though. :))
Next time I write BD-R SL, I can strace growisofs to check what
it's doing on the RESERVER TRACK front... or maybe dive into the
source again.
>> Another cdrskin difference, observed in the _result_, is
>> that the writing speed didn't seem to depend on speed=X
>> setting at all, ranging 5.1x to 8.0x on all three burns.
> libburn sends B6h SET STREAMING. But maybe the Streaming Bit
> in AAh WRITE(12) overrides that and causes fukk speed.
Yes, but note that I used streaming in only two of the three
writes, while all three weren't affected by speed=X.
> The lower limit of 5.1x might be due to a temporary shortage
> of input data (it's still nearly 20 MB/s). Did the "fifo"
> percentage sink below 50 % during the write run ?
> If so, then probably you will need a larger fifo size. Like
> fs=200m
> which will be able to buffer 5 to 10 seconds of the drive's
> data consumption.
No, the reason for the gradual 5.1--8.0x on- and offramp was the
limit at the angular velocity at the beginning of the first and
at the end of the second layer. All the time in between was
pretty steady around 8.0x.
> There is a fundamental speed problem with the synchronous
> drive operation that is done by libburn, and with its
> userspace priority. I observe better read speed through the
> Linux block device driver in comparison to libburn's READ
> facility. On my old 3 GHz machine the limit for libburn seems
> to be with about 25 MB/s = 5x to 6x BD. But the newer test
> achine (2.6 GHz) shows no speed degradation up to 8x BD.
> If you can afford another test which uses -sao and
> dvd_obs=64k, then this would help to learn about the role of
> RESERVE TRACk in this problem.
As above -- much later, perhaps. =)
> Have a nice day :)
Much nicer now, thanks. =)
--
/Dennis Vshivkov <jaimor@orcon.net.nz>
Reply to: