Hi,
Bill Davidsen:
> blockdev --setra 0 /dev/hdc
This does not match the behavior on my oldish system
either.
First suspicios thing:
# blockdev --getra /dev/hdg
8
That would be 8 x 512 = 2 x 2048 bytes.
So 4 kB should be a upper limit for the loss on this drive.
But my losses of blocks wi
Hi,
> I don't doubt your observations, I know that the run-out blocks are not
> readable. I think that's because at the level below blocks, data on the
> CD is spread across a wider range to mitigate the effect of scratches:
The run-out blocks seem to belong to packet writing mode
of which TAO is
On Wed, 2007-10-03 at 18:11 +0200, Thomas Schmitt wrote:
> Patrick Ohly:
> > Writing 150 empty blocks after the last block with user data is required
> > by the data CD standard - they are called "post-gap".
>
> Yep. But as the publicly available standard MMC-5 clarifies:
>
> "6.33.3.19 Post-gap
j t wrote:
Hi,
I have an iso file (which contains an iso9660/udf filesystem) that
I've written to a dvd-r using growisofs, thus:
# growisofs -dvd-compat -speed=1 -Z /dev/hdc=myDVD.iso
In the past, I have been able to check (verify) the burn finding the
iso size (using "isoinfo -d -i ") and the
Hi,
Patrick Ohly:
> Writing 150 empty blocks after the last block with user data is required
> by the data CD standard - they are called "post-gap".
Yep. But as the publicly available standard MMC-5 clarifies:
"6.33.3.19 Post-gap
If a Data track is followed by another kind of track
(such as an
Dear Thomas,
you are doing an excellent job explaining CD writing problems, my thanks
for that. However, in this case I feel compelled to comment ;-)
On Tue, 2007-10-02 at 22:20 +0200, Thomas Schmitt wrote:
> Our dear kernels seem to get confused by the inability
> to read these announced sectors
6 matches
Mail list logo
