Indeed if a SSD doesn’t trim, then every write to a previously written block must first be read, erased, modified, and re-written to the same location thus crippling write performance.
Since I have run quite some benchmark tests, and massively copied large files such .vmdk and .iso files and deleted them all afterward, the write performance got lower and lower.
My TS-459 runs a Linux QNAPNAS02 188.8.131.52 which does support natively TRIM function but I was sad to learn that while it’s available, it is not used at all because it is inadequate for today’s real TRIM hardware. This is not a QNAP problem but an issue with the Linux kernel developers. In the interim Mark Lord, who’s by the way one of those Linux kernel people, he created wiper.sh to manually trim SSD’s like my Intel one.
That being clarified, let’s go back to my blog post topic, how to get wiper.sh running on a QNAP storage device, a TS-459 Pro for instance, so I can trim my Intel SSD?
Well, it did not go straight doh! There were many issues and problems that I had to work around to finally get this thing running and trimming my SSD. I describe here all the steps it took me to achieve that, so bear with me please:
The script requires some tools to be installed prior running the script. Unfortunately or I should say fortunately QNAP doesn’t install by default, for security and stability reason, all the bits and bytes available for Linux. Instead and that’s clever from QNAP, you can install QPKG’es which are QNAP or community all in one software packages that you install using the IPKG tool. Thus here are the additional packages that you have to install:
- HDPARM (./ipkg install hdparm)
- GAWK (./ipkg install gawk)
- BUSYBOX to get the STAT tool (./ipkg install busybox)
- BLKID (./ipkg install e2fsprogs)
- RDEV and other nice to have tools (./ipkg install util-linux)
Copy the wiper.sh script onto the QNAP storage device
This one doesn’t come with the HDPARM package, thus you can download it from Sourceforge.com and copy only the wiper.sh script to /share/MD0_DATA/.qpkg/Optware/sbin
Edit the wiper.sh script
There is a HDPARM that comes built-in my QNAP storage device but it is too old. Installing the new HDPARM package created an HDPARM-HDPARM executable that we need to reference in the script. Thus edit wiper.sh with vi and locate HDPARM=`find_prog /sbin/hdparm` || exit 1 that you change to HDPARM=`find_prog /sbin/hdparm-hdparm` || exit 1
Write and quit the editor, then next make sure you can execute wiper.sh script by applying a chmod +x wiper.sh
The RDEV issue and workaround
If you run the wiper.sh script now, most probably you’ll get this error message /usr/sbin/rdev: needed but not found, aborting
This one sux! Looks like the RDEV tool is not anymore used in many Linux distro’s. Well it is not part of this Linux-Util package anymore thus I had to work around it. Hopefully Google is my best friend and I could solve the problem using the following steps:
- run df to get the list of root devices
- Now you need to stick the root device in /usr/sbin/rdev:
Filesystem Size Used Available Use% Mounted on
/dev/ram 124.0M 110.3M 13.7M 89% /
tmpfs 32.0M 120.0k 31.9M 0% /tmp
/dev/sda4 310.0M 156.4M 153.5M 50% /mnt/ext
/dev/md9 509.5M 48.3M 461.2M 9% /mnt/HDA_ROOT
/dev/sdc3 145.2G 78.0G 67.2G 54% /share/HDC_DATA
/dev/md0 547.2G 227.3G 319.9G 42% /share/MD0_DATA
/dev/sds1 37.2G 17.3G 20.0G 46% /share/external/sds1
vi /usr/sbin/rdev and insert:
Write and quit the editor, then next make sure you can execute the tool with the proper account:
chmod +x /usr/sbin/rdev
N.B. Big thanks to Micke for this one!
Note for EXT3 volumes
If you run an EXT3, make sure you un-mount the file system:
umount /dev/sdc3 or umount -l /dev/sdc3
N.B. You don’t suffer from this restriction with EXT4.
Let’s do a dry-run first
Run the wiper.sh script from /share/MD0_DATA/.qpkg/Optware/sbin directory:
bash wiper.sh –verbose /dev/sdc3
The output may look similar to this:
wiper.sh: Linux SATA SSD TRIM utility, version 3.1, by Mark Lord.
--> using /opt/sbin/hdparm-hdparm instead of /sbin/hdparm-hdparm
--> using /opt/bin/stat instead of /usr/bin/stat
--> using /opt/bin/gawk instead of /usr/bin/gawk
--> using /opt/sbin/blkid instead of /sbin/blkid
--> using /usr/sbin/rdev instead of /usr/sbin/rdev
--> using /usr/sbin/rdev instead of /usr/sbin/rdev
wiper.sh: line 260: /usr/sbin/rdev: Permission denied
--> using /opt/sbin/dumpe2fs instead of /sbin/dumpe2fs
Preparing for offline TRIM of free space on /dev/sdc3 (ext3 non-mounted).
This will be a DRY-RUN only. Use --commit to do it for real.
Simulating TRIM operations..
(dry-run) trimming 140902656 sectors from 2792 ranges
Time to run the script for good
The verbose mode showed that we don’t have any show stopper issue anymore thus let’s run the script for good now with the –commit option. Still you run the wiper.sh script from /share/MD0_DATA/.qpkg/Optware/sbin directory:
bash wiper.sh –commit /dev/sdc3
The script ran successfully and trimmed sectors that were marked as deleted by the OS but cells were not emptied by the SSD.
Don’t forget to read the disclaimer below and if you dare running the script in your home lab, thus happy trimming 🙂
DISCLAIMER. THIS INFORMATION IS PROVIDED TO YOU “AS IS” WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, WHETHER ORAL OR WRITTEN, EXPRESS OR IMPLIED. THE AUTHOR SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OR CONDITIONS OF MERCHANTABILITY, SATISFACTORY QUALITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE AND SHALL NOT BE LIABLE FOR ANY DAMAGES ARISING OUT OF OR IN CONNECTION WITH THE USE OF THIS CONTENT, INCLUDING DIRECT, INDIRECT, CONSEQUENTIAL DAMAGES, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF THE AUTHOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.