Ahci(4) needed for TRIM
-
Hi Folks – I installed a snapshot (14-June) on a system with a new 64G SanDisk SSD. AHCI is enabled in the bios, and I turned on TRIM after install, as described here: http://redmine.pfsense.org/issues/2319
But dmesg shows trim is not enabled:
[Trying to mount root from ufs:/dev/ad4s1a WARNING: /: TRIM flag on fs but disk does not support TRIM[/code] Seems that the ahci driver is needed for trim to work, but not being used: ahci disks would show up as ada4, while the above shows ad4 so the older ATA driver is being used. I will try [code]ahci_load="YES"[/code] in /boot/loader.conf, but I doubt it will work as I don't see any ahci kernel modules to load. Even if I could enable ahci *after* install, another problem would be the device name changing from ad4 to ada4 (for example), and the boot failing. Any idea how I can force ahci to be used during a re-install? Is ahci built into the default kernel config? Thanks
-
I have this message also and I have different SSD.
But if you check this page http://doc.pfsense.org/index.php/Boot_Troubleshooting you will find that AHCI is recommended mode for the pfsense and for my pfsense AHCI is enabled in BIOS. I am not sure about how freebsd can work using ATA driver in AHCI mode, but my ssd is ad4, also.Device name changing interrupts the boot, but you can manually type the path to boot and then change it in fstab.
For example the current boot path is /dev/ad4s1a
and the new one should be /dev/ada4s1a -
I've installed trim on all my partitions, including the separate "/var" partition with softupdates I had chosen from first install.
Here is in short what I did to get it to work:
-
Download the iso of freebsd 8.3 copy the "ahci.ko" into /boot/kernel/
-
chmod "ahci.ko" to r-xr-xr-x (0555)
-
Check if loads in the console, "kldload ahci" & "kldstat"
-
edit loader.conf to add ahci_load="YES"
-
reboot.
-
at the loader prompt "mountroot" type "?" for list of options.
-
at the loader prompt "mountroot" type "ufs:/dev/ada0s1a" (ada0;ada1;ada4 will depend on chipset used)
-
now that / root is mounted, /bin/sh for a shell
-
vi /etc/fstab
-
change and save the all mountpoints accordingly, including swap. (ada0;ada1;ada4 will depend on chipset used)
-
reboot.
-
pfsense will now boot like before if you have edited fstab correctly.
-
perform the TRIM_set action. http://redmine.pfsense.org/issues/2319
-
I noticed that only "/" is set to support TRIM, check with "tunefs -p /"
-
reboot.
-
choose option 5 (single user mode)
-
type: "tunefs -t enable /dev/ada0s1d" to enable TRIM on the other partion "/var"
-
reboot.
-
check support TRIM, check with "tunefs -p /" & "tunefs - p /var"
My AHCI controler is AMD based, so my partitions became "ada0s1a" for / & "ada0s1d" for /var
$ tunefs -p / tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L)
$ tunefs -p /var tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L)
partial dmesg:
$ dmesg |grep ada0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: <m4-ct064m4ssd2 040h=""> ATA-9 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes) ada0: Command Queueing enabled ada0: 61057MB (125045424 512 byte sectors: 16H 63S/T 16383C)</m4-ct064m4ssd2>
-
-
This did the trick! Thanks Tikimotel .
Only one thing that I did not - tunefs trim enable for var partition, as it was already enabled.
And my mistake was thinking that ad4 became ada4, wrong! :) it's ada0 now -
Just be careful when updating the builds.
Updating deletes the "ahci.ko" from the /boot/kernel folder.
So you'll have to do the opposite with mountroot, to mount the "/" partition (mount the non ahci name again), boot for a bit and copy "ahci.ko back again and reboot and finish/or re-install the packages. -
This would be good to include ahci.ko to the next builds. I hope jimp read this.
So we don't really need the option to enable trim during install for the 2.1, that is RC already, but at least it could be documented in some new ssd section of pfsense docs later and user can change the default driver if needed. I think including ahci.ko into boot kernel would not cause to drop rc stage back to alpha or beta ;) -
Have you tried the "ahci.ko" in the "/boot/modules/" instead the "/boot/kernel/" ? To avoid it to be deleted, when update….
-
Trying right now…
Yes, it works! Thanks for the hint, ptt!
-
Thanks guys! I will do this later tonight.
I second the idea of including ahci.ko in the pfSense build. It would be great to have a way to enable TRIM with pfSense 2.1 without having to download FreeBSD 8.3 release, and worry about breaking your system with an update. Would be pretty innocuous as a module in the /boot/modules directory, and there would be no worries about compatibility of modules from different compiler versions.
Even booting FreeBSD 8.3 or 8.4 live fixit mode, my SSD is detected as ata by default, not ahci. So including it as a module should be very safe.
Thanks ….... Charlie
-
@ptt:
Have you tried the "ahci.ko" in the "/boot/modules/" instead the "/boot/kernel/" ? To avoid it to be deleted, when update….
Awesome that did it!
-
Fantastic tutorial!! Thanks Tikimotel and PTT ;D
Updated tutorial for the ahci_load="YES" to be edited into /boot/loader.conf.local
That way it will persist through firmware updates because the /boot/loader.conf is overwritten during updates as well.
For pfSense 2.1, Enable AHCI and TRIM for SSDs. 1\. Download the ISO of FreeBSD 8.3 and copy the "ahci.ko" into /boot/modules/ 2\. chmod 0555 ahci.ko (r-xr-xr-x) 3\. Check if loads in the console, "kldload ahci" & "kldstat" 4\. Edit /boot/loader.conf.local to add ahci_load="YES" 5\. Reboot 6\. At the loader prompt "mountroot" type "?" for list of options. 7\. At the loader prompt "mountroot" type "ufs:/dev/ada0s1a" (ada0;ada1;ada4 will depend on chipset used) 8\. Once booted edit /etc/fstab and change and save the all mountpoints accordingly, including swap. (ada0;ada1;ada4 will depend on chipset used) 9\. Reboot pfSense will now boot like before if you have edited fstab correctly. 10\. Perform the TRIM_set action at a shell. touch /root/TRIM_set; /etc/rc.reboot to remove touch /root/TRIM_unset; /etc/rc.reboot 11\. Reboot 12\. Check if TRIM is enabled with "tunefs -p /"
-
Great, worked right away! I verified the module would load, then edited /etc/fstab, changing ad4 to ada0 and rebooted. I got lucky: with my intel chipset, the SSD came up as ada0
Maybe this should be in the release notes? Or at least point to this thread in http://redmine.pfsense.org/issues/2319. No use in documenting /root/TRIM_set if more work is needed to get TRIM working.
Thanks again
-
You can get the needed "ko" modules from here:
FreeBSD 8.1: http://files.pfsense.org/jimp/ko-8.1/
FreeBSD 8.3: http://files.pfsense.org/jimp/ko-8.3/
Thanks goes to Jimp ;)
Also say thanks to Jimp about the " xxxx.ko on the /boot/modules/" advice ;)
http://forum.pfsense.org/index.php/topic,39595.msg205010.html#msg205010
-
Thanks jimp! :D
Looks like using rc.conf.local is not really needed, because during update rc.conf is edited, not deleted, so my things added into rc.conf years ago are still working. But to be safe… yes it's not bad to use rc.conf.local instead
-
smartctl 6.1 2013-03-16 r3800 [FreeBSD 8.3-RELEASE-p8 i386] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org /dev/: Unable to detect device type Please specify device type with the -d option. Use smartctl -h to get a usage summary
I am getting this when trying to get S.M.A.R.T., after ahci enabled, any suggestions?
-
@w0w:
I am getting this when trying to get S.M.A.R.T., after ahci enabled, any suggestions?
The device name changed with ahci, ie from ad4 to ada0 in my case, and the extra 'a' is not being picked up by the regexp in diag_smart.php
This change to /usr/local/www/diag_smart.php will pick up the devices with the extra 'a', if it's there.
--- diag_smart.php.orig 2013-06-27 22:25:23.000000000 -0400 +++ diag_smart.php 2013-06-27 22:20:08.000000000 -0400 @@ -277,7 +277,7 @@ default: { // Get all AD* and DA* (IDE and SCSI) devices currently installed and stores them in the $devs array - exec("ls /dev | grep '^[ad][da][0-9]\{1,2\}$'", $devs); + exec("ls /dev | grep '^[ad][da]a*[0-9]\{1,2\}$'", $devs); ?>
-
Thank you charliem!
Hmm, may be it should be submitted here - https://github.com/pfsense/pfsense/blob/master/usr/local/www/diag_smart.php ?Or somebody can do the patch that can be applied with "Patches" package. This one posted does not look compatible.
I have patched manually but…
Patch works via "System Patches" package. Sorry ;) -
Use with caution!
I've cleaned up the "patch" a bit and added one extra for the dashboard widget! ;D1st:
Description : "AHCI SMART fix"--- diag_smart.php.orig 2013-06-27 22:25:23.000000000 -0400 +++ diag_smart.php 2013-07-16 22:20:08.000000000 -0400 @@ -280,1 +280,1 @@ - exec("ls /dev | grep '^[ad][da][0-9]\{1,2\}$'", $devs); + exec("ls /dev | grep '^[ad][da]a*[0-9]\{1,2\}$'", $devs);
Base Directory: "/usr/local/www/"
(Please test first!!! Line numbers may change or the patch may not be needed in the future!!!)2nd (for dashboard widget) ;)
Description : "ACHI dashboard fix"--- smart_status.widget.php.orig 2013-07-16 22:25:23.000000000 -0400 +++ smart_status.widget.php 2013-07-16 22:20:08.000000000 -0400 @@ -45,1 +45,1 @@ - exec("ls /dev | grep '^[ad][da][0-9]\{1,2\}$'", $devs); ## leant from orginal SMART status screen + exec("ls /dev | grep '^[ad][da]a*[0-9]\{1,2\}$'", $devs); ## leant from orginal SMART status screen
Base Directory: "/usr/local/www/widgets/widgets/"
(Please test first!!! Line numbers may change or the patch may not be needed in the future!!!)It works for me..
-
I think this is great, but TRIM on a SSD is so common like dirt by now and required, that it should either be:
1. Something that is just automagically detected and applied (like it does for any other common device)
or
2. Asked at initial install "would you like to enable TRIM on this device."
Maybe next decade.
-
AHCI is great! for TCQ & NCQ on normal HDD's not just for TRIM on SSD's.
"ada0: Command Queueing enabled"And for SATA 6Gbs support.
ada0: 600.000MB/s transfers (SATA 3.x, UDMA5, PIO 8192bytes) -
The AHCI module should be included in snapshots now (I just updated a VM and checked, it's there).
Also look at /usr/local/sbin/ufslabels.sh - that would eliminate the need to make any fstab edits.
Too late for 2.1 to grow an installer option for it, but perhaps for 2.2.
-
Thanks Jimp, just started a fresh installation on my main pf box using a new SSD and tried out the latest snap. Works perfectly.
Couldnt figure out how to run the ufslabels.sh file. Getting a permission denied at a shell, so just edited fstab the old fashioned way.
-
It's just missing exec bits
chmod a+x ufslabels.sh; ./ufslabels.shOr:
sh ufslabels.shI pushed a fix to correct the exec bits, it'll turn up in shapshots eventually
-
Does that printout look normal with the unexpected operator? End result seems to be correct.
[2.1-RC0][root@pfsense@pfsenseuser.net]/root(17): chmod a+x /usr/local/sbin/ufslabels.sh ; /usr/local/sbin/ufslabels.sh FS: / on device ada0s1a with ufsid 51f5bc9c854a3254 FS: Swap on device ada0s1b ==================== Current fstab: # Device Mountpoint FStype Options Dump Pass# /dev/ada0s1a / ufs rw 1 1 /dev/ada0s1b none swap sw 0 0 ==================== New fstab: # Device Mountpoint FStype Options Dump Pass# /dev/ufsid/51f5bc9c854a3254 / ufs rw 11 /dev/label/swap none swap sw 0 0 [: =: unexpected operator Commit changes? (y/n): y Disabling swap to apply label Applying label to swap parition Activating new fstab Re-enabling swap[/code]
-
That's not fatal (it was in code to auto-commit the changes if you passed in the right command line parameter), but it isn't relevant to using it interactively, so you can proceed from there.
-
Looks like SMART is also fixed
https://redmine.pfsense.org/projects/pfsense/repository/revisions/ccf479876283082b39ac9a37c1c6308f4857a6f0/diffThanks jimp!
-
For completeness the smart dashboard widget needs the same fix.
-
-
I just forgot about the widget entirely in the previous commit.
Done now though:
https://github.com/pfsense/pfsense/commit/0aa297594cd1882f32d52074ba3546c4f5f97c8e -
Thanks to your guides I think I have enabled TRIM on my SSD:
/root(5): tunefs -p / tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L)
and from dmesg
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: <ts16gssd25s-s v1210=""> ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 512bytes) ada0: Command Queueing enabled ada0: 15272MB (31277056 512 byte sectors: 16H 63S/T 16383C) lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ufsid/51fa1b22d7786f5c WARNING: /: TRIM flag on fs but disk does not support TRIM</ts16gssd25s-s>
Why is there still that last line that my disk doesn't support it?
I have this one:
=== START OF INFORMATION SECTION ===
Model Family: JMicron based SSDs
Device Model: TS16GSSD25S-S
Serial Number: 00246293003C
Firmware Version: V1210According to data sheet it does support trim command.
-
It appears you have a similar drive to mine, these drives are older and do not support TRIM.
Model Family: JMicron based SSDs
Device Model: TS32GSSD25S-M -
That's weird because on this page:
http://www.transcend-info.com/industry/products_details.asp?ModNo=3&Func1No=1
Transcend says it does support it. Look at the Features tab and under Specifications SSD25S is named. I have the SLC and you have the MLC.
-
I'll be honest, its been years since i've read or done anything with this drive. Last I read (for mine) it didn't support TRIM, but had "Wear-leveling algorithm ensures reliable data transfer", which I had assumed was pre-TRIM. My drive has been happily sitting in my router doing its job. It wasn't until this thread that I started playing with it again.
Mine also doesn't appear to have command queueing either.
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: <ts32gssd25s-m 100415=""> ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 512bytes) ada0: 30560MB (62586880 512 byte sectors: 16H 63S/T 16383C) WARNING: /: TRIM flag on fs but disk does not support TRIM</ts32gssd25s-m>
I wonder if there is a newer firmware that adds TRIM?
EDIT:
I don't see in the spec sheets where either drive supports TRIM.
TS16GSSD25S-S
http://www.csee.umbc.edu/~squire/images/ssd3.pdf
http://c.master.lv/p/01/53/40/05/F611373.pdf -
Jmicron?
Be worried… Be very worried.
If I had a jmicron and just had to run it, I'd do everything possible to minimize writes.
Might even treat it like flash card just to be safe.
-
I did some further investigation and it seems that my Transcend drive (TS16GSSD25S-S) has no TRIM support, although I have found a lot of resources that say otherwise:
root: camcontrol identify ada0 | egrep TRIM\|Feature Feature Support Enabled Value Vendor data set management (TRIM) no
It is an SLC drive with an MTBF of 1.000.000 hours and wear leveling so I am not worried at all even though it has a JMicron controller. ;)
I have it running for about 4 years now as ext3 linux OS server with extensive logging (also not advised by many sources) and now lately for pfSense.
http://www.ssdworld.net/?p=tipsSsd's with a JMicron controller however (OCZ and Kingston models) have initially caused much disappointment and frustration.
Meanwhile the firmware of ssd's with a JMicron controller have been improved, but because people are very reluctant buying an ssd with a JMicron controller, it will take a while until the appreciation for those ssd's will improve. -
The AHCI module should be included in snapshots now (I just updated a VM and checked, it's there).
Also look at /usr/local/sbin/ufslabels.sh - that would eliminate the need to make any fstab edits.
Too late for 2.1 to grow an installer option for it, but perhaps for 2.2.
The module is there, but coming from a snapshot before the inclusion of the module, I still require ahci_load="YES" in boot.conf.local - it reverts to the ATA modules otherwise. Is there something I’m missing?
-
No, you'll need to load the AHCI module if you want it. That won't change for 2.1.
-
Great, at least it’s behaving as intended, then :)
Is there any persistent configuration set by the installer when installing with TRIM enabled though? Or will we have to flip the AHCI switch even if installing with TRIM enabled?
-
The installer knows nothing of TRIM currently.
-
I'd like to point out, the previous patches for the smart status page / widget are incorrect.
This code, at least for me, stops showing ad* devices, and da* devices. It does report ada* devices.exec("ls /dev | grep '^[ad][da]a*[0-9]\{1,2\}$'", $devs);
Should be: (and this appears to be the latest committed to pfsense)
exec("ls /dev | grep '^\(ad\|da\|ada\)[0-9]\{1,2\}$'", $devs);