Re: dvd+rw-tools development and administration questions
Hi,
i am the author of xorriso, which learned several
essential DVD things from growisofs.
In reply i try to help its users when Andy is
not present.
So have a few technical comments to your bugs.
------------------------------------------------
> [Ubuntu bug] 600770 : Input/output error closing session on BD-R burn
> 600871 : disk-at-once (--use-the-force-luke=dao) a no-op for BD-R burns
Andy promised to fix that in the next release.
He stated it was not a show stopper.
There are no different write modes DAO versus
Incremental with BD media. BD-R writing resembles
DVD+R, BD-RE writing is much like DVD-RAM.
------------------------------------------------
> 600869 : transport.hxx:366: error: INT_MAX was not declared in this scope
> transport.hxx needs a #include <limits.h>
On Linux, FreeBSD or Solaris this is ok.
One would have to test the others or make
this inclusion conditional.
------------------------------------------------
> 600893 : buffer size rounding for >2G fails
> we run a high risk of buffer underruns@1M
Underruns are not as fatal with DVD or BD as
they once used to be with CD burners.
The fifo buffer was introduced quite late in the
life of growisofs. I understand it shall mainly
smoothen the data stream and thus make use of the
full possible media speed.
------------------------------------------------
> 600893 : erroneous reassignment to variable (keypunch?)
> (profile&=0xF0)==0x40) // BD-R[E]
Wow. That one looks dangerous on the first
glimpse.
But "profile" is a local variable which gets not
used afterwards. The test result is ok.
So the code is correct by accident.
------------------------------------------------
> 600898 : timeout delay in write loop too long for BD-R[E]
> device buffer underrun/cache coherency
> firmware problem affecting apparently only BD-R on Buffalo BRHC-6316U2
> (LG GGW-H20N) firmware level XJ03,
I have 'HL-DT-ST' 'BD-RE GGW-H20L' rev 'YL03'.
No problems with BD-R. (I make daily updates of
a few dozen MB. But in the past there were full
burns of 22 GB.)
> cmd.timeout(dao_toggle?180:60);
If i understand it right then this is a timeout
for situations when the MMC command does not end
voluntarily. Hard to believe that reducing the
number has a positive effect on i/o performance
or cache sanity.
How does the problem express itself ? (Symptoms ?)
Would you be willing to make tests with xorriso ?
> buffer underrun protection and zero-loss linking features are not yet
> universal).
Since growisofs always formats BD-R there is
really nothing to fear with buffer underruns.
Media in that state and with the WRITE10 command
as used by growisofs will checkread while writing
and eventually replace bad blocks from a spare
area. (That gives truly poor performance.)
I prefer full speed with the large burns and
use WRITE12 or unformatted media. Even then i
did not experience any buffer underrun damages
with my tests.
------------------------------------------------
> 601092: 64k block size for BD-R write
It seems needed for WRITE12 if the Streaming bit
is on. This is the method i use to get full speed
out of formatted BD media.
> // should I check if lba+nbl is multiple of 64K in BD case?
xorriso writes full 64 K chunks to BD, aligned
to 64 K addresses (i.e. LBA % 32 == 0).
It seems not very natural to use other sizes.
64 K chunks also may have a positive effect on
USB throughput to DVD recorders.
So i personally use 64 KB with all DVD types,
too.
------------------------------------------------
> 601125: code maintainability, modularity and readability issues
Do you really want to convince Andy of a
re-write ?
My own project has a much more elaborate
architecture (only in part my work) and similar
features. I learned a lot about MMC from
dvd+rw-tools code.
Comparing both, i would say it is not harder
to understand Andy's code than ours.
Where you have to hop forth and back in his
source, you have to drill holes through several
layers of abstraction in ours.
Yes, Andy's C tricks are smart with implicite
limitations.
I prefer to write more dull code and leave it
to the optimizer to be smart.
I see a more serious problem, nevertheless:
On Linux, growisofs and its children perform
block device driver operations and generic SCSI
driver operations on the same device during the
same program run. Both drivers are fewly
coordinated.
------------------------------------------------
Have a nice day :)
Thomas
Reply to: