Announcement
Collapse
No announcement yet.
Linux 5.1 Hit By A Data Loss Bug Due To Overly Aggressive FSTRIM
Collapse
X
-
Guest repliedOuch, my desktop satisfies all of those conditions. I haven't noticed any problems so far, but I did spend a few days on 5.1.3 .
- Likes 1
-
Originally posted by Chugworth View PostIt has nothing to do with the free space that the filesystem reports. Basically, when a block is no longer used, TRIM should occur on that block before data is written to it again. There are two reasons for this - the first is for better performance, and the second is to reduce wear on the SSD. If TRIM was not run on a block before new data is written to it, that actually causes more writes to occur internally in the SSD.
But as I mentioned earlier, TRIM has the same effect as zeroing out blocks of data, which causes some concerns for encrypted drives. I doubt the security concerns are that significant, but I also don't think that the performance and wear costs of not using it are that significant either (at least in my use cases).
Fortunately (for me) I don't need encryption - this machine is unlikely to go outside my home. It sounds as if encryption is the critical item in what started this whole thread.
Leave a comment:
-
Originally posted by phred14 View Post
I read a while back that you don't need to trim/discard that often, and it can actually be better/more-efficient/lower-wear to only do it periodically. The space waiting to be trimmed/discarded is unavailable to use, but as long as you're not pushing the limits on the space on the drive it shouldn't matter.
- Likes 1
Leave a comment:
-
Originally posted by phred14 View PostThe space waiting to be trimmed/discarded is unavailable to use, but as long as you're not pushing the limits on the space on the drive it shouldn't matter.
But as I mentioned earlier, TRIM has the same effect as zeroing out blocks of data, which causes some concerns for encrypted drives. I doubt the security concerns are that significant, but I also don't think that the performance and wear costs of not using it are that significant either (at least in my use cases).
Leave a comment:
-
Originally posted by zerothruster View Post
Do you have any links for why that would be a good idea ? I tend to use lower-end hardware (I'm not a gamer, building the software is enough of a game), and my preference for SSDs is SanDisk. I'm not sure how old my oldest SSD is, but I see that I've been using ',discard' in /etc/fstab for several years without any problems.
OTOH, I'm reluctant to use Crucial drives (apparently highly rated by some PC magazines in this country, but running smartctl shows a lack of data re self-tests). So maybe it is a drive-specific (or technology-specific) problem ?
When I got my first ryzen desktop in April last year, I accidentally forgot to add that. In June I was running some compile tests (re power consumption if I disabled cpufreq) and noted they were taking longer and longer. Then I ran fstrim and added it to the fstab, and things settled down. So, my view is that "automatic" fstrim (on ext4, without LVM or dm-crypt) is the way to go.
I haven't actually done this, but I have an SSD sitting on my desk waiting to be installed, and decided I wanted to wait for 5.2 in order to pick up some F2FS improvements - plus a lack of time. I'd done some research and kept my ears open.
- Likes 1
Leave a comment:
-
Originally posted by birdie View PostIs it the third data corruption bug for the past several months? The Linux kernel is so darn stable.
- Likes 2
Leave a comment:
-
-
Originally posted by M@yeulC View PostI am pretty sure it is actually better to only trim periodically, both performance- and longevity-wise, anyway (and should be the default?)
OTOH, I'm reluctant to use Crucial drives (apparently highly rated by some PC magazines in this country, but running smartctl shows a lack of data re self-tests). So maybe it is a drive-specific (or technology-specific) problem ?
When I got my first ryzen desktop in April last year, I accidentally forgot to add that. In June I was running some compile tests (re power consumption if I disabled cpufreq) and noted they were taking longer and longer. Then I ran fstrim and added it to the fstab, and things settled down. So, my view is that "automatic" fstrim (on ext4, without LVM or dm-crypt) is the way to go.
Leave a comment:
-
Is it the third data corruption bug for the past several months? The Linux kernel is so darn stable.
- Likes 1
Leave a comment:
-
I am pretty sure it is actually better to only trim periodically, both performance- and longevity-wise, anyway (and should be the default?)
- Likes 3
Leave a comment:
Leave a comment: