[SOLVED] Restore sanity to sata drive?

business_kid · 10-29-2023, 01:36 PM

For most of it's life, this drive

Code:

dec@Ebony:~/Downloads$gdisk -l /dev/sdd
GPT fdisk (gdisk) version 1.0.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdd: 1953525164 sectors, 931.5 GiB
Model: MQ04ABF100      
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 3DAA5F00-10B8-4319-B987-98575296E2D6
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953525130
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      1953525130   931.5 GiB   8300

knew it's capacity was 593.1G. The 931.5G is the result of an unfortunate dd which overwrote the capacity, when it was only supposed to overwrite the information. The actual size is 593.1G.

Is there any way of rescuing that so that the capacity makes sense? I wanted to use it for storage but that could get very messy if I let M$ near it...

jailbait · 10-29-2023, 01:55 PM

What I would do is copy all of the files and directories to a backup partition on some other drive, format the drive, and then restore the backup. Don't use dd at all during the procedure.

business_kid · 10-29-2023, 02:30 PM

Quote:

Originally Posted by jailbait

What I would do is copy all of the files and directories to a backup partition on some other drive, format the drive, and then restore the backup. Don't use dd at all during the procedure.

It wasn't a direct backup. The drive was my backup, and the filesystem had gone iffy. I got a bigger one and funny stuff happened, because I needed data off it.

Anyhow, best practise aside(and I agree with your comment) I'll have to start from where I am now, or junk this drive.

michaelk · 10-29-2023, 02:44 PM

Creating a new GPT partition table/partitions should restore the actual size similar to what happens when you write an ISO file to a USB disk. I don't know if you have to zero the GPT header location or not or that you have to worry about the secondary header since it should not exist. I have always written a smaller image to a larger disk so I am not sure what would actually happen in reverse. I suppose it would be fine until you actually wanted to write to a location > 593GB. Can you currently access the drive to copy any data if necessary?

Arnulf · 10-29-2023, 03:03 PM

Quote:

Originally Posted by business_kid

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdd: 1953525164 sectors, 931.5 GiB
Model: MQ04ABF100

Looking at https://storage.toshiba.com/internal...pc/mq04-series shows a drive capacity of 1 TB for the MQ04ABF100.
1 TB = 1000 GB ≈ 931.5 GiB

michaelk · 10-29-2023, 05:38 PM

I didn't look it up...

business_kid · 10-30-2023, 05:25 AM

Quote:

Originally Posted by Arnulf

Looking at https://storage.toshiba.com/internal...pc/mq04-series shows a drive capacity of 1 TB for the MQ04ABF100.
1 TB = 1000 GB ≈ 931.5 GiB

Overwrote the Manufacturer, too, did it? I can't open the drive to check but I'm sure it's not that model. The thing was sold as 600G (actually 593.1G) as I said in post #1 and I thought it was a Samsung drive. The manufacturer I never bothered about, the capacity I did. I need to do clever stuff to write it down in size. It lived a good 5 years as a 593.1G drive, and 1G drives were a bit more expensive then. I'm not going to write the rest, but windows is capable of being that stupid.

Quote:

Originally Posted by michaelk

I have always written a smaller image to a larger disk so I am not sure what would actually happen in reverse. I suppose it would be fine until you actually wanted to write to a location > 593GB. Can you currently access the drive to copy any data if necessary?

Yes, the drive is fine and reads/writes fine. I had wanted to put windows stuff there, but I wouldn't trust it not to do something silly.

michaelk · 10-30-2023, 09:17 AM

If true I would guess the drive was labeled as 640 GB which would be about 593 Gib. What does SMART output as to the drive's info.

business_kid · 10-30-2023, 12:32 PM

Quote:

Originally Posted by michaelk

If true I would guess the drive was labeled as 640 GB which would be about 593 Gib. What does SMART output as to the drive's info.

Good question, but I couldn't get anything diagnostic from smartctl that got me any nearer the problem.

Interestingly, I checked the two drives I suspected of being the source of the overwrite, and they were Western Digital devices,

Code:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048      1953525167   931.5 GiB   8300  Linux filesystem

My problem drive identifies as Toshiba. I made a 593 GiB partition on it, and I'm calling this solved. If windows urinates all over it at some future point, I will have to accept the consequences.

For the curious, I also made a second partition of the remaining space. I made an ext4 filesystem on this second partition, and rsync’ed about 28G of videos to it. The first partition had no filesystem at this stage. Then I made the filesystem on the first partition, so if the 2nd partition had wrapped around to sector 0, I'd lose stuff. but the Videos were all there. Now when I was sold that disk, it stopped at 593.1GiB, but I've added 28G after that...so far...

e2fsck reports the new filesystem as 43.3% non-contiguous. That struck me as strange, as that's awfully high by standards. Rsync has apparently written 9 directories and all their sub directories, but was only populating them when I called a halt. Videos that are listed as transferred to the questionable partition are all there. I've played bits of them throughout.

