Y
Yousuf Khan
Arno wrote:
> In comp.sys.ibm.pc.hardware.storage Yousuf Khan wrote:
>> Arno wrote:
>>> Maybe Windows thinks that you cannot possibly want to span on
>>> removable devices? It has this habit of thinking it knows
>>> what you do and do not want but at the same time is far too
>>> stupid to pull it off.
>
>> Yeah, it looks like the case here. The technote says Microsoft doesn't
>> support this on USB or Firewire drives.
>
> Well, it does make some sense. Personally, I think the idea
> of "removable" devices is fundamentally flawed, and mounting and
> umounting as in Linux/unix is the far better approach. Bit apparently
> MS customers just yank out devices if it is mechanically possible.
> That could be a deisaster if the devices are RAIDed/
>
>
>>> Incidentially the 800GB seems to be a problem with the enclosure,
>>> there is no limit (that I know of) at 39.5 bit adress length.
>>> Maybe give this pice of trash back?
>
>> Is it possible that there is a BIOS limitation, beyond 2TB? The
>> motherboard I'm using is a rather plain desktop mobo, it may not be
>> expecting such huge devices to join in?
>
> USB does not go over the BIOS, at least not in Linux. 2TB is 41
> bit. No limit on byte level I can see. Number of sectors would
> be 32. Ah, I think I see the problem. USB is using the storage
> SCSI command set. It has either 32 bit or 64 bit for the sector
> number. If the enclosure is resonably current, it should
> support 64 bit sector numbers. Linux need compiled in kernel
> support for large block devices to be able to handle block
> devices > 2TB. This support has been there for some years, but
> may be missing from your kernel. The config option is
> CONFIG_LBDAF and found under "enable block layer" in 2.6.32.
I asked the same question to Janos Mathe, the developer of HD Sentinel,
he believes that the USB-SATA chipset is to blame here. These are his words:
> It seems it is an overflow issue in addressing.
> I'm sure it is not related to BIOS as the BIOS would only cause troubles
> on disks which are under its control (for example if they were connected
> to the motherboard and you'd try to boot from it). USB devices are controlled by the USB drivers of the OSes (Windows/Linux).
>
> I suspect the problem is related to the JMicron USB-ATA bridge which
> translates the USB packets to ATA commands sent to the SATA drives.
> I quickly checked the specs of this chip at http://www.jmicron.com/PDF/JM20336/JM20336.pdf
> but as I see, JMicron do not mention the maximum drive capacity to be used.
> However, I think at the time of release (2005) they were not prepared
> for such BIG concatenated array and that's why the LBA addressing wraps around over 2 TB.
> If I can help, please let me know.
So it looks like there may be nothing that can be done here.
Yousuf Khan
> In comp.sys.ibm.pc.hardware.storage Yousuf Khan wrote:
>> Arno wrote:
>>> Maybe Windows thinks that you cannot possibly want to span on
>>> removable devices? It has this habit of thinking it knows
>>> what you do and do not want but at the same time is far too
>>> stupid to pull it off.
>
>> Yeah, it looks like the case here. The technote says Microsoft doesn't
>> support this on USB or Firewire drives.
>
> Well, it does make some sense. Personally, I think the idea
> of "removable" devices is fundamentally flawed, and mounting and
> umounting as in Linux/unix is the far better approach. Bit apparently
> MS customers just yank out devices if it is mechanically possible.
> That could be a deisaster if the devices are RAIDed/
>
>
>>> Incidentially the 800GB seems to be a problem with the enclosure,
>>> there is no limit (that I know of) at 39.5 bit adress length.
>>> Maybe give this pice of trash back?
>
>> Is it possible that there is a BIOS limitation, beyond 2TB? The
>> motherboard I'm using is a rather plain desktop mobo, it may not be
>> expecting such huge devices to join in?
>
> USB does not go over the BIOS, at least not in Linux. 2TB is 41
> bit. No limit on byte level I can see. Number of sectors would
> be 32. Ah, I think I see the problem. USB is using the storage
> SCSI command set. It has either 32 bit or 64 bit for the sector
> number. If the enclosure is resonably current, it should
> support 64 bit sector numbers. Linux need compiled in kernel
> support for large block devices to be able to handle block
> devices > 2TB. This support has been there for some years, but
> may be missing from your kernel. The config option is
> CONFIG_LBDAF and found under "enable block layer" in 2.6.32.
I asked the same question to Janos Mathe, the developer of HD Sentinel,
he believes that the USB-SATA chipset is to blame here. These are his words:
> It seems it is an overflow issue in addressing.
> I'm sure it is not related to BIOS as the BIOS would only cause troubles
> on disks which are under its control (for example if they were connected
> to the motherboard and you'd try to boot from it). USB devices are controlled by the USB drivers of the OSes (Windows/Linux).
>
> I suspect the problem is related to the JMicron USB-ATA bridge which
> translates the USB packets to ATA commands sent to the SATA drives.
> I quickly checked the specs of this chip at http://www.jmicron.com/PDF/JM20336/JM20336.pdf
> but as I see, JMicron do not mention the maximum drive capacity to be used.
> However, I think at the time of release (2005) they were not prepared
> for such BIG concatenated array and that's why the LBA addressing wraps around over 2 TB.
> If I can help, please let me know.
So it looks like there may be nothing that can be done here.
Yousuf Khan
