View previous topic :: View next topic |
Author |
Message |
DigitalCorpus Apprentice
Joined: 30 Jul 2007 Posts: 283
|
Posted: Sat Jan 30, 2021 1:47 pm Post subject: [Solved - HPA] GDisk - Corrupted partition table recovery |
|
|
I have 2, 4 TB EVO 860 SSDs I've copied my spinning rust data onto as I migrate from my old Q9400 server to my new i5-8500T server. I left one plugged in after having a full Gentoo install and DE functioning while I confirmed my overclock limit with this RAM & CPU, cause I forgot. The plugged in one suffered partition tabel corruption. Both SSDs are a single-partition with a Protected MBR & GPT layout,F2FS formatted. I *could* just wipe, copy, and MD5-verify everything on this single corrupted SSD, but I want to learn a bit more about how to properly recover the partition table. Here's the output of gdisk:
Code: | Warning: Partition table header claims that the size of partition table
entries is 0 bytes, but this program supports only 128-byte entries.
Adjusting accordingly, but partition table may be garbage.
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.
Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: ERROR
Main partition table: OK
Backup partition table: ERROR
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
**************************************************************************** |
'v'-erifing the partition table nets the following:
Code: | Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.
Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.
Problem: Disk is too small to hold all the data!
(Disk size is 7814035055 sectors, needs to be 7814037168 sectors.)
The 'e' option on the experts' menu may fix this problem.
Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 7814037134, but backup header is at
7814037167 and disk size is 7814035055 sectors.
The 'e' option on the experts' menu will probably fix this problem
Problem: partition 1 is too big for the disk.
Identified 5 problems! |
This is where I get confused, the options below and the resuts thereof:
Code: | b use backup GPT header (rebuilding main)
c load backup partition table from disk (rebuilding main)
d use main GPT header (rebuilding backup)
e load main partition table from disk (rebuilding backup)
f load MBR and build fresh GPT from it
...
w write table to disk and exit |
If I attempt to 'w'rite out the existing partition table in an understanding that the corrupted backups will be fixed, I already made a backup of the partition table, I get this output:
Code: | Recovery/transformation command (? for help): w
Caution! Secondary header was placed beyond the disk's limits! Moving the
header, but other problems may occur!
Warning! Secondary partition table overlaps the last partition by
2113 blocks!
You will need to delete this partition or resize it in another utility.
Problem: partition 1 is too big for the disk.
Aborting write operation!
Aborting write of new partition table. |
If I then select 'e' and then 'v'-erify it, I get:
Code: | Problem: partition 1 is too big for the disk.
Warning! Secondary partition table overlaps the last partition by
2113 blocks!
You will need to delete this partition or resize it in another utility.
Identified 2 problems! |
But if I only 'e' it and then verify it, I get:
Code: | Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.
Problem: Disk is too small to hold all the data!
(Disk size is 7814035055 sectors, needs to be 7814037168 sectors.)
The 'e' option on the experts' menu may fix this problem.
Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 7814037134, but backup header is at
7814037167 and disk size is 7814035055 sectors.
The 'e' option on the experts' menu will probably fix this problem
Problem: partition 1 is too big for the disk.
Identified 4 problems! |
I'd rather not spend a day copying ~3 TB of data off of 2 spinning rust drives, but I can. The only 4 TB drive I have to mirror this onto is the original 4 TB HDD mirrored onto the *other* of the paired 860 EVOs. PhotoREC/Testdisk do no support F2FS (just found out because of this) and test disk doesn't seem to think there is a problem with the partition table, so I don't trust that software, but I'm not confident enough with gdisk's output to warrant
I did think of copying the disk and partition UUIDs of the corrupted table, importing a copy of the other SSD's partition table as a known good and then change the subsequent UUIDs, but... the non-corrupted SSD's output reports a disk size of 7814037168 sectors, not 7814035055 sectors. This makes me question doing whole disk partitions, even on read-heavy drives where I wouldn't, and didn't, provide 5-25% overprovisioning.
Guideance is appreciated. Most results I found online didn't deal with this collection of results so here I am.
Last edited by DigitalCorpus on Sun Jan 31, 2021 7:58 pm; edited 1 time in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54408 Location: 56N 3W
|
Posted: Sat Jan 30, 2021 2:46 pm Post subject: |
|
|
DigitalCorpus,
Maybe the filesystem is damaged?
How did you do the copy?
The wrong answer is dd, unless the drives are *exactly* the same size. If you used dd and the output drive is smaller than the input drive, the end of the input drive is truncated.
That's not recoverable.
So, is Code: | Problem: partition 1 is too big for the disk. | correct or not?
We will likely need the same data (fdisk) from the source drive.
fdisk will show the disk size and the partition size.
Once we know if its a real problem, we can decide what to do next. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
DigitalCorpus Apprentice
Joined: 30 Jul 2007 Posts: 283
|
Posted: Sat Jan 30, 2021 10:57 pm Post subject: |
|
|
I did rsync -a for the vast majority of the data copy from spinning rust to SSD. I did cp -a for a few outstanding files. sort-ed, md5deep -rel for verification.
Sorry, I skipped a part: I noted there was an initial problem when the disk presented but no partitions mounted and cat /proc/partitions showed that the partition, eg. /dev/sdb*1*, was no longer "detected" by the system. Opening the disk in gdisk then told me the backup structures were corrupted etc.
When verifying the OC limits, I did have a few kernel panics or oops after POST, during kernel loading, rc init, and/r logging into XFCE4. Disk corruption was expected /shrug
non-corrupted SSD:
Code: | Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: Samsung SSD 860
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: FD8A9E7F-1B64-4D04-8EDC-A2E56F243BA7
Device Start End Sectors Size Type
/dev/sdb1 2048 7814037134 7814035087 3.6T Linux filesystem |
corrupted SSD:
Code: | The size of this disk is 3.6 TiB (4000785948160 bytes). DOS partition table format cannot be used on drives for volumes larger than 2199023255040 bytes for 512-byte sectors. Use GUID partition table format (GPT).
Command (m for help): p
Disk /dev/sdc: 3.64 TiB, 4000785948160 bytes, 7814035055 sectors
Disk model: Samsung SSD 860
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: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdc1 1 4294967295 4294967295 2T ee GPT |
Because fdisk reported a problem with GPT, I went to gdisk instead of fdisk and was presented with more info, specifically about the GPT structure being damaged. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54408 Location: 56N 3W
|
Posted: Sat Jan 30, 2021 11:26 pm Post subject: |
|
|
DigitalCorpus,
Code: | Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk /dev/sdc: 3.64 TiB, 4000785948160 bytes, 7814035055 sectors |
Are the drives really different sizes?
The sector count should be read from the drive.
What does dmesg say about the Host Protected Areas on the drive?The right answer is nothing.
Grep for HPA.
cp -a and rsync should both be OK an they coy files.
What does Code: | mount -o ro,offset=1048576 /dev/sd<whole_drive> /mnt/someplace | say?
That will mount the filesystem that starts at block 2048 without reading the partition table.
Have a look round.
There is one potential nasty. Even though the mount is read only, a journal replay can still happen.
This is usually a good thing ... unless the filesystem is corrupt, then in can be very bad.
If the filesystem mounts, what size is it?
df will tell the number of 1k blocks.
Then we need the GPT from the corrupt drive to see if it fits or not. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
DigitalCorpus Apprentice
Joined: 30 Jul 2007 Posts: 283
|
Posted: Sun Jan 31, 2021 12:18 am Post subject: |
|
|
Yeah, it's odd that the pair of SSDs differ in size. I don't know which mechanisms are used for reporting from the various tools, but from /proc/partitions to smartctl, they differ. At the same time, the FTL is a layer of obfuscation and I *assume* that if NAND cells were damaged, the firmware blacklists them and, if it was possible, rewrites the data elsewhere from reconstructed parity info, else the data is viewed as corrupted in software.
Should say nothing... FWIW, this system is an Intel P965 (Intel 82801HB) w/ AHCI in case we get more into the weeds and things look atypical.
Code: | [ 0.926768] ata2: SATA max UDMA/133 abar m2048@0xfb106000 port 0xfb106180 irq 29
...
[ 1.258913] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
...
[ 1.261229] ata2.00: HPA detected: current 7814035055, native 7814037168
[ 1.261231] ata2.00: supports DRM functions and may not be fully accessible
...
[ 1.261677] ata2.00: ATA-11: Samsung SSD 860 EVO 4TB, RVT04B6Q, max UDMA/133
[ 1.261680] ata2.00: 7814035055 sectors, multi 1: LBA48 NCQ (depth 32), AA
[ 1.263474] ata2.00: supports DRM functions and may not be fully accessible
[ 1.265374] ata2.00: configured for UDMA/133
...
[ 1.275059] ata2.00: Enabling discard_zeroes_data |
I get this when attempting to mount as root:
Code: | mount -o ro,offset=1048576 /dev/sdc /mnt/recover/
mount: /mnt/recover/: mount failed: Operation not permitted. |
In case it is my build that is causing the issue, i.e. the minimal USE flag for xorg-server disables 3D acceleration and I found *1* post about that from 2015 after 3 days of digging. Using the overlay for simpler access to the liquorix kernel sources for the MuQSS patche(s).
emerge -pv util-linux:
Code: | sys-apps/util-linux-2.36.1-r1::gentoo USE="cramfs logger ncurses nls pam readline (split-usr) suid udev (unicode) -audit -build -caps -cryptsetup -fdformat -hardlink -kill -python (-selinux) -slang -static-libs -su -systemd -test -tty-helpers" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_8 -python3_7 -python3_9" |
emerge --info:
Code: | Portage 3.0.14 (python 3.8.7-final-0, default/linux/amd64/17.1/desktop, gcc-10.2.0, glibc-2.32-r7, 5.10.7-lqx1-Trim+X11 x86_64)
=================================================================
System uname: Linux-5.10.7-lqx1-Trim+X11-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9400_@_2.66GHz-with-glibc2.2.5
KiB Mem: 8161876 total, 4847204 free
KiB Swap: 33554428 total, 33171964 free
Timestamp of repository gentoo: Sat, 30 Jan 2021 10:30:01 +0000
Head commit of repository gentoo: 5a6d0d137db7439de398fedad5efe746c40359f3
sh bash 5.1_p4
ld GNU ld (Gentoo 2.35.1 p2) 2.35.1
ccache version 4.1 [enabled]
app-shells/bash: 5.1_p4::gentoo
dev-java/java-config: 2.3.1::gentoo
dev-lang/perl: 5.32.0-r1::gentoo
dev-lang/python: 2.7.18-r6::gentoo, 3.8.7-r1::gentoo, 3.9.1-r1::gentoo
dev-util/ccache: 4.1::gentoo
dev-util/cmake: 3.19.4::gentoo
sys-apps/baselayout: 2.7-r1::gentoo
sys-apps/openrc: 0.42.1-r1::gentoo
sys-apps/sandbox: 2.20::gentoo
sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake: 1.11.6-r3::gentoo, 1.16.3-r1::gentoo
sys-devel/binutils: 2.35.1-r1::gentoo
sys-devel/gcc: 10.2.0-r5::gentoo
sys-devel/gcc-config: 2.3.3::gentoo
sys-devel/libtool: 2.4.6-r6::gentoo
sys-devel/make: 4.3::gentoo
sys-kernel/linux-headers: 5.10::gentoo (virtual/os-headers)
sys-libs/glibc: 2.32-r7::gentoo
Repositories:
gentoo
location: /var/db/repos/gentoo
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-verify-jobs: 2
sync-rsync-extra-opts:
sync-rsync-verify-metamanifest: yes
sync-rsync-verify-max-age: 6
x-portage
location: /usr/local/portage
masters: gentoo
priority: 0
heindsight
location: /var/lib/layman/heindsight
masters: gentoo
priority: 50
thegreatmcpain
location: /var/lib/layman/thegreatmcpain
masters: gentoo
priority: 50
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe "
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php8.0/ext-active/ /etc/php/cgi-php8.0/ext-active/ /etc/php/cli-php8.0/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -O2 -pipe "
DISTDIR="/var/db/repos/cache/distfiles"
EMERGE_DEFAULT_OPTS="--jobs 3 --keep-going --quiet-fail y"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-march=native -O2 -pipe "
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs ccache clean-logs compress-build-logs compress-index compressdebug config-protect-if-modified distlocks ebuild-locks fail-clean fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch parallel-install pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms split-log splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-march=native -O2 -pipe "
GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://gentoo.mirrors.easynews.com/linux/gentoo/ https://mirror.leaseweb.com/gentoo/"
LANG="en_US.utf8"
LDFLAGS="-march=native -O2 -pipe -Wl,-O1 -Wl,--as-needed -Bdirect -Wl,--hash-style=gnu,--sort-common,-znow,-zrelro"
LINGUAS="en_US en"
MAKEOPTS="-j4"
PKGDIR="/var/db/repos/cache/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_EXTRA_OPTS=""
PORTAGE_RSYNC_OPTS="--compress --compress-level=6 --delete --delete-during --force --links --perms --preallocate --recursive --safe-links --stats --times --whole-file --timeout=15 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/home/.tmp"
USE="X a52 aac acl acpi aio alsa amd64 berkdb bidi bindist branding bzip2 cairo cdda cdr cli crypt dbus dri dts dvd dvdr elogind emboss encode exif flac gallium gd gdbm gif gtk gtk2 gtk3 gui iconv icu initramfs introspection io-uring ipv6 jpeg jpeg2k lcms libglvnd libnotify libtirpc lighttpd llvm lm-sensors lzma minimal mng mp3 mp4 mpeg multilib native-cflags ncurses nls nptl nsplugin ogg opengl openmp pam pango pcre pcre16 pdf php png policykit ppds qt5 readline rule-generator samba seccomp sensord sna spell split-usr ssl startup-notification svg symlink tcpd threads tiff truetype udev udisks unicode upower usb vdpau vorbis vulkan widevine wxwidgets x264 xattr xcb xkb xml xscreensaver xslt xv zlib" ABI_X86="64" ALSA_CARDS="hda-intel" CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3 sse4_1" ELIBC="glibc" INPUT_DEVICES="libinput" KERNEL="linux" L10N="en en-US" LCD_DEVICES="ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="X86" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_8" PYTHON_TARGETS="python2_7 python3_8" RUBY_TARGETS="ruby26 ruby27" USERLAND="GNU" VIDEO_CARDS="nvidia"
Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS |
|
|
Back to top |
|
|
DigitalCorpus Apprentice
Joined: 30 Jul 2007 Posts: 283
|
Posted: Sun Jan 31, 2021 12:35 am Post subject: |
|
|
I used gdisk to backup the GPT to disk for both SSDs, sdb = good & sdc = bad, and here is the non-zero hex from them using dhex w/ a little padding:
Bad, sdc:
Code: | 198 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................
1B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 ee ff ff ff 01 00 ........................
1C8 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................
1E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................
1F8 00 00 00 00 00 00 55 aa 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 ......U.EFI PART....\...
210 89 5e 68 38 00 00 00 00 01 00 00 00 00 00 00 00 af be c0 d1 01 00 00 00 .^h8....................
228 22 00 00 00 00 00 00 00 8e be c0 d1 01 00 00 00 9e 67 f4 4a cb 40 26 45 "................g.J.@&E
240 ad 80 00 a3 4f 53 c4 f7 02 00 00 00 00 00 00 00 80 00 00 00 80 00 00 00 ....OS..................
258 26 eb 66 8e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 &.f.....................
270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................ |
Good, sdb:
Code: | 198 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................
1B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 ee ff ff ff 01 00 ........................
1C8 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................
1E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................
1F8 00 00 00 00 00 00 55 aa 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 ......U.EFI PART....\...
210 40 f2 f0 76 00 00 00 00 01 00 00 00 00 00 00 00 af be c0 d1 01 00 00 00 @..v....................
228 22 00 00 00 00 00 00 00 8e be c0 d1 01 00 00 00 7f 9e 8a fd 64 1b 04 4d "...................d..M
240 8e dc a2 e5 6f 24 3b a7 02 00 00 00 00 00 00 00 80 00 00 00 80 00 00 00 ....o$;.................
258 53 5b 01 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S[......................
270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................ |
I've installed the sleuth kit in case that is the next step |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54408 Location: 56N 3W
|
Posted: Sun Jan 31, 2021 9:53 am Post subject: |
|
|
DigitalCorpus,
Why do yo have a HPA on that drive?
Code: | [ 1.261229] ata2.00: HPA detected: current 7814035055, native 7814037168
[ 1.261231] ata2.00: supports DRM functions and may not be fully accessible |
That account for the difference ins sizes shown here.
Code: | Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk /dev/sdc: 3.64 TiB, 4000785948160 bytes, 7814035055 sectors |
The HPA is a 'hidden' region at the end of the drive that the drive hides from the operating system. Its typically used by large vendors for storing a recover image and has been used it the past for BIOS too.
The drive reports that it is 7814035055 sectors but its actually 7814037168 sectors.
I suspect that the HPA was created after the GPT disk lable and filesystem were added, now the end of the filesystem and the second copy of the GPT are inside the HPA.
They are probably still there.
Code: | mount -o ro,offset=1048576 /dev/sdc /mnt/recover/
mount: /mnt/recover/: mount failed: Operation not permitted. | suggests that you were not root.
Don't do this again as its likely that the end of the filesystem cannot be read.
If you didn't create the HPA and there is no reason for you to have a HPA on that drive, remove it. I suspect thaf the errors will go away then. hdparm can change the HPA settings.
Its a dangerous tool, so go careful with in.
The HPA is created with some low level ATA commands to the drive. If that happened accidentality, who knows what else happened.
Random writes in the middle of any mounted filesystems for example? _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
DigitalCorpus Apprentice
Joined: 30 Jul 2007 Posts: 283
|
Posted: Sun Jan 31, 2021 7:12 pm Post subject: |
|
|
I haven't heard of HPA until you had me grep my boot log. Don't know how it got "turned on"
I tried the mount as root and got that result, which is why I posted USE flags |
|
Back to top |
|
|
DigitalCorpus Apprentice
Joined: 30 Jul 2007 Posts: 283
|
Posted: Sun Jan 31, 2021 7:27 pm Post subject: |
|
|
If I'm understanding the man page correctly, the following command should remove HPA from the affected drive, currently sdc.
Code: | hdparm -Np7814037168 /dev/sdc |
I'll report back shortly
</break>
HPA was disabled sucessfully and auto mounting via label worked aye-okay. Unmounted and running fsck on the filesystem atm. I have no idea how it got turned on...
Last edited by DigitalCorpus on Sun Jan 31, 2021 7:34 pm; edited 1 time in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54408 Location: 56N 3W
|
Posted: Sun Jan 31, 2021 7:30 pm Post subject: |
|
|
DigitalCorpus,
I don't understand the Code: | Operation not permitted | error.
Its just as well it failed though.
Creating the HPA is programming some memory in the HDD. Your data is still there unless something wrote to the HPA, then the data that was there is gone.
That offset=1048576 is supposed to be 2048*512 ... for the start byte of the first partition, counting from the start of the drive.
Reading the man page, I would take is slowly.
Code: | -N displays the
current setting, which is reported as two values: the first
gives the current max sectors setting, and the second shows the
native (real) hardware limit for the disk. | Does that work and give the numbers you expect?
Next, try Code: | -Nnative (real) hardware limit for the disk | .
/dev/sdc1 may mount now. The change has been made but its not yet permanet.
You may need a SCSI bus rescan first.
If that looks good, try the -Np version.
Then there is Code: | --dco-restore
Reset all drive settings, features, and accessible capacities
back to factory defaults and full capabilities. This command
will fail if DCO is frozen/locked, or if a -Np maximum size re‐
striction has also been set. This is EXTREMELY DANGEROUS and
will very likely cause massive loss of data. DO NOT USE THIS
COMMAND. |
Some or all of these commands may issue a whole drive trim command for free. That will erase the entire drive but you do have a backup.? _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Last edited by NeddySeagoon on Sun Jan 31, 2021 7:51 pm; edited 2 times in total |
|
Back to top |
|
|
DigitalCorpus Apprentice
Joined: 30 Jul 2007 Posts: 283
|
Posted: Sun Jan 31, 2021 7:36 pm Post subject: |
|
|
NeddySeagoon wrote: | DigitalCorpus,
I don't understand the Code: | Operation not permitted | error.
Its just as well it failed though.
Creating the HPA is programming some memory in the HDD. Your data is still there unless something wrote to the HPA, then the data that was there is gone.
That offset=1048576 is supposed to be 2048*512 ... for the start byte of the first partition, counting from the start of the drive. |
This is dealing with lower level concepts than what I've touched on before in the past. The offset math made sense to me too so I don't know why it refused to work.
And, thank you btw for your guidance and support, Neddy |
|
Back to top |
|
|
DigitalCorpus Apprentice
Joined: 30 Jul 2007 Posts: 283
|
Posted: Sun Jan 31, 2021 7:57 pm Post subject: |
|
|
If this data was not the backup, I'd have taken it a little slower and tested the non-once-per-instance version of the command. I did a little more searching and netted this writeup someone did that advised overprovisioning of an SSD with HPA. I mean, I get it, but that's rather a rather hardcore limit instead of just creating a smaller partition.
https://www.thomas-krenn.com/en/wiki/SSD_Over-provisioning_using_hdparm
Edit:
Possibly the mount command has a HPA check that prevented operation from continuing???
Edit 2:
fsck-ing checked out fine. All systems go. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54408 Location: 56N 3W
|
Posted: Sun Jan 31, 2021 9:01 pm Post subject: |
|
|
DigitalCorpus,
SSDs are over provisioned anyway. There is no need to 'footer' with a HPA.
Look at smartctl -a to see the over provisioning.
Code: | ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
180 Unused_Reserve_NAND_Blk 0x0033 000 000 000 Pre-fail Always - 4403 |
_________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
DigitalCorpus Apprentice
Joined: 30 Jul 2007 Posts: 283
|
Posted: Sun Jan 31, 2021 9:17 pm Post subject: |
|
|
Neddy,
I'd say the overprovisioning is dependent upon model and manufacturer. The MX500 and 2 860 EVOs I have have none listed under ID 180 or any similarly named ID listed out by smartctl. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54408 Location: 56N 3W
|
Posted: Sun Jan 31, 2021 9:25 pm Post subject: |
|
|
DigitalCorpus,
It will still be there. Its the only way to cope with manufacturing defects and through life sector fails.
Its been on rotating rust HDD for over 20 years now, hence you never find any bad sectors on a HDD until its end of life. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
DigitalCorpus Apprentice
Joined: 30 Jul 2007 Posts: 283
|
Posted: Mon Feb 01, 2021 1:33 am Post subject: |
|
|
Needy,
Yes, it is there, but as Adandtech has pointed out over the years, it’s largely an unpublished spec. So if this were a write-heavy drive, I’d be adding a 10-20% on top of the unknown for performance consistency’s sake. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54408 Location: 56N 3W
|
Posted: Mon Feb 01, 2021 9:57 am Post subject: |
|
|
DigitalCorpus,
Agreed. It will be 10% or less though. Silicon storage is made in chunks of 2^n.
The 10% comes from the approximate difference between 1000 and 1024. That's kB or kiB.
Any more would need an extra address bit on the controller, which pushes up the cost. Any less is cost savings to the manufacturer.
Reducing it too far will upset buyers and push up the costs due to warranty returns. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|