Hi
Honestly I think the Intel folks is your best course of action, after all it’s their product 
They should have some low level tools to sort it out I imagine…
This Intel page is a profound nightmare. I entered the ISN and it said I have Warranty until something-2021. Then I made an Intel account (the next script and XSS nightmare) and logged in. Entered the SAME ISN again and now the webpage tells me
Product not found. Check the information you provided and try again, or create a support request for help identifying this product.
I’m so so sick and tired of these “get away” “customer support” systems…
I have here on TW:
ournalctl -b -u fstrim.service
-- Logs begin at Mon 2019-09-02 17:59:34 CEST, end at Tue 2019-09-03 09:01:36 CEST. --
-- No entries --
Any way to go back in history?
-b limits search to current boot.
Hmm:
sudo journalctl -u fstrim.service
[sudo] password for root:
-- Logs begin at Tue 2019-09-03 12:34:58 CEST, end at Tue 2019-09-03 12:59:15 CEST. --
-- No entries --
…but I must confess, Intel provided me with an unofficial FW-update for the read-only SSD. However, the boot SSD wit TW in this machine (I applied the FW update on…) has an SSD of the exact same type and series. So the FW update was applied to BOTH the read-only and the boot SSD (a CLI tool which did NOT ask for which SSD it should apply the update to). Sigh…
The log is very short. You may check for /var/log/journal Create it if nonexistent.
“The journal service stores log data either persistently below /var/log/journal or in a volatile way below /run/log/journal/ (in the latter case it is lost at reboot). By default, log data is stored persistently if /var/log/journal/ exists during boot, with an implicit fallback to volatile storage otherwise. Use Storage= in journald.conf(5) to configure where log data is placed, independently of the existence of /var/log/journal/.”
https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html
Hey, thanks!
In /var/log there was no “journal” directory. Should be effective after next reboot. I will have a look.
Intel SSD is apparently back to life now, no idea if I can really trust this little monster any longer (have identical SSDs in router/firewall :-/ ).
TWIMC:
Problem with the Intel 530/535 SSDs is high HAND write:
241 Host_Writes_32MiB 0x0032 100 100 000 Old_age Always - 47642
242 Host_Reads_32MiB 0x0032 100 100 000 Old_age Always - 31544
249 NAND_Writes_1GiB 0x0032 100 100 000 Old_age Always - 32467
Therefore you have to apply a special FW update. Not available without accessing Support, afaik.
But that won’t take away the high NAND writes made in the past…
And has nothing to do with TRIM, or?
Sigh. I stay with HDDs where ever it’s really critial.
Just to be clear what the numbers from the SMART status (Linux) posted above mean, here the numbers from the Intel SSD tool:
F1 Total LBAs Written 1604.56 GB
F2 Total LBAs Read 985.84 GB
F9 Total NAND Writes 32494.00 GB
Hi
Why not just email their support and ask for the firmware?
I’m finding it hard to kill off this OCZ 60GB disk (btrfs)… the laptop it’s in will likely be replaced…
5 Retired_Block_Count 0x0033 100 100 003 Pre-fail Always - 1
9 Power_On_Hours_and_Msec 0x0032 039 039 000 Old_age Always - 54035h+08m+58.750s
231 SSD_Life_Left 0x0013 097 097 010 Pre-fail Always - 0
241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 25745
I have the custom firmware in the meantime, support was very helpful yesterday (we played email ping pong for some hours). 
I currently don’t have Tumbleweed installed, but I just made a fresh install of Leap 15.1 on a SSD during which I did not format the existing encrypted /home (luks, created with Leap 42.3). I just deleted the hidden files there (yes, I have a backup of the folder .thunderbird and the bookmarks of firefox).
Installation is done and most things run smooth now.
With still one exception:
# fstrim -v /
/: 17.8 GiB (19079819264 bytes) trimmed
# fstrim -v /home
fstrim: /home: the discard operation is not supported
#
From this it is obvious that in this case the output of
# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2019-09-10 11:26:08 CEST; 1h 1min ago
Trigger: Mon 2019-09-16 00:00:00 CEST; 5 days left
Docs: man:fstrim
is completely irrelevant with respect to /home, because fstrim may be run by some timer from time to time, but if fstrim doesn’t even work for /home if run manually, then it won’t work if run automatically either - with the difference that in the latter case the user won’t even take notice of that!
So, what should one say if the user trusts that everything with respect to trim is setup well in this case: happy wear?
The crypttab file generated by the 15.1 installer
cr-auto-3 /dev/sdb6
is a disaster, at least for having /dev/sdb6 instead of some /dev/disk/by-uuid/… or /dev/disk/by-id/… .
Under previous versions of Leap/openSUSE I did spend a bit of time getting fstrim work for an encrypted /home .
A question that I have: is the situation with respect to that better in Tumbleweed than in Leap 15.1 ?
After some back and forth I finally got fstrim working for /home again for Leap 15.1 - this time even using UUIDs …
For the sake of completeness: the fstab generated by the installer was
UUID=36c9cf12-4e80-4838-bed6-f3b0b8f2d796 / ext4 noatime,acl,user_xattr,nodiratime 0 1
UUID=c9711634-b09e-4167-8c08-b172e600c3e2 /home ext4 noatime,acl,user_xattr,data=ordered,nodiratime 0 2
UUID=76cca290-a1ef-43e8-b295-a3a704857f9e swap swap defaults 0 0
(I entered the parameter ‘nodiratime’ at “Arbitrary Option Value” in the “Fstab Options” of the partitioner).
In this the UUID of /home is the UUID of the volume within the encrypted partition, which can not be known unless that partition is decrypted or made accessible by the encryption algorithm.
Now I changed** crypttab **from (c.f. previous posting).
cr-auto-3 /dev/sdb6
to
cr_home /dev/disk/by-uuid/b5ee7005-3b4a-440b-9e58-d75836ae6101 none luks,discard
In the latter the UUID is the UUID of the (outer) partition that contains the encrypted volume, which can be known at boot, and which is not the same as the UUID for the (inner) volume with /home in the above version of fstab.
After that I changed** fstab **to
UUID=36c9cf12-4e80-4838-bed6-f3b0b8f2d796 / ext4 noatime,nodiratime,acl,user_xattr 0 1
/dev/mapper/cr_home /home ext4 noatime,nodiratime,acl,user_xattr,data=ordered,nofail 0 2
UUID=76cca290-a1ef-43e8-b295-a3a704857f9e swap swap sw,discard 0 0
In this, I included the parameter ‘discard’ for swap after looking around at the internet a bit, but I didn’t get to know a way to actually check if that really works.
Does somebody here know about such a way?
And the parameter ‘nofail’ for /home in this version of fstab should help to at least be able to log in to a root session if one should ever forget the password for the encrypted /home …
After these changes to crypttab and fstab and rebooting I got
# fstrim -v /home
/home: 27.4 GiB (29455220736 bytes) trimmed
#
So, now TRIM is enabled for my encrypted /home in my installation of 15.1 - which it was not, before!
Should work for Tumbleweed too, right?
I know this is an older post, but not sure if enabling TRIM on an encrypted SSD is a good idea as it can potentially leak data. It is disabled for a reason by default. You can find more related info on the matter here: dm-crypt/Specialties - ArchWiki
Hi and welcome to the forums!
In which way exactly, and when exactly, or under which conditions, could fstrim leak data?
On the page that you linked here, with respect to TRIM and encryption, two quite old and short postings from 2011 and 2012 and a blog from 2011 are cited - I would prefer different sources to support the thesis that using fstrim would involve risks.
In my view the “risk” that by calls to fstrim data is leaked, is a rather theoretical one.
Reason: in order that fstrim can be used at all, the file system on the encrypted partition has to be decrypted or made accessible first - otherwise fstrim wouldn’t at all be able to do its job, e.g.
http://man7.org/linux/man-pages/man8/fstrim.8.html
In other words: TRIM needs the information of the file system (e.g. ext4) which is encrypted along with the data if the partition is encrypted.
But when the encryped partition is decrypted after the password had been entered by the user (which the user needs to enter to access the data), then any malware doesn’t need to bother with fstrim anymore (!), because then that malware has direct access to all of the data on the encrypted partition without having to care about any encryption methods or passwords!
If, on the other hand, the drive with the encrypted partition would be stolen, then as well the encrypted partition would first have to be mounted to make fstrim (or TRIM) work. But in order to mount it, it has to be decrypted beforehand.
Without the password (or decryption) the thief can not run fstrim (or TRIM) for the encrypted partition, and the thief thus can not see what fstrim would do.
So the only information that the thief could perhaps easily obtain would be a list of the sectors in use and the free sectors on the SSD.
In comparison to an encrypted partition on a hard disk drive (HDD, no fstrim / TRIM) the only advantage that I can see for the thief of a SSD for which fstrim had been used before it was stolen, is that he/she may get a list with the used and free sectors and that the amount of data that he/she has to deal with is reduced by the information which sectors are free.
Thank’s, been here for 10+ yrs, new account
This post does go into the details a bit more: Milan Broz's blog: TRIM & dm-crypt ... problems?
There is a reason why TRIM is disabled on encrypted drives by default AFAIK. With that being said leaking data via free space can A) be a problem for you or B) its fine so just TRIM. Guess it very much depends on the individual view on security and what are they trying to avoid. IMHO TRIM is not bringing much value to the table at this point and prefer to keep my stuff secure. Yea even wearing, but with current SSDs that doesn’t feel like such a massive problem anymore. Not like I need to worry about the NSA or something, just the thought that my data is secure… for me its calming.
Thank’s, been here for 10+ yrs, new account ;)[/QUOTE]
That is your preference.
This post does go into the details a bit more: http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html[/QUOTE]
I already commented on that, but you may not have recognized that:
On the page that you linked here, with respect to TRIM and encryption, two quite old and short postings from 2011 and 2012 and a blog from 2011 are cited - I would prefer different sources to support the thesis that using fstrim would involve risks.[/QUOTE]
The blog from 2011 that I mentioned is the same for which you placed the link
in your last posting.
That blog from 2011 is by a “Milan Broz”.
Then on that ArchLinux page with respect to Discard/TRIM you have a reference to
https://www.saout.de/pipermail/dm-crypt/2011-September/002019.html
which is a posting from 2011 by “Milan Broz”.
The third and last link on that ArchLinux page with respect to Discard/TRIM is to
https://www.saout.de/pipermail/dm-crypt/2012-April/002420.html
which is a posting from 2012.
I have read through all that - there is no proof of concept or even empirical evidence shown in that, and the mechanisms in which way exactly TRIM could be used to leak data of an encrypted partition aren’t discussed, so …
I’ll give you a counterexample at the end of this posting.
Still the question remains: which reason?
“AFAIK” is no reason.
It does not “feel” to be so?
The problem is, the basic situation with SSDs didn’t change and can not change, because an SSD just can not “know” which parts of the storage aren’t allocated and can be re-used, and which parts of the storage contain data which should not be deleted.
There is no miracle garbage collection.
And that can not change, because it is inherent in the feature that an SSD to the outside should behave just the same way as a hard disk with magnetic disks behaves.
That is and will stay the reason for wear leveling on SSDs,
https://en.wikipedia.org/wiki/Wear_leveling
So if you like to shorten the lifetime of your SSD then just disable or not enable TRIM.
Is it?
You think that your data is more secure when you don’t enable TRIM?
From the blog of 2011 (with the term “ciphertext” used there replaced by “encrypted” for the sake of comprehensibility):
Important is that encrypted data cannot be distinguished from random data without key knowledge. If the encrypted device is wiped off using random data (or sectors are at least once written though encryption layer) it is not possible to say which sectors contain data and which are unused.
Encrypted device without using TRIM would be just black box (all sectors have random data characteristic, disk was wiped before use).
and the last sentence of that blog referring to the same idea
But if some forensic analysis tool tries to find something here… Good luck.
That obviously is the core point put forward in that blog from 2011 - the idea of a “black box”, which would be “destroyed” when using TRIM.
Here’s a simple counterexample:
Assume you have encrypted a partition by the simple method of bitwise XOR using the password “MPWD” (which is only 4*8=32 bits long).
Further assume that the partition is filled up with valid data to 50 percent of it.
The unused portion of the partition is filled up with random data.
How long do you think that this setup would resist an attempt to crack/decrypt it?
Minutes?
Seconds?
Milliseconds?
But, where is the “black box” then??
This “black box” has big big holes in it - it isn’t one.
That “black box” is only human imagination.
The reason for that is the weak encryption.
So at the end of the day it all boils down to that the security of your data will critically and in the first line depend on the quality of the encryption algorithm and the password.
Not using TRIM may perhaps only double the effort for cracking the encryption if the encrypted partition is filled up by 50 percent.
Is that worth not using TRIM?
It’s your decision.