md5sum'ing block devices
Loris Caren
on most CDROM drives whereas if I mount the same CD and then do the
md5sum on all files found, it works?; I get sector read errors if
I do md5sum /dev/cdrom but don't if I mount /dev/cdrom /mnt;
find /mnt -type f -exec md5sum {} \; OK, this isn't reading quite
as much of the disk and certainly in a different order, but it proves that
every byte can be read. NB: I've got one SCSI CDROM unit which always works
fine, giving a sensible signature for the cd image and no errors.
Surely, all mount does is put a layer of file-system 'understanding'
over the raw stream of bytes available by reading /dev/cdrom?
Is there error correction inherent in CD media being used by the block
device driver?
Is there (any more) error correction inherent in (say) an ISO9660
file system being used by the VFS layer?
The other peculiarity that I notice is that doing md5sum (or dd) of
a floppy or hard disk examines the full media, irrespective of what data is
on it.
However, the /dev/cdrom seems different in ignoring any unused capacity
on the media - doing dd if=/dev/cdrom of=/dev/null is much quicker if the
CD installed is only 50M used capacity, rather than if a full 650M CD
is tried. Can anybody offer an explanation for this apparent
inconsistency?
Nick Lockyer
650M image, and the chances are that the entire CD was not written.
You are reading the phyical device with /dev/cdrom which is below the file
system layer.
Loris Caren <lo...@caren.demon.co.uk> wrote in message
news:988631124.14081.0...@news.demon.co.uk...
Kasper Dupont
When using a CD there are more logical layers than
just blockdevice and filesystem.
/dev/cdrom is below the filesystem layer, but above
the layer implementing tracks. Some of the
specifications used span over multiple different
layers making the entire design a mess.
Here are a few hints that will make more things
work like expected:
Don't mix CD/DA and ROM tracks one the same CD.
Don't write more than one track on a CD-ROM, some
offsets used in the ISO filesystem is meassured
from the start of the CD not the start of the track,
on the first track this is the same and it works
like expected.
Don't use multisession CD's
Record disks with DAO (Disk at once) instead of
TAO (Track at once). Using TAO can make the end of
tracks unreadable.
From the original description of the problem I
would guess that the problem is that the disk is
recorded with TAO. Notice that reading every byte
of every file on the CD does not necesarrily read
every byte of the disk. The filesystem does not
have to use the entrie block device, when recording
a CD it is common practice to pad with a number of
zero bytes at the end of the disk. Cdrecord has an
option to pad with 15 sectors (30KB). This padding
prevents problems reading files from a TAO disk,
because the unreadable part of the disk is from my
experience at most 8 sectors.
--
Kasper Dupont
Loris Caren
I've found a recipe that works:-
1. mount the CD
2. do a df and note the number of 1k blocks consumed
3. umount the CD
4. dd if=/dev/cdrom bs=1k count=n | md5sum (where n is from step 2).
This works on all the pressed CDs and home grown CDRs that I've tried on
all the drives I've got. So it looks as if I can now offer a CDR
validation service to my WinDoze collegues who have been reliant on just
looking at the directory structure.
However, I'm still baffled how reading beyond the end of the data can work
perfectly on one drive but not on another, same kernel, same driver (both
SCSI).
phil-new...@ipal.net
Apparently devices do vary in how they handle sectors and tracks beyond
the actually recorded data. Recording actually puts some extra padding
in there. That's needed if another session is to be recorded. And for
some reasons it's needed even if not.
I've noted a wide difference of behaviour between IDE and SCSI. I have
3 IDE CDROM drives and 2 SCSI CDROM drives. I get consistent results
with the SCSI ones, but wild and crazy results from the IDE ones.
--
-----------------------------------------------------------------
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| phil-...@ipal.net | Texas, USA | http://phil.ipal.org/ |
-----------------------------------------------------------------
Tim Shoppa
> However, I'm still baffled how reading beyond the end of the data can work
> perfectly on one drive but not on another, same kernel, same driver (both
> SCSI).
CD-R's (and even some pressed CD's) often have a few to several more
"almost good" 2048-byte blocks past the intended end-of-data point.
These "almost good" blocks may read on some drives, but not on others.
Even on the same drive you can sometimes get different results,
because this is nasal demon territory.
The solution you found - finding the originally-intended end-of-data
and then using dd to make sure you don't go beyond it - is the
preferred one.
Tim.