[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Issues brining BD disks from the command line - write failures


> Or you could be dealing with a stupid Linux kernel that hasn't got fixed
> for the last 15 years. If the recording ends at the end of the
> filesystem (common, for obvious reasons) and the size of the filesystem
> is not a multiple of some internal Linux buffer size, the last buffer
> Linux tries to read is incomplete and gets treated with an I/O error,
> although the only error is that of the programmer trying to read past
> the end of the legimitate recording.

This happens only with CDs which were written in write type TAO.
The stupidity is equally distributed over Linux and MMC specs.

The MMC specs prescribe that a TAO track ends by two non-data
sectors. These sectors are counted as part of the track size.

Linux blindly believes the announced track size from the CD
table-of-content and tries to read the two non-data sectors, too.
So far so good. One cannot distinguish TAO form SAO CDs easily
and thus has to try. The Linux stupidity is to drop the whole cache
tile (i believe it is 128 KB) that would contain those two blocks.
This means to also drop up to 124 KB of perfectly readable data.

Nevertheless, that is a _read_ problem. Dale has a problem with
write errors. The read-ahead bug has never been observed with
DVD or BD, anyway.

> The other good thing to do with Linux is to append 2MByte of zeros at
> the end of the filesystem

To my experience, 128 KB is enough. Tradition is 300 KB, out of
a wrong perception of Linux bug and MMC specs.
Actually it depends on the size of reading ahead. So it might vary.

> > I do not deem mkisofs to be the best ISO 9660 program. :))

> What are the options, though? (Not counting jokes like woedumb.)

If you want ISO 9660 then i dare to say it is better than mkisofs.

> And what are the options for UDF (which is becoming increasingly
> necessary)?

mkudffs and cp.

But for what, particularly ?
It is a misperception that the specs for DVD and BD would demand
UDF. It is the specs for commercial videos which demand UDF.
And the specs for BD demand a UDF variant which mkisofs does not
produce either.

I have looked into the specs (ECMA-167 and UDF-2.60, not nice to read)
and found nothing that would convince me of technical benefits.

If some user would approach me with the wish for UDF for video DVD
or video BD, then i would start developing ISO 9660 / UDF hybrids.
But that would need effort by the user, too. One would need hardware
that insists in specs-compliant DVDs. One would need the full specs
for video CD resp. BD. One would need time for testing.

No such user showed up yet.

Have a nice day :)


Reply to: