Jump to content
SSD

3T -> 2T Possible? If so, how?

41 posts in this topic Last Reply

Recommended Posts

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!

Share this post


Link to post

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.

Share this post


Link to post

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)

 

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

I'm curious how they show up on the BR10i with the 1.32.00 firmware with 6.34.00 BIOS combo.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

Good point.  It would be good to let preclear test out the entire drive.  Joe L. - think that would work?

Share this post


Link to post

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.

 

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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).

Share this post


Link to post

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)?

Share this post


Link to post

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.