SOLVED Ex-FreeNAS hard drives not showing full capacity in Windows

[wogggieee]

I have 4 3TB hard drives that I had used in a FreeNAS pool until I upgraded those. I want to use these hard drives in other computers. I've connected them to multiple windows machines and they only show them as having 746GB. I've tried doing a number of things suggested from googling like making it a GPT partition and using Diskpart and nothing seems to work on any of these drives. How would I go about getting the full space?

 

[Chris Moore]

3TB hard drives

Sorry to hear that you are having some difficulty. I have been using FreeNAS since 2011 and have not seen anything like what you are describing despite having used several hundred drives with FreeNAS. I have a server at work that is running 80 drives and another that is running 60 drives in addition to my server at home that is running 48 drives. I am not exaggerating at all.
If these drives were sitting un-used for a period of time after being removed from the NAS, it is possible that they suffered some kind of failure.
FreeNAS does nothing to the drive other than partition and format it, just like any other operating system. I have taken dozens of drives that were removed from FreeNAS systems and used them for other purposes including installing Windows on them to use them as boot drives. There is absolutely nothing about what FreeNAS does to the drive that is in any way unusual and nothing about it should leave a lasting impression on the drive. What ever the problem is, it has nothing to do with FreeNAS.

 

[wogggieee]

They've only been sitting for about a week. Each of the four drives have had the same issue. Not sure what to make of that.

 

[Chris Moore]

You might try using DBAN to wipe them.

 

[wblock]

Windows and Linux partitioning software is frequently unable to deal with GPT partitioning, often confusing the PMBR with a real MBR and leaving a secondary GPT table at the end of the disk.

FreeNAS has a "wipe disk" option that can do this, although caution is strongly recommended. I personally do not like to do disk erases on a system where live data disks are attached.

FreeBSD's gpart properly deals with GPT, so I suggest:

Attach the drives to a spare system (for safety), then boot mfsBSD. I'd use the full "special edition" rather than the mini, but 64-bit either way.

