Hard Drive suffering an identity crisis

I have a Seagate model ST3000DM003, 3 TB hard drive which sometimes mounts as a 2.73 TB hard drive labeled 3TBFAT32, and sometimes mounts as a 746 GB Hard drive labeled GPARTED-LIVE.

This drive was removed from a Seagate external USB drive. That drive had ceased to function, but presumably due to some fault in the interface board, not in the hard drive.

I wanted to install the GPARTED Linx distribution on a hard drive, so I attempted to do so. As I recall, I was unable to boot from it, and I abandoned the effort. Some time later I mounted the hard drive, and it presented as a 746 GB partition completely filling the drive and containing the files you would expect for a GPARTED installation. I them used the KDE Partition Manger to repartition the drive. As I recall KDE first recognized the 746 GB partition as filling the entire drive, let me delete it, and then recognized the drive as having 2.73 TB of unallocated space. I partitioned it as FAT32, and all seemed normal. I copied a file to the drive, and was satisfied that it was all working.

All of this activity was done with the hard drive connected via a USB adapter.

The next time I needed a hard drive, I connected the hard drive using the same USB adapter, and it presented as the 746GB drive with the GPARTED files. I’m not sure of the exact sequence of things after that, but in trying to access the hard drive I have tried various combinations of two Linux computers, 1 windows computer, and two different USB adapters. When connected to a Linux computer, sometimes the drive presents as a 746GB drive with the GPARTED files installed, and sometimes it presents as the 7.3 TB drive with the one file copied to it.

The Windows computer always (so far) has recognized the FAT32 partition. It doesn’t acknowledge any free space or other partitions on the drive. The Linux computers usually recognize the 746 GB partition, but sometimes recognize the drive as a single FAT32 partition. I’m not certain, but it may be that which partition is recognized by the Linux computers depends upon which of the USB adapters is being used.

What does fdisk -l or parted -l report for that 3TB Seagate?

1 members found this post helpful.

And why in the name of sanity would you choose FAT ?.

No idea about the root cause.
But you might try to overwrite the whole disk with zeros, before repartitioning.
sudo dd if-/dev/zero of=/dev/sdX (your drive)
Might take a whole day.
If you want to see the progress, first install pv and then:
dd if-/dev/zero | pv | dd of=/dev/sdX

Perhaps it is enough to overwrite only the first part of the drive:
dd bs=1M count=10 if-/dev/zero of=/dev/sdX

Let's hope the OP provides the data asked for before obliterating any evidence that might be useful.

I'd start afresh. Give it a new MBR, partition it, & put ext4 file system on it.

MBR? That is wrong. Use GPT instead.

OP
Why install GParted on a 3TB disk?

I have estaablished that which adapter I use determines which file system will be recognized.


This is what I get with the disk connected (/dev/sdc) and recognized as 746 GB drive:


sudo fdisk -l /dev/sdc
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdc: 746.53 GiB, 801569726464 bytes, 1565565872 sectors
Disk model: External
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 075AA60E-FE17-4A4F-98A4-9F2E5EA0BF4F

sudo parted -l
Error: Invalid argument during seek for read on /dev/sdc
Retry/Ignore/Cancel? i
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? OK
Model: Generic External (scsi)
Disk /dev/sdc: 802GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:


This is what I get with the disk connected (/dev/sdc) and recognized as 2.37 GB drive:

sudo fdisk -l /dev/sdc
[sudo] password for rcdawson:
Disk /dev/sdc: 2.75 TiB, 3000592982016 bytes, 5860533168 sectors
Disk model: 003-1F216N
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 075AA60E-FE17-4A4F-98A4-9F2E5EA0BF4F

Device Start End Sectors Size Type
/dev/sdc1 2048 5860532223 5860530176 2.7T Microsoft basic data


Model: ST3000DM 003-1F216N (scsi)
Disk /dev/sdc: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 3001GB 3001GB fat32 msftdata


It would appear that there is some problem with the GPT table being corrupted, although fdisk and parted seem
to have a difference of opinion as to whether it is the primary or backup that is corrupted. Could this be the
cause of the problem?

Also, I have pretty well confirmed that which file system is recognized depends upon which adapter I use. One is
made by Startech, the other by Unitek. I think that the Startech is a USB 2 device, and the Unitek is a
USB 3 device.

As to why FAT32, I need to share the contents with Windows computers, and that seems to work. I do think I am sane

I thought about trying using dd to copy zeros, but would that address any problem with the partition table?

As to starting fresh, I have tried repartitioning with KDE Partition manager. At one point it did delete the
746 GB partition and replace it with the 2.7 TB partition, but that is how I got to where I am. At
this point, knowing that what file system is recognized depends upon which adapter I use, I might try
re-partitioning with the adapter that recognizes the 746 GB filesystem. I would prefer, however
to see if there isn't some rational explanation and sure-fire solution.

Does the information from fdisk and parted provide any insight?

You almost provided enough information to make it clear what to suggest. I don't see any indication which fdisk and parted output is from using the USB2 or the USB3 adapter. It looks like the one the second data set comes from is indicating the disk should be ready to use as is.

Using FAT32 on a partition that fills a 3TB disk is a bad idea. FAT32 was not intended for use with filesystems of such huge size as a 3TB disk allows. Current Linux distros support writing to NTFS and ExFAT, so I suggest reformatting to one of those two. I also suggest starting with a new GPT table prior to formatting the new partition(s). I further suggest giving some thought to partitioning it with two partitions so that one can be used with a Linux native format, such as EXT4, for files that Windows doesn't need to see.

My 3TB disk with one partition on it looks as follows:

I agree with mrmazda, this looks correct and the information from the other adapter is not. Which adapter are you using? There is no point in playing with the other one that reports the drive as 746 GB.

The USB 2 adapter connects to the 746 GB file system. The adapter is a Startech model SATADOCKU2. On Startech's website I found two others complaining that it wouldn't recognize larger drives. I find that it will recognize a 1 TB drive.

I notice on the 2.7 TB drive there is a notice from Seagate saying that for greater than 2 TB a special driver may be required.

I suspect that my Startech adapter was built before 2 TB drives were widely available.

What is odd to me is that the 746 GB partition, that was all I could make with the Startech adapter, persisted even after I created the 2.7 TB partition using the other adapter.

If anyone has a suggestion on how to obliterate the 746 GB partition, that would set my mind at ease

Does the Windows computer always recognize the drive as 2.7 TB regardless of adapter?

I might of guessed that the 746 GB filesystem would of been using the USB 3 versus 2 adapter depending on distribution/kernel and if your plugging the adapter into a USB 2 or 3 port.

0.7TiB is the typical size (in round numbers) reported by a host adapter that doesn't support a disk size greater than 2.0TiB. 0.7TiB is a non-support consequence of wrapping the size back to zero to start counting again as if it was counting from zero. A 3.0TB disk is approximately 2.728TiB. It's the same basic issue that lead to the development of the GPT partition table type. MBR partitioning can't support more than 2.0TiB correctly, except in limited circumstances understood by experts, which I will not attempt to do or explain. If you stop using that limited functionality Startech with a drive larger than it supports, you should stop seeing any .7TiB partition. Definitely do not use the Startech with any partitioning or formatting tools unless with a drive small enough for it to support correctly. And, if you decide to repartition, be sure to use only the GPT type.

1 members found this post helpful.

I missed your update. And yes I agree with mrmazda...

1 members found this post helpful.