Ahci(4) needed for TRIM
-
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) noIt 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); -
The old regex worked fine when I tested it, e.g.
$ cat test.txt ad0 da0 ada0 $ grep '^[ad][da]a*[0-9]\{1,2\}$' test.txt ad0 da0 ada0 $ ls /dev | grep '^[ad][da]a*[0-9]\{1,2\}$' ad4 ad6 ada0 ada1 da0The newer one is definitely better, but the old one wasn't broken on any system I tried it on.
-
This thread got TRIM enabled on an AMD64. Curious if "time" is the best optimization method or if it's even worth looking into.
[2.1-RC1][admin@pfsense.router]/(2): 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)
