SSD Posted February 20, 2011 Share Posted February 20, 2011 I am wondering if it is possible to buy some 3Tb drives, downsize them to 2Tb (or 2.2Tb) for now, and then use them in my array. To buy 3 2TB 7200 RPM Hitachi drives would cost $110 each = $330. To buy 2 3TB 7200 RPM Hitachi drives would cost $180 each = $360. Same capacity. I would pay this $30 premium. When unRAID 5.0 b5 comes out, I'd be able to help test out the 3Tb formatting. Is this doable? I remember reading that you could create an HPA "on purpose" to make the drive look smaller to unRAID, but with all of the HPA issues with the newer releases, I am unsure if this is viable. If not, is there some other tricky way to fool unRAID into thinking these disks are smaller than their true capacity. BTW, I plan to use these in a new "beta" build and will have all data 100% replicated on my current "production" array until the new build has been thoroughly tested. Thanks! Quote Link to comment
ohlwiler Posted February 20, 2011 Share Posted February 20, 2011 I believe Seatools for DOS has this capability. They specifically mention the ability to resize disks for creating equal size disks for RAID arrays so it sounds like it has the capability. http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=201271 Quote Link to comment
Joe L. Posted February 20, 2011 Share Posted February 20, 2011 I am wondering if it is possible to buy some 3Tb drives, downsize them to 2Tb (or 2.2Tb) for now, and then use them in my array. To buy 3 2TB 7200 RPM Hitachi drives would cost $110 each = $330. To buy 2 3TB 7200 RPM Hitachi drives would cost $180 each = $360. Same capacity. I would pay this $30 premium. When unRAID 5.0 b5 comes out, I'd be able to help test out the 3Tb formatting. Is this doable? I remember reading that you could create an HPA "on purpose" to make the drive look smaller to unRAID, but with all of the HPA issues with the newer releases, I am unsure if this is viable. If not, is there some other tricky way to fool unRAID into thinking these disks are smaller than their true capacity. BTW, I plan to use these in a new "beta" build and will have all data 100% replicated on my current "production" array until the new build has been thoroughly tested. Thanks! I think it will work... You can probably use hdparm -N pXXXXXXXXXX to do the re-size. You'll get a big jump on all of us in knowing if your disk controller can handle the large disks, even before re-sizing and partitioning them. Quote Link to comment
SSD Posted February 20, 2011 Author Share Posted February 20, 2011 I am wondering if it is possible to buy some 3Tb drives, downsize them to 2Tb (or 2.2Tb) for now, and then use them in my array. To buy 3 2TB 7200 RPM Hitachi drives would cost $110 each = $330. To buy 2 3TB 7200 RPM Hitachi drives would cost $180 each = $360. Same capacity. I would pay this $30 premium. When unRAID 5.0 b5 comes out, I'd be able to help test out the 3Tb formatting. Is this doable? I remember reading that you could create an HPA "on purpose" to make the drive look smaller to unRAID, but with all of the HPA issues with the newer releases, I am unsure if this is viable. If not, is there some other tricky way to fool unRAID into thinking these disks are smaller than their true capacity. BTW, I plan to use these in a new "beta" build and will have all data 100% replicated on my current "production" array until the new build has been thoroughly tested. Thanks! I think it will work... You can probably use hdparm -N pXXXXXXXXXX to do the re-size. You'll get a big jump on all of us in knowing if your disk controller can handle the large disks, even before re-sizing and partitioning them. Can you help with the xxxxxxxxxx? I want to compute this for a 2TB partition (exact same size as normal 2TB drives), and for a near max 2.2TB MBR partition (don't have to get it to the exact sector, but something close but safely under). How would I figure this out? Yes, I would be able to test with a number of controllers that I have: SuperMicro C2SEE-O MB IBM Br10i controller Hong Kong cheap PCIe x1 controller (if they ever get here) Adaptec 1430sa controller SuperMicro AOC-SASLP-MV8 SuperMicro AOC-SAT2-MV8 Promise TX2 controller (2 eSata ports) ASUS P5B VM DO MB JMicron JMB383 (on the ASUS MB) Quote Link to comment
Joe L. Posted February 20, 2011 Share Posted February 20, 2011 I am wondering if it is possible to buy some 3Tb drives, downsize them to 2Tb (or 2.2Tb) for now, and then use them in my array. To buy 3 2TB 7200 RPM Hitachi drives would cost $110 each = $330. To buy 2 3TB 7200 RPM Hitachi drives would cost $180 each = $360. Same capacity. I would pay this $30 premium. When unRAID 5.0 b5 comes out, I'd be able to help test out the 3Tb formatting. Is this doable? I remember reading that you could create an HPA "on purpose" to make the drive look smaller to unRAID, but with all of the HPA issues with the newer releases, I am unsure if this is viable. If not, is there some other tricky way to fool unRAID into thinking these disks are smaller than their true capacity. BTW, I plan to use these in a new "beta" build and will have all data 100% replicated on my current "production" array until the new build has been thoroughly tested. Thanks! I think it will work... You can probably use hdparm -N pXXXXXXXXXX to do the re-size. You'll get a big jump on all of us in knowing if your disk controller can handle the large disks, even before re-sizing and partitioning them. Can you help with the xxxxxxxxxx? I want to compute this for a 2TB partition (exact same size as normal 2TB drives), and for a near max 2.2TB MBR partition (don't have to get it to the exact sector, but something close but safely under). How would I figure this out? Yes, I would be able to test with a number of controllers that I have: SuperMicro C2SEE-O MB IBM Br10i controller Hong Kong cheap PCIe x1 controller (if they ever get here) Adaptec 1430sa controller SuperMicro AOC-SASLP-MV8 SuperMicro AOC-SAT2-MV8 Promise TX2 controller (2 eSata ports) ASUS P5B VM DO MB JMicron JMB383 (on the ASUS MB) Use hdparm -N to get the drive's reported "max" number of sectors and divide by three? It will be close. Just make sure you use a number divisible by 4 otherwise unRAIDs math might get the usable size wrong. If the disk is reporting 512 byte sectors to hdparm the 3TB drive with the HPA should end up at 3907029168 (that is what is reported on a 2TB drive with no HPA) Joe L. Quote Link to comment
SSD Posted February 25, 2011 Author Share Posted February 25, 2011 Got 2 of them sitting in my hot little hands. What should I do to test compatibility? I think I have a handle on how to make them into 2.2T drives for temporary use until Tom has the 3T support ready, but want to run any tests people request before I do all that. Quote Link to comment
Joe L. Posted February 25, 2011 Share Posted February 25, 2011 Got 2 of them sitting in my hot little hands. What should I do to test compatibility? I think I have a handle on how to make them into 2.2T drives for temporary use until Tom has the 3T support ready, but want to run any tests people request before I do all that. fdisk -l -u /dev/sdX hdparm -N /dev/sdX smartctl -d ata -a /dev/sdX Quote Link to comment
SSD Posted February 27, 2011 Author Share Posted February 27, 2011 Ok - I have my new box partially assembled, and have installed the 2 3T drives. The motherboard is the SuperMicro C2SEE-O. I have hooked up one of the 3T drives to the BR10i controller, running 6.30 BIOS. I have hooked up the other 3T drives to the Motherboard (ICH10). A couple of interesting observations: 1. The BR10i drive is being recognized as 2.2T, but the one on the motherboard is showing as 3T. 2. unRAID allows me to assign the disks to the "array" (it is a brand new box - disks are assigned as disk1 and disk2, no parity). I did not try to start the array / format the disks. Should I hook them both up to the motherboard and try to format them? Here are the requested commands. Anything else? fdisk -lu /dev/sda (motherboard drive) Disk /dev/sda: 3000.6 GB, 3000592982016 bytes 255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/sda doesn't contain a valid partition table fdisk -lu /dev/sdh (BR10i drive) Disk /dev/sdh: 2199.0 GB, 2199023254528 bytes 255 heads, 63 sectors/track, 267349 cylinders, total 4294967294 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/sdh doesn't contain a valid partition table hdparm -N /dev/sda (motherboard) /dev/sda: max sectors = 5860533168/5860533168, HPA is disabled hdparm -N /dev/sdh (BR10i) /dev/sdh: max sectors = 5860533168/5860533168, HPA is disabled smartctl on /dev/sda (motherboard) smartctl 5.39.1 2010-01-28 r3054 [i486-slackware-linux-gnu] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: Hitachi HDS723030ALA640 Serial Number: MK0311YHG2Xxxx Firmware Version: MKAOA3B0 User Capacity: 3,000,592,982,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is: Sat Feb 26 22:03:18 2011 Local time zone must be set--see zic m SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x80) Offline data collection activity was never started. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (28319) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 255) minutes. SCT capabilities: (0x003d) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0 2 Throughput_Performance 0x0005 100 100 054 Pre-fail Offline - 0 3 Spin_Up_Time 0x0007 100 100 024 Pre-fail Always - 0 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 3 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 100 100 020 Pre-fail Offline - 0 9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 0 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 3 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 3 193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 3 194 Temperature_Celsius 0x0002 240 240 000 Old_age Always - 25 (Lifetime Min/Max 23/32) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. Quote Link to comment
Joe L. Posted February 27, 2011 Share Posted February 27, 2011 Interesting... Tom did say he changed some of the values types in the config/super.dat file to be able to handle the larger disks. You won;t know how it reacts until you assign the disks to the array. You are treading on new ground... Obviously, your add-on controller is not compatible... not without a firmware update of its own. Joe L. Quote Link to comment
BRiT Posted February 27, 2011 Share Posted February 27, 2011 I'm curious how they show up on the BR10i with the 1.32.00 firmware with 6.34.00 BIOS combo. Quote Link to comment
Joe L. Posted February 27, 2011 Share Posted February 27, 2011 We know for certain the bytes in the MBR that define the partition size are insufficient to handle a partition greater than 2.2TB. I expect the preclear script to choke on the task of creating the partition. Quote Link to comment
lionelhutz Posted February 27, 2011 Share Posted February 27, 2011 It would be curious to know it unRAID would just create a 2.2T partition and use it. I assume you'll just try assigning and starting at some point? Peter Quote Link to comment
SSD Posted February 27, 2011 Author Share Posted February 27, 2011 I'm curious how they show up on the BR10i with the 1.32.00 firmware with 6.34.00 BIOS combo. It is interesting that the BR10i mounted drive is showing the same sectors (look at my two hdparm commands) as the ICH10, but in fdisk is showing only 2.2T. I am wondering if the BR10i Linux driver, and not the controller itself, is limiting drives to 2.2T. I will try and update the BIOS. It would be curious to know it unRAID would just create a 2.2T partition and use it. I assume you'll just try assigning and starting at some point? Peter Yes - that is the plan. Although was hoping to see 5.0b5 posted to see if the 3T feature was added. In order to do what you suggest, I would need to hook them both to the MB and run this command on each one: hdparm -N pXXXXXXXXXX /dev/sdX and I believe that xxxxxxxxxx should be 4294963168. Joe L., can you help me confirm that's a good number? I tried to come up with something that ends with 168, and that unRAID would end its count with 552. Quote Link to comment
lionelhutz Posted February 27, 2011 Share Posted February 27, 2011 No, I was meaning to just assign the disks and start the array. No hdparam commands. If you get working 2.2T partitions then you would just clear the mbr and rebuild the disk to 3T in a future version of unRAID. I would think the chances of them just working at 2.2T when connected to the BR10i are fairly high but you might end up with something like a 700gig partition when connected to the motherboard. Peter Quote Link to comment
SSD Posted February 27, 2011 Author Share Posted February 27, 2011 Joe L. already said that preclear wouldn't like it. And I don't want to depend on the oddities of the way one controller works. I think the hdparm command would be the smart way to do this. Creating my own HPA. You are right, after 3T support is in place, I should be able to rebuild parity and then rebuild the data drive. Quote Link to comment
lionelhutz Posted February 27, 2011 Share Posted February 27, 2011 I was just curious what happens when you just hit the start and format buttons. unRAID creates and uses the primary partition so if it is created at 2.2T then you're OK with the current unRAID. You'll be relying on the controllers and such working just as much at 3T. Peter Quote Link to comment
lionelhutz Posted February 27, 2011 Share Posted February 27, 2011 Something I wanted to add before. If the preclear script only does the first 2T with a HPA then it doesn't test the whole drive. I would run it on the whole drive and let it read and write to the whole drive. If it only fail the partition creation, so what? You just have to let unRAID partition them. Pter Quote Link to comment
SSD Posted February 27, 2011 Author Share Posted February 27, 2011 Good point. It would be good to let preclear test out the entire drive. Joe L. - think that would work? Quote Link to comment
SSD Posted March 1, 2011 Author Share Posted March 1, 2011 I am running preclears on the 2 3T drives + 1 2T Seagate LP (refurb from RMA). The good news is preclear did not choke setting up the MBR. It didn't perform a miracle, but it didn't crash! Here is the result of the fdisk from one of the 3T and from the 2T (for comparison). I don't know what that "+" means at the end on the # of blocks in the 3T disk partition. But I believe that the partition is pretty small. 3T DISK: Disk /dev/sda: 3000.6 GB, 3000592982016 bytes 255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 64 366283382 183141659+ 0 Empty Partition 1 does not end on cylinder boundary. 2T DISK: Disk /dev/sdd: 2000.4 GB, 2000398934016 bytes 255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdd1 64 3907029167 1953514552 0 Empty Partition 1 does not end on cylinder boundary. Quote Link to comment
lionelhutz Posted March 1, 2011 Share Posted March 1, 2011 That is an odd partition size, somewhere around 187gig if I calculated that correctly. Peter Quote Link to comment
SSD Posted March 1, 2011 Author Share Posted March 1, 2011 That is an odd partition size, somewhere around 187gig if I calculated that correctly. Peter Yes - about 10% of the size of the 2T drive. I would have expected about 800G, but doesn't matter. Below are the steps I plan to take to add these drives to my array. Input is welcome: 1. I will have to zero out the MBR and partition table of each of the 3T drives (dd if=/dev/zero count=200 of=/dev/sdX ) 2. Make the usable space 2.2T on each of the 3T drives (hdparm -N p4294963168 /dev/sdX) 3. Reboot (not sure if necessary) 4. Reset the array configuration 5. Add the 2 2T disks as parity and disk1 (add other disks, which were formatted with unRAID) 6. Start the array. unRAID should partition the new disks and start building parity. Only the 3T disk should appear unformatted - the rest are all already loaded with data and should just be included in the parity calculation. Am I missing anything? Quote Link to comment
SSD Posted March 4, 2011 Author Share Posted March 4, 2011 That is an odd partition size, somewhere around 187gig if I calculated that correctly. Peter Yes - about 10% of the size of the 2T drive. I would have expected about 800G, but doesn't matter. Below are the steps I plan to take to add these drives to my array. Input is welcome: 1. I will have to zero out the MBR and partition table of each of the 3T drives (dd if=/dev/zero count=200 of=/dev/sdX ) 2. Make the usable space 2.2T on each of the 3T drives (hdparm -N p4294963168 /dev/sdX) 3. Reboot (not sure if necessary) 4. Reset the array configuration 5. Add the 2 2T disks as parity and disk1 (add other disks, which were formatted with unRAID) 6. Start the array. unRAID should partition the new disks and start building parity. Only the 3T disk should appear unformatted - the rest are all already loaded with data and should just be included in the parity calculation. Am I missing anything? I was able to successfully preclear the 3T drive, and reduce the capacity to 2.2T, assign it as a cache drive in my unRAID 4.7 production array, and copy files to it. It is running right now. This is on a 2-port PCI card. Since the array is literally overflowing with disks at the moment (some destined to stay in this "backup" server, and others destined to move into the new server), it is the only open port I have open at the moment! Prior to this, I tried my other 3T drive (no HPA - full 3T capacity) on the same port (with unRAID 5.0b4). I tried to assign it to the cache slot. Although it showed the drive and allowed me to make the assignment, when I went back to the main page it said there was no disk assigned to cache. Since I was able to assign 3T drives under 5.0b4 on another machine using the ICH10 controller, I have to assume that it is either an issue with the card or an issue with the driver. I will do more playing around with the 3T drive on the various controllers in my production unRAID server (using separate memory stick and never starting the array with any of my production disks assigned to slots) to see if I can find another controller than seems happy with the 3T capacity. I will also upgrade my BR10i to the latest firmware that BRiT has posted to see if it is happier about recognizing the full capacity than the 6.30 version I am currently flashed with. I was doing some reserach on controller support for larger disks. My understanding is that LBA 28, the original standard, had a 137.4 gigabyte limit, and that the upgrade was to an LBA 48 standard, which allows a generous 144 petabytes (144,000 TB) capacity. So 3T is nothing! So I am not sure why I am hitting 2T limitations on the controllers. Maybe the firmware is based on a false assumption that life will not extend beyond the 2.2T limit of MBR, or maybe the card is fine but the drivers are limited. Whichever it is, at the moment I am only sure of 6 ports (motherboard) that will support 3T drives once Tom gets the supprt into unRAID. Quote Link to comment
SSD Posted March 5, 2011 Author Share Posted March 5, 2011 I completed my testing of the 3T drives on a number of motherboards / controllers. Motherboard: SuperMicro C2SEE-O Motherboard (ICH10) P5B VM DO Motherboard (ICH8DO) P5B VM DO (2 Jmicron Ports) PCIe: Hong Kong $1.99 Jmicron Controller (x1, 2 port) Adaptec 1430sa (x4, 4 port) SuperMicro AOC-SASLP-MV8 (x4, 8 port) (.21 firmware) IBM BR10i (x8, 8 port) PCI / PCIX: SuperMicro AOC-SAT2-MV8 (8 port) Promise TX2 (2 port eSATA) I ran the following commands: fdisk -lu cat /proc/partitions hdparm -N And I tried to assign a 3T disk to disk1 and to the cache slots using 5.0 beta4. On ALL of the controllers except the BR10i, the controllers got consistant results and recognized the drive as being 3T. I was able to assign it to disk1 in unRAID. I was not able to assign it to the cache drive (it assigned but when I went to the main page, it showed not installed). I think this is an unRAID bug. Important note: just becuase unRAID saw the disk as 3T and allowed me to assign it to a disk slot, that does NOT mean unRAID supports 3T drives. That support should be forthcoming soon, based on the Roadmap. The only way to use a 3T drive in an array today is to follow the process described earlier in this thread and use it at 2.2T instead of 3T capacity. Starting with unRAID 5.0 beta 7 unRAID supports 3T drives. One small anomally, on the SuperMicro AOC-SASLP-MV8, the hdparm -N command returned this ... max sectors = 5860533168 / 5284784(5860533168?), HPA setting seems invalid (buggy kernel device driver?) rather than max sectors = 5860533168 / 5860533168, HPA is disabled This should not cause any operational problems IMO, but thought it worth noting. The one odd ball was the BR10i. It sees the 3T drive as a 2 TiB (2.2 TB) drive in its own firmware, and under Linux with fdisk, proc/partitions, and unRAID. The hdparm -N continued to report the correct values (same as other controllers - 5860533168). It did not have the buggy kernel issue like the SASLP. The BR10i did succeed in assigning the disk to the cache slot, where it was seen as 2.2 TB. Funny, I thought the BR10i was the controller most likely NOT to have problems with the 3T drives, yet it was the only one that does have problems. I'm sure IBM / LSI will fix it soon. Update 6-25-11: I no longer think it likely the BR10i will ever have its firmware updated to support 3T+ drives. Hope this is helpful. Quote Link to comment
BRiT Posted March 5, 2011 Share Posted March 5, 2011 Your information and testing is greatly appreciated. It's a bit surprising to see how well it did behave on the older controllers (ICH8 and JMicron). Quote Link to comment
SSD Posted March 29, 2011 Author Share Posted March 29, 2011 Does the underlying Slackware OS in 5.0b6a support GPT partitions on > 2.2TB disks, and allow large RFS partitions (>2.2TB including 3TB and beyond)? Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.