Format SSD to 4Kn with Samsung DC Toolkit 2.1 for Linux?
- Thread starter MuscleLazy
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
I have the GXT32F3Q installed, I'll check if I can get it extracted and share it. I don't think there is an easy tool to extract the firmware, openSeaChest has one but is designed only for Seagate disks.
Last edited:
It does not, same 512e support only. As a side note, DCToolkit has a nice feature showing you how my data was written to each disk, so you know what's left for the disk endurance:
I paid for the PM883s 960GB on eBay $40 each, they have the wear at 87-89%, plenty to go until 0%:
The PM863s 240GB are at 99% wear.
Code:
# ./DCToolkit --list
================================================================================================
Samsung DC Toolkit Version 2.1.L.Q.0
Copyright (C) 2017 SAMSUNG Electronics Co. Ltd. All rights reserved.
================================================================================================
----------------------------------------------------------------------------------------------------------------------------------------------
| Disk | Path | Model | Serial | Firmware | Optionrom | Capacity | Drive | Total Bytes | NVMe Driver |
| Number | | | Number | | Version | | Health | Written | |
----------------------------------------------------------------------------------------------------------------------------------------------
| 0 | /dev/sda | SAMSUNG MZ7LH960HAJR-00005 | xxxxxxxxxxxxxx | HXT7A04Q | N/A | 894 GB | GOOD | 746.10 TB | N/A |
----------------------------------------------------------------------------------------------------------------------------------------------
| 1 | /dev/sdb | SAMSUNG MZ7LH960HAJR-00005 | xxxxxxxxxxxxxx | HXT7A04Q | N/A | 894 GB | GOOD | 838.62 TB | N/A |
----------------------------------------------------------------------------------------------------------------------------------------------
| 2 | /dev/sdc | SAMSUNG MZ7LH960HAJR-00005 | xxxxxxxxxxxxxx | HXT7A04Q | N/A | 894 GB | GOOD | 857.98 TB | N/A |
----------------------------------------------------------------------------------------------------------------------------------------------
| 3 | /dev/sdd | SAMSUNG MZ7LM240HCGR-00003 | xxxxxxxxxxxxxx | GXT32F3Q | N/A | 223 GB | GOOD | 0.26 TB | N/A |
----------------------------------------------------------------------------------------------------------------------------------------------
| 4 | /dev/sde | SAMSUNG MZ7LM240HCGR-00003 | xxxxxxxxxxxxxx | GXT32F3Q | N/A | 223 GB | GOOD | 0.26 TB | N/A |
----------------------------------------------------------------------------------------------------------------------------------------------
Code:
# smartctl -a /dev/sda | egrep 'FLAG|Wear'
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
177 Wear_Leveling_Count 0x0013 089 089 005 Pre-fail Always - 801
245 Timed_Workld_Media_Wear 0x0032 100 100 000 Old_age Always - 65535
Last edited:
just interest part is that when they format it as 512e (in 4kn) they actually inflate iops.
(at least in my own tests) performance stays about same though. You do gain space, as partition space, as well as file index are being written with better efficiency.
( i do recall some micron enterprise SSD having issues with overprovisioned memory when in 4kn - but manually blocking off more from it solved that odd issue.)
I don't think this will work, because the firmware-update-file is encrypted/signed, and the "F" indicates in most cases that this is not an OEM Drive.
The "NF" in the firmware-file name means noformat, it should work without formatting/secure-erasing, but don't count on it (Backup), most are NF even if it's not in the filename.
FW-version is the fifth digit: GXT5404Q, JXTE204Q, ...
It works anyway with ashift=12 and its better to do so in ZFS (it's default in actual TrueNAS versions). I personally give some more over-provisioning via HPA (hdparm -Np1562500000 --yes-i-know-what-i-am-doing /dev/sdX), between 15% - 28% keeps the write-amplification low -> more room for garbage collection -> less wear, and enhances write performance.
Overprovisioning on SATA-SSD's
How this is different from creating partition/allocating eg 85% of total available space of media ? Aren't most if not all internal FW OP mechanisms working this way (checking what's free and using it for internal OP) ? Or is there some sort of OP on file-system level, which I have not heard of yet ?
Thats true, you can do it this way, no real difference internally i believe. With the HPA-method it makes the space mostly inaccessible by OS, and shows the drive with the capacity you set plus doesn't tempt you to free up the rest of the available space afterwards...