From: Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
To: linux-kernel@vger.kernel.org
Cc: jwoithe@physics.adelaide.edu.au (Jonathan Woithe)
Subject: Linux 2.4.18: short dd read from IDE cdrom
Date: Mon, 2 Sep 2002 14:57:17 +0930 (CST) [thread overview]
Message-ID: <200209020527.g825RHd07114@sprite.physics.adelaide.edu.au> (raw)
Hi
For a number of years now I have duplicated cds using
dd if=/dev/cdrom of=foo.iso
cdrecord ... foo.iso
Here, /dev/cdrom is a symlink to an IDE CDROM (usually /dev/hdc). This has
worked on all versions of Linux I have used to date, up to 2.2.19.
Today I tried the same trick under 2.4.18 and struck a problem: the kernel
would not read the complete CD image. The CD I was testing this with was
64016 sectors long (1 sector = 2048 bytes): when mounted, df reported a size
of 128032 blocks and the image size created by mkisofs was 64016 extends.
However, the above dd command would *only* read 63972 sectors - 44 sectors
at the end of the disk were unread. If the disc was mounted, the full
contents of the CDROM could be read, so the problem seems to be associated
with reading the raw bitstream via the /dev/ device entry.
If the image created by the dd command was mounted (on a CD after burning or
via loopback) at least one file per CD was unreadable (I'm guessing it's the
files at the end of the CD occupying those last 44 sectors).
I tried this in two different 2.4.18 boxes with the same result. A 2.2.19
box with an IDE CDROM read the 64016 sectors with no trouble. A closing I/O
error was reported, but the full 64016 were successfully transferred to the
output file.
A *SCSI* CD writer drive under 2.4.18 also read the full 64016 sectors like
2.2.19+IDE drive did.
Thus it seems that there is a problem accessing the last few sectors (44 in
our case above) of a cdrom directly when 2.4.18 is used with an IDE CD
drive.
Is there any way around this problem? Is it a known problem and is a fix
available?
Please CC me any replies since I read the list via a web archive which has
missed individual postings in the past. Thanks.
Best regards
jonathan
--
* Jonathan Woithe jwoithe@physics.adelaide.edu.au *
* http://www.physics.adelaide.edu.au/~jwoithe *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so" **
* "...you wouldn't recognize a subtle plan if it painted itself purple and *
* danced naked on a harpsichord singing 'subtle plans are here again'" *
next reply other threads:[~2002-09-02 5:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-02 5:27 Jonathan Woithe [this message]
2002-09-03 7:19 ` Jonathan Woithe
2002-09-03 7:35 ` Erik Andersen
2002-09-05 0:39 ` Jonathan Woithe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200209020527.g825RHd07114@sprite.physics.adelaide.edu.au \
--to=jwoithe@physics.adelaide.edu.au \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®