Sorry about this being old, but I'm just catching up on the group,
and thought this was important should someone be considering
rewriting some low-level code...
case. One can wonder if the common block buffer could do better
job spotting the last addressible sector? Well, yes, but do keep
in
Sorry about this being old, but I'm just catching up on the group,
and thought this was important should someone be considering
rewriting some low-level code...
case. One can wonder if the common block buffer could do better
job spotting the last addressible sector? Well, yes, but do keep
in
What value do you call sane - count=N with N = isoinfo -d?
Sane block count is obviously the number of last *significant* block.
Yes, for mkisofs mastered images the value returned by isoinfo suffices.
As long as this sane value can't be obtained easily, even with
non-mkisofs-mastered
From [EMAIL PROTECTED] Tue Oct 14 18:47:59 2003
If you really have to
checksum the whole image, then make sure to bypass the block buffer
*and* provide sane block count value. A.
Sane block count is obviously the number of last *significant* block.
Yes, for mkisofs mastered images
From: Lourens Veen [EMAIL PROTECTED]
If set to (A2) the P-MIN, P-SEC and P-FRAC fields specify the
beginning of the Lead-out Track, thus the address of the first
Section of the Lead-out Track.
The TOC basically consists of a list of records, each of which
specifies a track number and a start
From: Andy Polyakov [EMAIL PROTECTED]
df output equals to isoinfo -d per definition. I mean df *always* shows
same value as isoinfo (provided that we keep talking about single
session media:-). It's simply two ways to examine same value, so it does
not prove anything. What you should compare it
From: Andy Polyakov [EMAIL PROTECTED]
Disregard this comment! Yes, there is a window of uncertainty, but not
as big as 75 blocks! These 75 blocks is most likely reservation for the
fact that player unit has no way to tell apart media recorded in DAO and
TAO or something in that style. Yet this
mkisofs -B on the other hand does cover SPARC boot block[s] by value
returned by isoinfo. But even if ISO9660 partition of Solaris boot CD
was prepared with mkisofs, there're UFS partitions which are surely
appended by *separate* means and therefore resulting layout can hardly
be classified
mkisofs -B on the other hand does cover SPARC boot block[s] by value
returned by isoinfo. But even if ISO9660 partition of Solaris boot CD
was prepared with mkisofs, there're UFS partitions which are surely
appended by *separate* means and therefore resulting layout can hardly
be
On Wed 15 October 2003 16:19, Joerg Schilling wrote:
From: Andy Polyakov [EMAIL PROTECTED]
[...]
75 blocks exist nowhere in a seek related paper
The basic position accuracy (without starting to read!) for a CD
player must be 2 seconds (150 sectors). This is why at least
150 sectors of
From [EMAIL PROTECTED] Wed Oct 15 17:26:12 2003
mkisofs -B on the other hand does cover SPARC boot block[s] by value
returned by isoinfo. But even if ISO9660 partition of Solaris boot CD
was prepared with mkisofs, there're UFS partitions which are surely
appended by *separate* means and
I *agree* that you can *not* use isoinfo output to copy the *original*
Solaris media as it's delivered from Sun.
Just had a chance to examine SPARC Solaris 9 DVD. ISO9660 layout appears
to be prepared by mkisofs, *but* UFS partitions are clearly appended to
iso-image by means *other than*
What value do you call sane - count=N with N = isoinfo -d?
Sane block count is obviously the number of last *significant* block.
Yes, for mkisofs mastered images the value returned by isoinfo suffices.
As long as this sane value can't be obtained easily, even with
non-mkisofs-mastered
* The SCSI specification allows for the value returned
* by READ CAPACITY to be up to 75 2K sectors past the
* last readable block.
What idiot came up with that idea... ?
It's the way CD media is. The catch is that MSF addressing information
is smashed across the whole block [in
From: Lourens Veen [EMAIL PROTECTED]
If set to (A2) the P-MIN, P-SEC and P-FRAC fields specify the
beginning of the Lead-out Track, thus the address of the first
Section of the Lead-out Track.
The TOC basically consists of a list of records, each of which
specifies a track number and a start
From: Andy Polyakov [EMAIL PROTECTED]
Disregard this comment! Yes, there is a window of uncertainty, but not
as big as 75 blocks! These 75 blocks is most likely reservation for the
fact that player unit has no way to tell apart media recorded in DAO and
TAO or something in that style. Yet this
mkisofs -B on the other hand does cover SPARC boot block[s] by value
returned by isoinfo. But even if ISO9660 partition of Solaris boot CD
was prepared with mkisofs, there're UFS partitions which are surely
appended by *separate* means and therefore resulting layout can hardly
be classified
mkisofs -B on the other hand does cover SPARC boot block[s] by value
returned by isoinfo. But even if ISO9660 partition of Solaris boot CD
was prepared with mkisofs, there're UFS partitions which are surely
appended by *separate* means and therefore resulting layout can hardly
be
On Wed 15 October 2003 16:19, Joerg Schilling wrote:
From: Andy Polyakov [EMAIL PROTECTED]
[...]
75 blocks exist nowhere in a seek related paper
The basic position accuracy (without starting to read!) for a CD
player must be 2 seconds (150 sectors). This is why at least
150 sectors of
From [EMAIL PROTECTED] Wed Oct 15 17:26:12 2003
mkisofs -B on the other hand does cover SPARC boot block[s] by value
returned by isoinfo. But even if ISO9660 partition of Solaris boot CD
was prepared with mkisofs, there're UFS partitions which are surely
appended by *separate* means and
I *agree* that you can *not* use isoinfo output to copy the *original*
Solaris media as it's delivered from Sun.
Just had a chance to examine SPARC Solaris 9 DVD. ISO9660 layout appears
to be prepared by mkisofs, *but* UFS partitions are clearly appended to
iso-image by means *other than*
Meet the players in the field:
- block buffer which provides for read-ahead, I/O requests' slicing and
coalescing;
- value returned by READ CAPACITY command, hereafter simply READ
CAPACITY;
- actual lead-out position;
Rules of the game (please note that I'm not claiming that I know all the
rules
Wow! Someone who knows what he's talking about - I'm impressed.
- CD lead-out position is documented to be inaccurate [with 75 blocks
inaccuracy?]
Silly question - where/how? How do you arrive at 75?
I have observed the same problem with DVD+R burnt by Nero (different
box), reading on the box
- CD lead-out position is documented to be inaccurate [with 75 blocks
inaccuracy?]
Silly question - where/how?
Note the question mark in the [comment]. It means I'm not sure where I
read/heard this and I admit that I might be wrong about this:-)
How do you arrive at 75?
75 sectors is
From: Volker Kuhlmann [EMAIL PROTECTED]
Thanks for all your thoughts. I'll combine the reply.
Why are you mailing cdwrite? If it's a kernel bug, you should send a
bug report to linux-kernel I'd say.
I am not sure where the bug is, but it affects CDs. This is a CD writing
list?
(a) get the
From: Ambrose Li [EMAIL PROTECTED]
(From someone who doesn't know much about CD's)
I used to checksum all the files (after finding that
checksumming the whole disk doesn't work -- something beyond
my understanding). This stopped abruptly after I upgraded my
Linux kernel to 2.4, when mounting a
From: Andy Polyakov [EMAIL PROTECTED]
If you really have to
checksum the whole image, then make sure to bypass the block buffer
*and* provide sane block count value. A.
Obvious question ;): is there an easy way to bypass the block buffer?
Well, already mentioned readcd effectively
If you really have to
checksum the whole image, then make sure to bypass the block buffer
*and* provide sane block count value. A.
Sane block count is obviously the number of last *significant* block.
Yes, for mkisofs mastered images the value returned by isoinfo suffices.
Not if
On Tue 14 October 2003 12:30, Andy Polyakov wrote:
Meet the players in the field:
- block buffer which provides for read-ahead, I/O requests'
slicing and coalescing;
- value returned by READ CAPACITY command, hereafter simply READ
CAPACITY;
- actual lead-out position;
Rules of the game
75 sectors is one second CD-DA, right?
Yes.
I have observed the same problem with DVD+R burnt by Nero (different
box), reading on the box as previously stated, so I don't think it's
limited to CDs - it affects DVDs in the same manner.
Can you confirm that the value returned by isoinfo
Meet the players in the field:
- block buffer which provides for read-ahead, I/O requests' slicing and
coalescing;
- value returned by READ CAPACITY command, hereafter simply READ
CAPACITY;
- actual lead-out position;
Rules of the game (please note that I'm not claiming that I know all the
rules
Wow! Someone who knows what he's talking about - I'm impressed.
- CD lead-out position is documented to be inaccurate [with 75 blocks
inaccuracy?]
Silly question - where/how? How do you arrive at 75?
I have observed the same problem with DVD+R burnt by Nero (different
box), reading on the box
On Wed, Oct 15, 2003 at 12:33:12AM +1300, Volker Kuhlmann wrote:
If we're talking about ISO9660 layout prepared by mkisofs,
then those more blocks are known to be insignificant and
you can as well checksum every file instead of the whole
filesystem image, can't you?
No. Checksumming
- CD lead-out position is documented to be inaccurate [with 75 blocks
inaccuracy?]
Silly question - where/how?
Note the question mark in the [comment]. It means I'm not sure where I
read/heard this and I admit that I might be wrong about this:-)
How do you arrive at 75?
75 sectors is
From: Volker Kuhlmann [EMAIL PROTECTED]
Thanks for all your thoughts. I'll combine the reply.
Why are you mailing cdwrite? If it's a kernel bug, you should send a
bug report to linux-kernel I'd say.
I am not sure where the bug is, but it affects CDs. This is a CD writing
list?
(a) get the
From: Ambrose Li [EMAIL PROTECTED]
(From someone who doesn't know much about CD's)
I used to checksum all the files (after finding that
checksumming the whole disk doesn't work -- something beyond
my understanding). This stopped abruptly after I upgraded my
Linux kernel to 2.4, when mounting a
From: Andy Polyakov [EMAIL PROTECTED]
If you really have to
checksum the whole image, then make sure to bypass the block buffer
*and* provide sane block count value. A.
Obvious question ;): is there an easy way to bypass the block buffer?
Well, already mentioned readcd effectively
If you really have to
checksum the whole image, then make sure to bypass the block buffer
*and* provide sane block count value. A.
Sane block count is obviously the number of last *significant* block.
Yes, for mkisofs mastered images the value returned by isoinfo suffices.
Not if
On Tue 14 October 2003 12:30, Andy Polyakov wrote:
Meet the players in the field:
- block buffer which provides for read-ahead, I/O requests'
slicing and coalescing;
- value returned by READ CAPACITY command, hereafter simply READ
CAPACITY;
- actual lead-out position;
Rules of the game
75 sectors is one second CD-DA, right?
Yes.
I have observed the same problem with DVD+R burnt by Nero (different
box), reading on the box as previously stated, so I don't think it's
limited to CDs - it affects DVDs in the same manner.
Can you confirm that the value returned by isoinfo
Thanks for all your thoughts. I'll combine the reply.
Why are you mailing cdwrite? If it's a kernel bug, you should send a
bug report to linux-kernel I'd say.
I am not sure where the bug is, but it affects CDs. This is a CD writing
list?
(a) get the size of the ISO filesystem with cdrecord
Thanks for all your thoughts. I'll combine the reply.
Why are you mailing cdwrite? If it's a kernel bug, you should send a
bug report to linux-kernel I'd say.
I am not sure where the bug is, but it affects CDs. This is a CD writing
list?
(a) get the size of the ISO filesystem with cdrecord
On Wed 8 October 2003 05:09, Rob Bogus wrote:
Volker Kuhlmann wrote:
Esteemed gurus,
if anyone is able to shed some more light on this kernel problem
I'd appreciate it. It's been going on for years.
When reading the whole of an iso9660 filesystem from a cd or
dvd, I often get I/O
Lourens Veen wrote:
On Wed 8 October 2003 05:09, Rob Bogus wrote:
Volker Kuhlmann wrote:
Esteemed gurus,
if anyone is able to shed some more light on this kernel problem
I'd appreciate it. It's been going on for years.
When reading the whole of an iso9660
On Wed 8 October 2003 13:03, Rob Bogus wrote:
Well, it could be a bad CD ;-) I just tried using dd on my old
burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the
52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 kernel,
and no error on any of them. I can't try a 2.6 kernel
From: Volker Kuhlmann [EMAIL PROTECTED]
(I scripted that a long time ago). In the mid nineties it was necessary
to use cdrecord -pad to make linux read all the files, described as
read-ahead bug in linux's iso9660 driver in the cdrecord man page. When
I checked again a few years ago it was
From: Lourens Veen [EMAIL PROTECTED]
I'd appreciate it. It's been going on for years.
snip
This state of affairs is not really acceptable. Does anyone know
what the problem is caused by, and what can/should be done about
it?
Why are you mailing cdwrite? If it's a kernel bug, you should send
On Wed 8 October 2003 05:09, Rob Bogus wrote:
Volker Kuhlmann wrote:
Esteemed gurus,
if anyone is able to shed some more light on this kernel problem
I'd appreciate it. It's been going on for years.
When reading the whole of an iso9660 filesystem from a cd or
dvd, I often get I/O
Lourens Veen wrote:
On Wed 8 October 2003 05:09, Rob Bogus wrote:
Volker Kuhlmann wrote:
Esteemed gurus,
if anyone is able to shed some more light on this kernel problem
I'd appreciate it. It's been going on for years.
When reading the whole of an iso9660
On Wed 8 October 2003 13:03, Rob Bogus wrote:
Well, it could be a bad CD ;-) I just tried using dd on my old
burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the
52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0 kernel,
and no error on any of them. I can't try a 2.6 kernel
From: Volker Kuhlmann [EMAIL PROTECTED]
(I scripted that a long time ago). In the mid nineties it was necessary
to use cdrecord -pad to make linux read all the files, described as
read-ahead bug in linux's iso9660 driver in the cdrecord man page. When
I checked again a few years ago it was
From: Lourens Veen [EMAIL PROTECTED]
I'd appreciate it. It's been going on for years.
snip
This state of affairs is not really acceptable. Does anyone know
what the problem is caused by, and what can/should be done about
it?
Why are you mailing cdwrite? If it's a kernel bug, you should send
On Wed 8 October 2003 13:41, Lourens Veen wrote:
On Wed 8 October 2003 13:03, Rob Bogus wrote:
Well, it could be a bad CD ;-) I just tried using dd on my old
burner (real SCSI), my recent burner (ATAPI+ide-scsi), and the
52x reader only (ATAPI+ide-cd) and a Redhat 2.4.18-24.8.0
kernel,
Volker Kuhlmann wrote:
Esteemed gurus,
if anyone is able to shed some more light on this kernel problem I'd
appreciate it. It's been going on for years.
When reading the whole of an iso9660 filesystem from a cd or dvd, I
often get I/O errors within the last blocks of the filesystem. Using
cat
On Tue 7 October 2003 00:06, Volker Kuhlmann wrote:
Esteemed gurus,
if anyone is able to shed some more light on this kernel problem
I'd appreciate it. It's been going on for years.
snip
This state of affairs is not really acceptable. Does anyone know
what the problem is caused by, and what
Volker Kuhlmann wrote:
Esteemed gurus,
if anyone is able to shed some more light on this kernel problem I'd
appreciate it. It's been going on for years.
When reading the whole of an iso9660 filesystem from a cd or dvd, I
often get I/O errors within the last blocks of the filesystem. Using
cat
Esteemed gurus,
if anyone is able to shed some more light on this kernel problem I'd
appreciate it. It's been going on for years.
When reading the whole of an iso9660 filesystem from a cd or dvd, I
often get I/O errors within the last blocks of the filesystem. Using
cat /dev/cdrom
as test is
On Tue 7 October 2003 00:06, Volker Kuhlmann wrote:
Esteemed gurus,
if anyone is able to shed some more light on this kernel problem
I'd appreciate it. It's been going on for years.
snip
This state of affairs is not really acceptable. Does anyone know
what the problem is caused by, and what
Esteemed gurus,
if anyone is able to shed some more light on this kernel problem I'd
appreciate it. It's been going on for years.
When reading the whole of an iso9660 filesystem from a cd or dvd, I
often get I/O errors within the last blocks of the filesystem. Using
cat /dev/cdrom
as test is
59 matches
Mail list logo
