Hi,
Giulio Orsero wrote:
Isn't the read-ahead thing solved with padding?
ie mkisofs adds 150k by default since some time, and when burning I've
always used 1MB of padding (ie cdrecord's padsize=512s), just to be
safe.
I could not reproduce the bug with anything
else but CD TAO tracks.
Never
Thomas Schmitt scdbac...@gmx.net wrote:
I could not reproduce the bug with anything
else but CD TAO tracks.
Never with CD SAO, never with DVD.
The reason for the TAO problem is known:
Two non-data sectors at the end of the announced
track size.
A simple remedy is not to read the last two
Hi,
Joerg Schilling wrote:
There are known writers that write up to 15 run out sectors in TAO mode.
Then a cautious program should approach the
last 15 sectors separately and be ready to
tolerate failure.
This would still not hamper read performance
with the main part of the image.
Have a
Volker Kuhlmann wrote:
On Sun 10 Jan 2010 10:15:10 NZDT +1300, Bill Davidsen wrote:
There was another error having to do with reading data at the end of an
image. Due to read ahead settings a read past end of data occurred and the
(valid) partial data was not returned to the user program.
On Mon, Jan 18, 2010 at 20:58, Bill Davidsen david...@tmr.com wrote:
I have just turned down readahead in blockdev and my issues have gone away,
but like you I don't see it much if a while.
Isn't the read-ahead thing solved with padding?
ie mkisofs adds 150k by default since some time, and
On Sun 10 Jan 2010 10:15:10 NZDT +1300, Bill Davidsen wrote:
There was another error having to do with reading data at the end of an
image. Due to read ahead settings a read past end of data occurred and the
(valid) partial data was not returned to the user program. Might that be
what you
On Sat, 09 Jan 2010 16:35:04 +0100, joerg.schill...@fokus.fraunhofer.de
(Joerg Schilling) wrote:
Well, if you can read files 4 GB correctly, it may be that the problem
has been fixed in a different way. is there any patch related to iso9660
in your kernel?
I unpacked the RHEL5 kernel src.rpm.
Hi,
If someone has a procedure to get the multi-extent Linux problem to manifest
itself, please post it.
I tried yours and i seem to have the original
plague with i/o error and all. (Unclear why i
cannot remember of the error back in 2008.)
$ dd if=/dev/urandom of=filetest bs=100
I'd like to understand what are the pitfalls, if any, in using multi-extent
files, as enabled by mkisofs --iso-level 3 option for files larger than
4GiB-2, on Linux.
I'm using
- mkisofs 2.01.01a69
- kernel 2.6.18-164.9.1.el5 (RHEL5)
I had made some tests and it seemed to
Giulio giul...@gmail.com wrote:
I'd like to understand what are the pitfalls, if any, in using multi-extent
files, as enabled by mkisofs --iso-level 3 option for files larger than
4GiB-2, on Linux.
I'm using
- mkisofs 2.01.01a69
- kernel 2.6.18-164.9.1.el5 (RHEL5)
When
On Sat, 09 Jan 2010 13:07:25 +0100, joerg.schill...@fokus.fraunhofer.de
(Joerg Schilling) wrote:
Giulio giul...@gmail.com wrote:
I'd like to understand what are the pitfalls, if any, in using multi-extent
files, as enabled by mkisofs --iso-level 3 option for files larger than
4GiB-2, on
Giulio Orsero giul...@gmail.com wrote:
On Sat, 09 Jan 2010 13:07:25 +0100, joerg.schill...@fokus.fraunhofer.de
(Joerg Schilling) wrote:
Giulio giul...@gmail.com wrote:
I'd like to understand what are the pitfalls, if any, in using multi-extent
files, as enabled by mkisofs --iso-level 3
Joerg Schilling wrote:
Giulio giul...@gmail.com wrote:
I'd like to understand what are the pitfalls, if any, in using multi-extent
files, as enabled by mkisofs --iso-level 3 option for files larger than
4GiB-2, on Linux.
I'm using
- mkisofs 2.01.01a69
- kernel 2.6.18-164.9.1.el5
Hi,
Bill Davidsen wrote:
There was another error having to do with reading data at the end of
an image. Due to read ahead settings a read past end of data occurred
and the (valid) partial data was not returned to the user program.
Might that be what you are remembering?
Hardly. It is related
14 matches
Mail list logo