Then use gpart destroy -F ada9 on each drive (substitute the drive name for ada9, but don't wipe out the boot drive if the spare system still has one).

If either Windows or Linux has been used to modify what they thought the partitioning was, the GPT format is probably corrupted. In that situation, the quick way to fix it is to:

Code:

gpart destroy -F ada9
gpart create -s gpt ada9
gpart destroy -F ada9

In other words, erase whatever partitioning is on there, create a valid GPT format, then properly erase that. That erases the secondary GPT table at the end of the drive.

Brute-force disk wipe programs can work, very slowly, as a side effect of just erasing every block on the drive. They have their own limitations and can put significant wear on the disk. Don't use them on SSDs.

 

[Ericloewe]

For SSDs that support it, a secure erase is a quick option for brute-force wiping. Same goes for HDDs that support it, I guess, but those are fairly rare.

 

[wogggieee]

Windows and Linux partitioning software is frequently unable to deal with GPT partitioning, often confusing the PMBR with a real MBR and leaving a secondary GPT table at the end of the disk.

FreeNAS has a "wipe disk" option that can do this, although caution is strongly recommended. I personally do not like to do disk erases on a system where live data disks are attached.

FreeBSD's gpart properly deals with GPT, so I suggest:

Attach the drives to a spare system (for safety), then boot mfsBSD. I'd use the full "special edition" rather than the mini, but 64-bit either way.

Then use gpart destroy -F ada9 on each drive (substitute the drive name for ada9, but don't wipe out the boot drive if the spare system still has one).

If either Windows or Linux has been used to modify what they thought the partitioning was, the GPT format is probably corrupted. In that situation, the quick way to fix it is to:

Code:

gpart destroy -F ada9
gpart create -s gpt ada9
gpart destroy -F ada9

In other words, erase whatever partitioning is on there, create a valid GPT format, then properly erase that. That erases the secondary GPT table at the end of the drive.

Brute-force disk wipe programs can work, very slowly, as a side effect of just erasing every block on the drive. They have their own limitations and can put significant wear on the disk. Don't use them on SSDs.

Once this is done do I create new partitions with windows or within FreeBSD?

 

[Chris Moore]

Once this is done do I create new partitions with windows

If the plan is to use these disks with Windows, you would use Windows to partition and format the drives as usual.
I have not had any problems with cleaning the partitioning by using the command prompt utility included with Windows, diskpart, but you said you had tried that. Using diskpart and the clean function within it has worked for me, so many times, but there can always be the edge case that is different.

 

[jgreco]

If the plan is to use these disks with Windows, you would use Windows to partition and format the drives as usual.
I have not had any problems with cleaning the partitioning by using the command prompt utility included with Windows, diskpart, but you said you had tried that. Using diskpart and the clean function within it has worked for me, so many times, but there can always be the edge case that is different.

You can also run 'diskmgmt.msc' from an administrative command prompt in Windows. This sometimes gives valuable clues into what the problem is, and also happens to be pretty convenient for fooling around with disk partitioning.

 

[wogggieee]

Windows and Linux partitioning software is frequently unable to deal with GPT partitioning, often confusing the PMBR with a real MBR and leaving a secondary GPT table at the end of the disk.

FreeNAS has a "wipe disk" option that can do this, although caution is strongly recommended. I personally do not like to do disk erases on a system where live data disks are attached.

FreeBSD's gpart properly deals with GPT, so I suggest:

Attach the drives to a spare system (for safety), then boot mfsBSD. I'd use the full "special edition" rather than the mini, but 64-bit either way.

Then use gpart destroy -F ada9 on each drive (substitute the drive name for ada9, but don't wipe out the boot drive if the spare system still has one).

If either Windows or Linux has been used to modify what they thought the partitioning was, the GPT format is probably corrupted. In that situation, the quick way to fix it is to:

Code:

gpart destroy -F ada9
gpart create -s gpt ada9
gpart destroy -F ada9

In other words, erase whatever partitioning is on there, create a valid GPT format, then properly erase that. That erases the secondary GPT table at the end of the drive.

Brute-force disk wipe programs can work, very slowly, as a side effect of just erasing every block on the drive. They have their own limitations and can put significant wear on the disk. Don't use them on SSDs.

Unfortunately this did not work

 

[wblock]

Once this is done do I create new partitions with windows or within FreeBSD?

Use the system that will be using the drive to partition it.

Unfortunately this did not work

What happened?

 

[farmerpling2]

A simple tool is to use the manufacturers disk testing tool. They typically contain a feature to zero the disk (DD does the same thing). Some of the packages have a QUICK erase, which erases the first and last million blocks on disk. Use the windows package install rather than the ISO boot CDROM/USB.

Zero it and then use disk management to do a quick format to see ho much space is available.

Are you using hardware raid by chance on the windows PC?

 

[wogggieee]

What happened?

I did the gpart stuff to no effect. Still shows 746 gigs when I bring it up in windows disk management

 

[wogggieee]

A simple tool is to use the manufacturers disk testing tool. They typically contain a feature to zero the disk (DD does the same thing). Some of the packages have a QUICK erase, which erases the first and last million blocks on disk. Use the windows package install rather than the ISO boot CDROM/USB.

Zero it and then use disk management to do a quick format to see ho much space is available.

Are you using hardware raid by chance on the windows PC?

It's a western digital red drive. I'll have to see if wd has a utility.

What is DD?

The windows PC is not raid, however the disks I'm trying to use were part of a freenas raid array of that matters at all.

 

[gpsguy]

https://en.wikipedia.org/wiki/Dd_(Unix)

What is DD?

 

[farmerpling2]

You can also do:

smartctl -x /dev/adax

to see a good view of what smart statistics. To do this, you would have to put the drive back into your freenas system.

Are you using software raid on your PC's?

 

[wblock]

I did the gpart stuff to no effect. Still shows 746 gigs when I bring it up in windows disk management

It would be helpful to see the output gpart showed when that was done, but okay.

Another idea: maybe the Windows machine hard drive controller or motherboard is old enough to have a 2TB rollover, and it is only seeing the space available minus that 2TB. With a hard drive at 3 hard-drive-vendor "TB" minus a real 2TB, that could come out pretty close to the numbers you are seeing.

 

[wogggieee]

So the problem has been solved. It seems that it was the USB to SATA cable that I was using. When I attached the drive directly to the motherboard it worked as expected.

 

[Chris Moore]

So the problem has been solved. It seems that it was the USB to SATA cable that I was using. When I attached the drive directly to the motherboard it worked as expected.

You should always assume that USB is not going to work correctly. Always go directly to a hardware controller.
Going directly to the hardware controller should have been your first, first thing to try

Sent from my SAMSUNG-SGH-I537 using Tapatalk

 

[wogggieee]

Yeah, lesson learned