> From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > > We really don't want to make the decision within the kernel of whether > we believe the partition size or the disk capacity. For these disk > problems we need it to be the former, but if we choose that always, > we'll get weird results on mispartitioned devices. > > The usual rule is no policy in the kernel and which to choose is policy, > so just export the knob (as Alan's patch does) and then let userspace > decide. I can see some significant advantages to setting up the hack in user-space, above the architectural ones: - We can get the user to confirm how big we think the disk is -- because its size is printed on the label of the disk. And if the partition table is unreadable in some way, the user can manually enter the size. - We can warn the user that the data path to his disk is deficient in not supporting which ever SCSI request, so that he knows to upgrade his hardware. There is one thing that seems like it might be a problem: We have to ensure that the SCSI driver can read the partition tables (in the standard locations) even if it doesn't know how big the disk is. Which leads me to wonder what happens if one reads /dev/sdX until one hits end-of file. People have written that we don't want to read the disk from locations beyond end-of-data because some disks react badly to out-of-range reads. But if that is so in general, there would be problems simply copying /dev/sdX. (Indeed, if all disks gave a proper error for out-of-range reads, a bisection search would find the size of the disk easily enough.) Dale -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
