RES: RES: AS2105-based enclosure size issues with >2TB HDDs

Alfredo Dal Ava Junior
2014-08-25T20:14:20Z

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-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html