more information on my trouble reading CDROM's with hdc=ide-cd. Anybody else?

[David Zeuthen]

On Thu, 2004-11-18 at 07:55 -0500, Alan Cox wrote:
> Perhaps. The problem is that some of the other file system code looks
> at the _end_ of the disk. Unfortunately CD-R doesn't have an "end" it 
> sort of tails out into no-mans land. 

Really? Because using the BLKGETSIZE64 ioctl() on the device file we get

 667502592 for FC3-i386-gold-disc3
 668524544 for FC3-i386-gold-disc2

Hmm; the ISO files are this size

-rw-r--r--    3 root     root     668520448 Nov  3 17:07 FC3-i386-disc2.iso
-rw-r--r--    3 root     root     667498496 Nov  3 17:08 FC3-i386-disc3.iso

which, respectively, is exactly 4096 bytes (two blocks of 2k) less than
what the ioctl() gives. I wonder why that is; maybe it's just a wild
goose chase, just curious.

> Most drives politely handle such
> requests, some don't. The ide-scsi driver has the needed magic to work 
> around some of this, ide-cd lacks it.
> 
>
> The HAL fix I guess would be to only try iso9660/udf on CD-R/CD-RW media,

Yeah, that would screw some other users though, e.g. people actually put
HFS/HFS+ (Apple install media) and ext2 (e.g. DVD-RAM) on optical discs.

I suppose a better fix is to only look for filesystems that doesn't
require looking at the end of the disk. That would indeed also include
HFS/HFS+ (superblock is at 0x0200 offset like ext3).

Reason we look at the end of the disk is that it's smart to probe for
RAID/LVM1/LVM2 (which has the superblock at the end of the disk) before
anything else as we otherwise might have a false positive. Just think of
the havoc that adding /dev/sda1 being a RAID mirror member and g-v-m
mounting that because it was added to the /etc/fstab. That would not be
nice.

> but it might ultimately be better if we can fix it kernel side.
> 

Yah. Is that hard, e.g. can it be done within a reasonable time frame?
I'd hate to put yet another special case into hal to work around a
kernel bug.

Cheers,
David