I had one of those "2 TB" usb drives which are really 16G usb-2.0 devices, and know it looks real until the next time. This looks odd

Code:

dec@Ebony:~$df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            32M  1.6M   31M   5% /run
devtmpfs        8.0M     0  8.0M   0% /dev
/dev/nvme0n1p6   59G   24G   33G  42% /
tmpfs           7.8G   54M  7.8G   1% /dev/shm
cgroup_root     8.0M     0  8.0M   0% /sys/fs/cgroup
/dev/nvme0n1p5  459M   77M  354M  18% /boot
/dev/nvme0n1p7  159G   72G   80G  48% /home
/dev/nvme0n1p1   96M   52M   45M  54% /boot/efi
/dev/nvme0n1p3  254G   55G  200G  22% /win11
tmpfs           1.6G   16K  1.6G   1% /run/user/1000
/dev/sda3       867G  618G  205G  76% /mnt/hd
tmpfs           1.6G     0  1.6G   0% /run/user/0
/dev/sdc1       916G  632G  239G  73% /mnt/zip
/dev/sdb1       583G   28K  553G   1% /mnt/dvd
/dev/sdb2       333G   28G  288G   9% /mnt/tmp

I'll expect it hits an unexpected EOF, but there could be odd things going on in the Toshiba plant. Who knows? I remember the day it's capacity rose from 593.1GiB to 931.5GiB and a large dd and extensive makeover with e2fsck were done on it that day. But I've been wrong before, so why not now?

I'll update the thread with developments.

lvm_ · 10-30-2023, 01:26 PM

Could be that drive's HPA got corrupted somehow. You can access it with hdparm -N

michaelk · 10-30-2023, 01:42 PM

Quote:

I couldn't get anything diagnostic from smartctl that got me any nearer the problem.

From my hard drive the output of smartctl -i /dev/sda

Quote:

=== START OF INFORMATION SECTION ===
Model Family: Western Digital Black
Device Model: WDC WD1003FZEX-00K3CA0
Serial Number: WD-WCC6Y0XK1290
LU WWN Device Id: 5 0014ee 211197689
Firmware Version: 01.01A01
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-3 T13/2161-D revision 3b
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)
SMART support is: Enabled

Does this match the output of gdisk?

Ser Olmy · 10-30-2023, 02:52 PM

Quote:

Originally Posted by business_kid

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdd: 1953525164 sectors, 931.5 GiB

GPT stores a copy of the partition table at the end of the disk. If this disk does not actually have a capacity of 931.5 Gb, fdisk and gdisk should complain about the backup partition table being unreadable.

The manufacturer and model number of the drive is reported to the kernel by the drive at bootup/plugin, and is not stored in the partition table at all.

Something here doesn't make sense.

business_kid · 10-30-2023, 03:17 PM

Quote:

Originally Posted by Ser Olmy

GPT stores a copy of the partition table at the end of the disk. If this disk does not actually have a capacity of 931.5 Gb, fdisk and gdisk should complain about the backup partition table being unreadable.

The manufacturer and model number of the drive is reported to the kernel by the drive at bootup/plugin, and is not stored in the partition table at all.

Something here doesn't make sense.

How does the idea of Toshiba putting a 1TB platter into a 640G disk because it was cheaper/easier/handier for them, or stupid of them? On a manufacturing line, nobody could spot that sort of thing.

That wasn't my first idea, but I'm coming round to it.

business_kid · 11-01-2023, 10:50 AM

Quote:

Originally Posted by business_kid

How does the idea of Toshiba putting a 1TB platter into a 640G disk because it was cheaper/easier/handier for them, or stupid of them? On a manufacturing line, nobody could spot that sort of thing.

That wasn't my first idea, but I'm coming round to it.

This now seems verified. Here's my partitions:

Code:

dec@Ebony:~$fdisk -l /dev/sdb
Disk /dev/sdb: 931.51 GiB, 1000204883968 bytes, 1953525164 sectors

Device          Start        End    Sectors   Size Type
/dev/sdb1        2048 1243613183 1243611136   593G Linux filesystem
/dev/sdb2  1243613184 1953525130  709911947 338.5G Linux filesystem
dec@Ebony:~$df -h
/dev/sdb1       583G  475G   79G  86% /mnt/dvd
/dev/sdb2       333G  315G  591M 100% /mnt/zip

The significance of the partitions are: sdb1 is the space I bought and paid for when I ordered the disk. sdb2 is the extra space that I didn't have out of the box.

Now I've copied 315GiB of Videos on to sdb2 before it ran out of space. I could watch them all, or samples at intervals anyhow. Then I went at partition 1 and am in the process of filling that. But it's well over the 593.1 GiB the drive reported for the first 5 years of it's life.

EDIT: Final capacity was:

Code:

/dev/sdb1       583G  583G     0 100% /mnt/dvd
/dev/sdb2       333G  315G  591M 100% /mnt/zip