Don't know when exactly this started, but running ssd trim (/sbin/fstrim -v /mnt/cache) returns "fstrim: /mnt/cache: the discard operation is not supported".

The SSD is a Crucial MX300 connected directly to my motherboard (ASUS Z97-A). It's encrypted using the tools implemented in one of the recent RC's.

Tried to Google and the only results I found where talks about it not working over USB/E-SATA but that doesn't apply to me, I also found some talk about it not working with encryption?

Edited December 10, 20178 yr by zin105

1 hour ago, zin105 said:

Don't know when exactly this started, but running ssd trim (/sbin/fstrim -v /mnt/cache) returns "fstrim: /mnt/cache: the discard operation is not supported".

The SSD is a Crucial MX300 connected directly to my motherboard (ASUS Z97-A). It's encrypted using the tools implemented in one of the recent RC's.

Tried to Google and the only results I found where talks about it not working over USB/E-SATA but that doesn't apply to me, I also found some talk about it not working with encryption?

 

Use of encryption with SSD TRIM is something of a touchy issue in crypto-land.  Here is a starting place on the Arch wiki to research:

https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Discard.2FTRIM_support_for_solid_state_drives_.28SSD.29

 

unRAID does not enable TRIM at the dm-layer (where encrypted devices are mapped).  We may offer a config setting to let you enable it but you will really have to know what you are doing and what the security ramifications are.

 

Another possibility is to use devices with hardware based Full DIsk Encryption:

https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption

On 12/10/2017 at 12:17 PM, limetech said:

 

Use of encryption with SSD TRIM is something of a touchy issue in crypto-land.  Here is a starting place on the Arch wiki to research:

https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Discard.2FTRIM_support_for_solid_state_drives_.28SSD.29

 

unRAID does not enable TRIM at the dm-layer (where encrypted devices are mapped).  We may offer a config setting to let you enable it but you will really have to know what you are doing and what the security ramifications are.

 

Another possibility is to use devices with hardware based Full DIsk Encryption:

https://en.wikipedia.org/wiki/Hardware-based_full_disk_encryption

 

Is there any further update on adding this as a setting? or a guide somewhere on how to manually update the necessary configs?  My disk encryption use case is mostly just a first line of defense against physical theft of my unraid box. This is just a home install so the most sensitive data is stuff like tax returns and medical bills.

 

So If a theft were to happen then my personal data is relatively safe from someone just booting the machine, or pulling the drive and trying to extract the contents.  If my drive is in the hands of someone sophisticated and determined enough to try to exploit the gaps left by using TRIM on an encrypted drive then they probably have easier ways to get that data anyway...

 

With that in mind I'd prefer to have the performance and durability benefits of TRIM over the additional security.  I understand that in other use cases the security is the most critical thing but I would imagine those users are more likely to roll their own solution than take something off the shelf.

13 hours ago, atconc said:

With that in mind I'd prefer to have the performance and durability benefits of TRIM over the additional security.  I understand that in other use cases the security is the most critical thing but I would imagine those users are more likely to roll their own solution than take something off the shelf.

 

Note that with 15-20% overprovisioning, you can get quite far even without TRIM. Some drives can automatically do overprovisioning if the used partition isn't making use of the full drive size. But it requires that the drive has been fully erased from the start, so the drive doesn't think there are actual data stored in the unpartitioned region.

 

https://www.anandtech.com/show/8216/samsung-ssd-850-pro-128gb-256gb-1tb-review-enter-the-3d-era/7

 

On 8/19/2018 at 2:15 AM, pwm said:

 

Note that with 15-20% overprovisioning, you can get quite far even without TRIM. Some drives can automatically do overprovisioning if the used partition isn't making use of the full drive size. But it requires that the drive has been fully erased from the start, so the drive doesn't think there are actual data stored in the unpartitioned region.

 

https://www.anandtech.com/show/8216/samsung-ssd-850-pro-128gb-256gb-1tb-review-enter-the-3d-era/7

 

 

I'd rather not give up that much capacity if possible, so being able to enable trim, with my eyes open to the security impact would be good.

7 hours ago, atconc said:

 

I'd rather not give up that much capacity if possible, so being able to enable trim, with my eyes open to the security impact would be good.

 

Note that TRIM only works on unused surface. So if you haven't a significant percent free space then TRIM will not be efficient. And if you haven't a significant percent free space, then the wear on the flash will greatly increase when the flash controller has to move data around which means it erases a block of data and directly writes back half of the content one more time.

 

For first-generation SSD, each flash block could handle 100k erase cycles. Then it became 40k. Then 10k. Then 3k. Most of todays SSD have flash that can handle 300-400 erase cycles. And if you have a factor 20 write amplification, then you get 400 / 20 which means you end up only being able to write the full capacity 20 times before you have introduced 400x full disk writes on the actual flash media.