January 3, 201115 yr From Hitachi (PDF file) This is becoming a higher priority & I'll have a couple of these next week.
January 3, 201115 yr Interesting list of motherboards, controllers, and drivers that support 3T drives. List is encouraging! Goes back to ICH5! Unfortunately the list is far from complete, and I don't think you can infer that an item not on the list is incompatible. For example, the Adaptec 1420SA is listed as compatible. But the Adaptec 1430SA is not mentioned at all. I don't think this means the 1430SA is incompatible. Rather I'm pretty sure that if the 1420SA is compatible, other Adaptec controllers of similar vintage are supported as well. No mention of currently popular SuperMicro SAS controller. There is also no mention of specific products found to be incompatible.
January 30, 201115 yr I just wanted to bundle some additional information related to these High-Capacity Drives. The latest Linux Kernel 2.6.37 release includes changes for NATIVE 4K drive support in libata. The interesting bit from the commit comment is: Lastly, the patch has been tested with a native 4K 'Engineering Sample' drive provided by Hitachi GST. So at least Hitachi is working on drives that report native 4K sectors instead of emulating 512 byte sectors. Looking at the actual changes, it seems libata was hardcoded to use 512byte sectors before kernel 2.6.37. Hopefully unRAID 5.1 can rebase on Linux 2.6.37 to also include support for these new native 4K drives.
January 30, 201115 yr Author I just wanted to bundle some additional information related to these High-Capacity Drives. The latest Linux Kernel 2.6.37 release includes changes for NATIVE 4K drive support in libata. The interesting bit from the commit comment is: Lastly, the patch has been tested with a native 4K 'Engineering Sample' drive provided by Hitachi GST. So at least Hitachi is working on drives that report native 4K sectors instead of emulating 512 byte sectors. Looking at the actual changes, it seems libata was hardcoded to use 512byte sectors before kernel 2.6.37. Hopefully unRAID 5.1 can rebase on Linux 2.6.37 to also include support for these new native 4K drives. I'd be really surprised if libata was the only subsystem with 512-byte hard coded sector size!
January 30, 201115 yr BRiT, that's very interesting. That's the first documented proof of an exposed 4k sector drive I've seen. Well, it's not 100% proof but they have no reason to make that up. Peter
January 30, 201115 yr Interestingly, on the Linux NAS front, Buffalo updated their LS-XHL firmware a while back to support 4k sector drives. I'm guessing it's because they use Samsung drives and were switching from F3 to F4 drives: http://forum.buffalo.nas-central.org/viewtopic.php?f=69&t=22070
January 30, 201115 yr I'd be really surprised if libata was the only subsystem with 512-byte hard coded sector size! So would I. Any programmer who did it dynamically prior to 2010 was WAY ahead of his/her time, and probably had no friends at all.
January 30, 201115 yr No mention of currently popular SuperMicro SAS controller. AOC-SASLP-MV8 has Marvell 88SE6480. Marvell 88SE61x1 is supported (without * which indicates the drives might be 2Tb in your system). Although a large number of chipsets show support (as said, even ICH5), what use is this if it limits the drive to 2Tb...
January 30, 201115 yr Although a large number of chipsets show support (as said, even ICH5), what use is this if it limits the drive to 2Tb... The Hitachi compatibilty guide clearly states that the ICH5 (and many others) DO support the 3T drives using the Microsoft drivers. This means that the hardware / firmware is capable. Drivers for Linux would just need to be updated. Am I reading this wrong?
January 30, 201115 yr Author It will be interesting to see how this plays out in the industry. Due to limitations in the MBR (that I know about all too well now), the largest drive that can be supported with 512-byte sectors is 2TB. In theory, you can use MBR with 4K sector size (or any other size) and support drives up to 8TB, because MBR doesn't record anything about the size of sectors. But I think someone must have done a study and concluded that probably more software would be broken by using MBR with anything other than 512-byte sectors, that no one dare propose such heresy! It's always easier to upgrade than it is to retrofit, so it looks like drives larger than 2TB will have to use GPT scheme instead of MBR anyway - and it's wise to do so now so that 8TB doesn't become the next barrier in the future. But GPT has lots more bits for holding sector counts - so there's really no reason to change the exported sector size from 512 to 4K. As long as new code which uses GPT keeps the start of partitions on physical sector size boundaries, it's all good (something else I know all to well now). So I can see why hdd manufacturers want to move to 4K physical, but there's really no reason they need to move away from 512 logical, especially considering they all had to write the code to handle odd-sector access anyway.
January 31, 201115 yr Although a large number of chipsets show support (as said, even ICH5), what use is this if it limits the drive to 2Tb... The Hitachi compatibilty guide clearly states that the ICH5 (and many others) DO support the 3T drives using the Microsoft drivers. This means that the hardware / firmware is capable. Drivers for Linux would just need to be updated. Am I reading this wrong? It says : Note: For items marked with *, the accessible capacity of a 3TB drive may be limted to 2TB depending on how your system is configured. So we can't conclude anything from this doc as to the level of support, and wether the chipset or driver/os is the culprit. From the doc I can deduct Hitachi seems to think that a 3Tb drive with usable 2Tb is a 'supported' configuration, as the drive itself is functioning. The Hitachi site (linked in the PDF) shows other information (OS level), but does not mention chipsets. Also the Mac OSX support using 'the latest Microsoft drivers' is a bit odd
Archived
This topic is now archived and is closed to further replies.