Post by bad sectorPosting this in case someone googles for it in desparation
==========================================================
I've seenm other makes of ssd's acting up to so it's probably not just my
Team Grp 4tbs although both incidents WERE with Team-Grp ssd's (have 2).
The first time it happened windows was not involved at all, not in the
cause nor in the undetermined solution. This last time a run in windows
was the only way out of the pits.
After formatting with gdisk to a single 4tb ext4 1st partition I put it
away for a day or so, on ready-1 as it were. Today I try to use it and the
ssd is only 2gb in size! That's right, NOT 2TB but 2GB and I could not
find any linux solution that actually worked. So after reading some
similar horror stories I plugged it in under w10 disk-managment where it
was showing as a normal unused 4tb device. I reformatted it all as ntfs.
The next time in linux gdisk was showing the correct and full 4tb size
again.
I can find a reference to this happening with a SATA device, so I'm
guessing this isn't an NVME stick. You should list the model number
in your post, in case that is important.
There are several mechanisms to end up with a 2GB drive. The "obvious" ways
are with a Host Protected Area (HPA) or a DCO. Not all hardware devices support
that. On my (deceased) X48 system with E8400 processor, the Intel SATA ports
do not allow the formation of an HPA. However, the JMicron IDE header, the
driver in it *did* support HPA, and by fitting an IDE to SATA adapter, I
could do an HPA on a SATA drive. Now that the X48 system is deceased, I can
no longer do an HPA for experimental purposes.
On drives back around early 2000's era, there was a Clip Jumper on the drive.
Insert that and it limits the disk size. (Don't worry, that jumper feature
no longer exists on drives.) It doesn't really change the disk size,
it changes some reported CHS value and the interpretation of that,
is up to the OS you are running.
https://aeb.win.tue.nl/linux/Large-Disk-11.html
11.4 Jumpers that clip total capacity
Clip to 2.1 GB
--------------
The first serious limit was the 4096 cylinder limit (that is, with 16 heads and 63 sectors/track, 2.11 GB).
For example, a Fujitsu MPB3032ATU 3.24 GB disk has
default geometry 6704/15/63
but can be jumpered to
appear as 4092/16/63
and then reports LBAcapacity 4124736 sectors, ... operating system cannot guess that it is larger in reality.
Clip to 33 GB
-------------
The IBM Deskstar 37.5 GB (DPTA-353750) with 73261440 sectors (corresponding to 72680/16/63, or 4560/255/63)
can be jumpered to appear as a 33.8 GB disk, and then reports geometry 16383/16/63 like any big disk,
but [reports] LBAcapacity 66055248 (corresponding to 65531/16/63, or 4111/255/63).
That article also has an extensive section on individual company implementations,
indicating the behavior wasn't exactly standardized. One thing IBM supported
at the time (as an example of bad jokes), was sector sizes other than 512 bytes.
Maybe the attraction at the time, was the soft-sectoring of drives and
the existence of actual Low Level Format commands, make things like this
possible, but it may not have actually been implemented that way. I vaguely
recollect reading some disk drive specification document, with all these
disquieting sector size options mentioned in passing.
"The ATA Read Native Max and Set Max commands may be used to reset the true full capacity."
[And that is with 48 bit LBA and double-pumped control and data register, so
should be able to handle disks over 2.2TB. It's the MBR value (32 bit address)
that "limits" disks to 2.2TB, rather than the drive itself having an addressing limit that low.]
*******
The good news is, it's none of those things :-) :-)
The clipping values, are not power-of-two. They're derived from weird CHS numbers,
and the "small limit" is 2.11GB, whereas you report 2.00GB. Your limiting case
could be an exact power-of-two value.
(This is one reason, when reporting weird capacity issues, it is a good idea
to report exact byte values such as seen in "disktype", "fdisk", or "gdisk".)
Someone suggests this is a secured storage facility of some sort,
and maybe the drive either advertises such a mode or was left in
that mode at the factory. Is it a manifestation of FDE (Full Disk Encryption) ?
Dunno. If a partition had been "formatted" to a certain size, surely
the mount command would have noticed the file system had no upper end.
There are capacity measurement softwares, but I have never tracked such a
thing down and used it in anger. In the HDD days, I used to test drive purchases
by "filling them with files, 1GB at a time", in order to detect canonical
limit cases before they happened by accident. For example, one USENETTER
writes in, has constructed a 3TB raid using three 1TB drives. He seemed
rather proud of himself. OK, so he is ripping DVDs one at a time and filling
the RAID. At the 2.2TB mark, the RAIDed volume instantly disappears. He
has suffered a case of "address rollover at 2.2TB" and the MBR just got deleted.
Did he have a backup ? Nope :-) This is why we *test* storage capacities
to make sure we did not neglect a detail. Even though the software allowed
him to make a 3TB volume, the software did *not* warn him that he was
set up for a failure case.
In the old days, I was known for copying 1GB files onto a drive,
until the drive was full, as proof the "drive actually had that
much storage space". This was to prove, for a storage device,
I had not hit some canonical limit described in the aeb.win.tue.nl URL above.
For example, one day, I was in a VM, and the manual says "we have a disk
passthru mode". Great. I have a 200GB video I'm editing. Boom. Corrupted.
Turns out the hardware interface used, had 28 bit LBA (not 48 bit LBA),
and it managed to corrupt the real storage of the passthru drive.
So so funny. Ha. The VM could not address more than 137GB, the address
rolled over inside the VM, the VM was writing to the MBR, when it thought
it was writing to 137GB + 1 sector as an address. And that instantly
destroys the partition table. And why would you back up such a
drive before such an experiment ? Shirley the mode is safe. Shirley.
*******
You should run "disktype" after this, because it can show the
protective 0xEE partition declaration on a GPT disk. And you would
need GPT for a 4TB storage device. This is my daily driver 4TB SATA SSD (GPT).
S:\disktype> disktype.exe /dev/sda <=== cygwin disktype
--- /dev/sda
Block device, size 3.639 TiB (4000787030016 bytes)
DOS/MBR partition map
Partition 1: 2.000 TiB (2199023255040 bytes, 4294967295 sectors from 1)
Type 0xEE (EFI GPT protective) <==== Protective MBR, tells WinXP to "go away and don't come back"
The three other MBR partition entries are empty
GPT partition map, 128 entries
Disk size 3.639 TiB (4000787030016 bytes, 7814037168 sectors)
Disk GUID CD4D6752-BAC8-B446-90A7-662721F0DD2D
Partition 1: 100 MiB (104857600 bytes, 204800 sectors from 2048)
Type EFI System (FAT) (GUID 28732AC1-1FF8-D211-BA4B-00A0C93EC93B)
Partition Name "EFI system partition"
Partition GUID BE145A8D-FC87-9B45-AFB1-8959CB4D727A
FAT32 file system (hints score 4 of 5)
Volume size 96 MiB (100663296 bytes, 98304 clusters of 1 KiB)
Partition 2: 16 MiB (16777216 bytes, 32768 sectors from 206848)
Type MS Reserved (GUID 16E3C9E3-5C0B-B84D-817D-F92DF00215AE)
Partition Name "Microsoft reserved partition"
Partition GUID B000A1BB-661C-7541-AF97-88BB60627F66
Partition 3: 118.7 GiB (127481675776 bytes, 248987648 sectors from 239616)
Type Basic Data (GUID A2A0D0EB-E5B9-3344-87C0-68B6B72699C7)
Partition Name "Basic data partition"
Partition GUID 6A16D60B-3608-4140-891C-792DF2C72ABD
NTFS file system
Volume size 118.7 GiB (127481675264 bytes, 248987647 sectors)
Partition 4: 649 MiB (680525824 bytes, 1329152 sectors from 249227264)
Type Unknown (GUID A4BB94DE-D106-404D-A16A-BFD50179D6AC)
Partition Name ""
Partition GUID B15ABCC3-F0C5-AE4D-838C-751EF868E237
NTFS file system
Volume size 649.0 MiB (680521728 bytes, 1329144 sectors)
Partition 5: 129.0 GiB (138510690816 bytes, 270528693 sectors from 250556416)
Type Basic Data (GUID A2A0D0EB-E5B9-3344-87C0-68B6B72699C7)
Partition Name "Basic data partition"
Partition GUID BC694DBD-BB6F-124F-B804-F32C6B9E828C
NTFS file system
Volume size 129.0 GiB (138510690304 bytes, 270528692 sectors)
Partition 6: 1.001 GiB (1074790400 bytes, 2099200 sectors from 521086976)
Type Unknown (GUID A4BB94DE-D106-404D-A16A-BFD50179D6AC)
Partition Name ""
Partition GUID CF6B38AF-C016-3F48-A84B-B310CC27C8E8
NTFS file system
Volume size 1.001 GiB (1074786304 bytes, 2099192 sectors)
Partition 7: 682.0 GiB (732331769856 bytes, 1430335488 sectors from 523186176)
Type Basic Data (GUID A2A0D0EB-E5B9-3344-87C0-68B6B72699C7)
Partition Name "Basic data partition"
Partition GUID DA97834F-DF61-974A-B913-9BD526C13C9A
NTFS file system
Volume size 682.0 GiB (732331769344 bytes, 1430335487 sectors)
Partition 8: unused
That's just to show you the level of detail available. The report
in GDISK, of "EF00", is shorthand for "28732AC1-1FF8-D211-BA4B-00A0C93EC93B",
which is why the pseudo-codes were invented, to help humans. The
value "EF00" is not written on the drive anywhere.
Paul