SOLVED Removed vdev Log drive - Now shows incorrect (smaller) size in BIOS

Randy...

Cadet
Joined
Dec 30, 2020
Messages
9
I'm new to TrueNAS and Linux/Debian in general. My Drobo died a while back, so I've been playing with TrueNAS since the 12.0 U1 release came out.

As I was playing around with my first TrueNAS build, I created a RAID-z2 pool with 5x 5TB data drives and a spare 4TB VDEV ZFS LOG drive (since I could not add it as a data drive in the z2 pool, and it was already physically installed in the system - I just had to use it for something!). It worked, but I decided to start over on a new faster MoBo/CPU/RAM w/o the additional 4TB VDEV ZFS LOG drive - and removed the 4TB drive from the build. The new build is working very well!

Now, when I place that 4TB WD Black drive in any computer, BIOS shows it as approx. 7.5GB. I've tried most methods of clearing the partition table (cmd diskpart / gparted boot disk / WD Data Lifeguard erase function). The 4TB drive continues to be reported as a 7.5GB drive at the BIOS level and from any software I use to see it (including GRC's Spinrite).

I've searched to the best of my ability, but I cannot seem to figure out how to resolve this issue - especially seeing as the issue seems to be at the low-level drive controller domain (not a partition table/MBR/GPT/ZFS type issue). The drive worked fine before I tried to use it as a TrueNAS LOG drive...

Thanks for throwing me any pointers :)
Randy V.
 

Randy...

Cadet
Joined
Dec 30, 2020
Messages
9
Bumping this for any pointers. I thought I was on the right track with trying to delete the partition table - but that doesn't seem to resolve the issue.

TLDR - Removed a 4TB WD Black drive that was momentarily used as a vdev ZFS log drive - now it shows as a 7.5GB drive in any other system...

Grazie!
Randy V.
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
Did you by chance configure overprovisioning of the log drive in TrueNAS? The way that works is it alters the firmware of the drive to report less usable capacity to the controller.
 

Randy...

Cadet
Joined
Dec 30, 2020
Messages
9
Hello Samuel - and thanks for your reply!

Possibly so. If so, how would I "undo" that action?
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
Not easily. What's the exact model number of your Black?
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
OK, in all likelihood, this drive is permanently set at this low capacity now, but there's a slight chance we might be able to undo it.

First, I was able to find out the maximum sector count for this model: 7814037168.
Next, is this drive back in your TrueNAS system? If not, please reconnect it, but don't make it part of any pool. If it shows back up in a pool, remove it from the pool.

Let's say this is /dev/ada2 in your system. You'll want to run: camcontrol hpa /dev/ada2 to show the HPA parameters. In particular, you'll want to see the max sector count in the HPA. On my system this shows 7814037168/7814037168; i.e., I can address up to the maximum sector count of that 4 TB drive.

On your drive, this may be set to something absurdly low. Please report what your max addressable sector is.

Changing this max addressable sector can only be done once per power-on of the drive, via

camcontrol hpa /dev/ada2 -s 7814037168 -P. However, chances are this won't succeed, as there may have been an HPA password set, and we won't know what the password is.
 

Randy...

Cadet
Joined
Dec 30, 2020
Messages
9
Samuel - Thank you again for your continued support. I have many drives 'laying around' - but effectively losing a nice 4TB drive with much life remaining is something I'd like to resolve :)

Understood - I will re-install the drive (temporarily) and report back with my findings ASAP. Likely later this week or next week (busy with work tasks this week).

My current/only TrueNAS instance is different from the initial system where this drive was installed - but I used the same root user/PW if that has any potential benefits towards a possible recovery. I have many other systems (including the original MoBo/CPU/RAM this drive was installed in) to play with, and my current TrueNAS build is a redundant backup for two other hardware based Areca RAID-6 systems - so not much to lose if I screw something up in the process of drive recovery.

In the past, I've also cobbled together a repair of a different drive using the drive's auxiliary serial port and TTL commands - but that was many moons ago if that has any possible implications here...

Thanks again for your generous offer to assist!

RV
 

Randy...

Cadet
Joined
Dec 30, 2020
Messages
9
Checking in with an update for Samuel or anyone that is following along. Been an interesting month in Houston with the freeze of a century and being informed I will be laid off as of March 31st. I'll have lots of free time to play with this issue further in April. Will report back then :cool:
 

Randy...

Cadet
Joined
Dec 30, 2020
Messages
9
Hello all,

I finally had a chance to play with this. And I'm glad to say @Samuel Tai 's suggestion worked!

Luckily, the HPA password was not set, and I was able to execute the command to re-recognize the missing freespace.

Thanks a million kind sir!

Randy V.
 

Samuel Tai

Never underestimate your own stupidity
Moderator
Joined
Apr 24, 2020
Messages
5,399
Excellent news!
 
Top