On Mon, 25 Aug 2014 Alan Stern wrote: > > On Mon, 25 Aug 2014, Alfredo Dal Ava Junior wrote: > > That's right. I don't know why Windows behaves that way.
Please look this output from diskpart (Windows): DISKPART> list partition Partition ### Type Size Offset ------------- ---------------- ------- ------- Partition 1 Primary 3726 GB 17 KB DISKPART> list disk Disk ### Status Size Free Dyn Gpt -------- ------------- ------- ------- --- --- Disk 0 Online 298 GB 0 B * Disk 1 Online 1678 GB 0 B * DISKPART> select disk 1 Disk 1 is now the selected disk. DISKPART> list partition Partition ### Type Size Offset ------------- ---------------- ------- ------- Partition 1 Primary 3726 GB 17 KB > > Could we do the same? Would be possible to signalize to upper layers > > that capacity is not accurate (or return zero) on this device, and > > tell GPT handlers to bypass it's partition_size vs disk size > > consistency check? > > There is no way to do this, as far as I know. But I'm not an expert in this > area. > Maybe you can figure out a way to add this capability. > > (But then what happens if the size stored in the partition table really is > larger > than the disk's capacity?) It's the first time I touch this code, but I will learn from the code and try to find it out... but still in hope to find a clean solution... If size stored on partition table is really larger than disk, my guess it will cause I/O errors, and that some disks may get crazy like you pointed. Do you think disk could cause kernel instability? I think it is acceptable if no consequences to kernel stability, since it is a "specific-device" workaround. []'s Alfredo -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
