| gnarface | it would be possible to swap on software raid, right? | 03:58 |
|---|---|---|
| rwp | gnarface, Yes. Swap on software raid, aka mdadm raid, is fully standard. | 04:09 |
| hacksenwerk | ted-ious: You messaged me. | 13:00 |
| hacksenwerk | Memo 1 - Sent by ted-ious, Mar 19 22:34:11 2025: Do you make sure to trim your ssd often? | 13:01 |
| hacksenwerk | Memo 2 - Sent by ted-ious, Mar 19 22:34:15 2025: That is important to keep it from wearing out faster than normal. | 13:01 |
| hacksenwerk | ted-ious: I hope that is just a bit of Ignorance on your side. | 13:02 |
| hacksenwerk | 1. Using TRIM often will reduce the lifetime of your flash drive. | 13:03 |
| hacksenwerk | You could at best use it, when the garbage collection gets so full that you can not write on the device anymore, by starting a live system and the run TRIM __once__ on that flash drive. | 13:04 |
| hacksenwerk | 2. There are many flash devices that do not support TRIM or do not properly handle queued TRIM commands. | 13:05 |
| hacksenwerk | There's a ata driver blacklist for linux: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c | 13:05 |
| hacksenwerk | My device for example (Samsung 860 EVO) can not handle TRIM properly, so it is higly recommended to __not__ use TRIM at all! | 13:06 |
| hacksenwerk | It can couse data coruption. | 13:06 |
| hacksenwerk | *cause | 13:06 |
| hacksenwerk | Do __not__ reccomend such thigs to people, when you don't understand the topic please. | 13:08 |
| hacksenwerk | Doing things on storage devices could lead to data loss, that's nothing you want to be responsible for I guess. | 13:09 |
| hacksenwerk | ted-ious: In addition: TRIM does not reducing wear leveling. | 13:10 |
| hacksenwerk | It just marks no longer needed cell space as free, that is all it does and it is the only benefit of TRIM. | 13:11 |
| hacksenwerk | Also: never run such tasks or similiar tasks, like some hdparm commands on devices that natively support them, but are not connected via their native interface and instead connected via an adapter. | 13:13 |
| hacksenwerk | There are several bug reports where people beak things becuase there were running TRIM on a SATA device connected via SATA-to-USB-Adapater, or on a SD card, connect to the computer via an external card reader (internal SD card readers often work with TRIM when the SD card also supports it, but not always). | 13:14 |
| hacksenwerk | *There are several bug reports where people break things because they were running TRIM on a SATA device connected via SATA-to-USB-Adapater, or on a SD card, connect to the computer via an external card reader (internal SD card readers often work with TRIM when the SD card also supports it, but not always). | 13:15 |
| hacksenwerk | (sorry) | 13:15 |
| hacksenwerk | ted-ious: https://wiki.debian.org/SSDOptimization#WARNING | 13:22 |
| hacksenwerk | To check if your SSD is supporting TRIM run: hdparm -I /dev/sd? | grep -e TRIM -e Model | 13:22 |
| hacksenwerk | But that does __not__ mean, that the SSD handles the TRIM properly! | 13:23 |
| hacksenwerk | Always check the ata blacklist from kernel.org first and when you couldn't find your device start also a websearch. | 13:23 |
| metala | >> 1. Using TRIM often will reduce the lifetime of your flash drive. << The remapping part should be on SLC . I doubt you would be able to waste so many cycles to decrease the lifetime of the flash memory / SSD. | 13:24 |
| hacksenwerk | For bug reports, forum posts or similiar things. | 13:24 |
| metala | Not to mention, that freeing the cells, should improve the wear-levelling, not just the write speed. | 13:25 |
| hacksenwerk | And only when you find no issues for TRIM and your flash device, you can run TRIM on it (but finding nothing issue related also doesn't mean that your device could handle TRIM correctly, keep that in mind). | 13:26 |
| hacksenwerk | And keep also in mind that TRIM erases the blocks. So when something goes wrong with it your data will be lost and you can __not__ recover it, even not with forensic methods. | 13:36 |
| hacksenwerk | https://security.stackexchange.com/questions/244154/data-recovery-from-trimmed-ssds | 13:36 |
| ted-ious | hacksenwerk: I am very familiar with the trim feature thanks. :) | 17:39 |
| ted-ious | I was just asking because some people aren't aware at all so they never use it. | 17:40 |
| ted-ious | That ends up being just as bad as using it too much. | 17:40 |
| ted-ious | I recommend using it daily or whenever you finish some intensive job like a big upgrade or building alot of software. | 17:42 |
| ted-ious | I think the biggest danger is enabling auto trim not running it manually too much. | 17:44 |
| hacksenwerk | ted-ious: Since Debian 11 trim is set via a cron job by systemd once a week. That's already to much. And you say: "17:42 < ted-ious> I recommend using it daily..." ?! | 17:46 |
| hacksenwerk | It isn't necessary at all, only when your flash drive get to the read-only state (not the one that means eol). | 17:47 |
| hacksenwerk | TRIM wearl level down your flash, everytime you run it. | 17:48 |
| ted-ious | I have been running different trim schedules on different media for a few years now and the only ones that have failed have been the ones where I don't trim at all. | 17:52 |
| ted-ious | But if you don't want to trim at all that's fine too and I would like to receive your data. :) | 17:53 |
| hacksenwerk | ted-ious: Why should they fail and with what did they fail? | 17:53 |
| hacksenwerk | ted-ious: Read the stuff I posted and linked, There are several drives where you should avoid trimming at all. | 17:54 |
| ted-ious | Flash devices that have very little slack space left for doing relocations have to work harder and harder to load level their writes. | 17:54 |
| hacksenwerk | Is any of your drives on the ata blacklist? | 17:54 |
| ted-ious | So they end up write amplifying even if you are only writing large aligned blocks. | 17:55 |
| hacksenwerk | "very little slack space left" But that's what I said! | 17:55 |
| ted-ious | No I don't have any of those drives. | 17:55 |
| hacksenwerk | ted-ious: Good for you. | 17:55 |
| hacksenwerk | I do. | 17:55 |
| hacksenwerk | And I don't want to end up having dataloss without even knowing it... | 17:56 |
| hacksenwerk | When any of my drives should ever end up being full and slow, I would make a complet backup, or better clone it, run secure erase and copy the stuff back. | 17:57 |
| hacksenwerk | I wouldn't even run TRIM on the first drive and then copy teh stuff back, because also the fs, the lvm, and luks are stored there and can get corrupted. | 17:58 |
| ted-ious | Ok well I only wanted to let you know about trim if you didn't already and since you obviously do then my work here is done. :) | 17:58 |
| hacksenwerk | And "my work here" was to tell you not to tell people the should run TRIM often on their flash drives. Some could believe that this is would be a good idea and it isn't. | 17:59 |
| hacksenwerk | *they | 17:59 |
| hacksenwerk | ted-ious: Did you know the sources I linked to you before? | 18:00 |
| hacksenwerk | Or the information in them? | 18:00 |
| ted-ious | I think maybe we have a different definition of often and good. | 18:00 |
| hacksenwerk | ted-ious: Did you know the sources I linked to you before? | 18:01 |
| ted-ious | I think the average devuan user probably doesn't know about trim at all and might only do it after their flash device is having problems. | 18:01 |
| ted-ious | So them I would advise running fstrim daily which is much more often and a very good idea according to the data I have collected. | 18:02 |
| hacksenwerk | ted-ious: ...well I don't know any devuan user and I feel not in the position to judge if they or any other computer user is able to run task foobar... | 18:03 |
| hacksenwerk | ted-ious: no | 18:03 |
| hacksenwerk | That's not about beliefs here! It is a fact that running TRIM without knowing if your device can handle it properly is dangerous. And it is also a fact that running it often, no matter if the device handles it properly or not, will wear level down the storage! | 18:05 |
| hacksenwerk | ted-ious: If you want to do it on your drives that's your decisiion, I don't care. But do not suggesst it to others, because it's bad. | 18:06 |
| ted-ious | I have probably read the debian page at some point in the past but the stack overflow page is about data recovery not extending flash life spans so no. | 18:06 |
| hacksenwerk | ted-ious: That was another topic, why you mix it up know? | 18:07 |
| ted-ious | I think the best references I found were some white papers from sandisk. | 18:07 |
| hacksenwerk | I did not mix it. | 18:07 |
| ted-ious | It's your link I'm just explaining what it is and why I didn't find it relevant. | 18:07 |
| hacksenwerk | I just told you that TRIMed away data is lost and you can not recover it, just to further reinforce that TRIMing falsh storage is not a trivial task and that when you lose data you wont be able to recover the data with any forensic method known. | 18:08 |
| hacksenwerk | But ok "I have probably read" is well... | 18:09 |
| ted-ious | I never said anything about data recovery and I don't think it has very much to do with trimming. | 18:09 |
| hacksenwerk | ted-ious: Yeah and that's the point where people who do undertsand what TRIM is understand that you do not understand it. | 18:09 |
| hacksenwerk | Again: that's why I said: don't suggests your TRIM behaviour to others. | 18:10 |
| ted-ious | I think we're going to have to agree to disagree on that and if you think you will extend the life span of your devices by not trimming them then I would love to get your results after a few years. | 18:11 |
| hacksenwerk | That is not about giving bad advices that could maybe break some application so it does not start anymore or stuff like that. It is about dataloss. Data that does not belong to you, but to other people who maybe trusted your advice. That's a no go! | 18:12 |
| ted-ious | I'm sorry you're getting upset about this subject but I'm glad that you already knew about trimming so I'm going to just wish you luck with your future storage use and stop talking about this now. | 18:12 |
| hacksenwerk | ted-ious: How many years would you "believe" my devices will last without trimming? Maximum. | 18:12 |
| hacksenwerk | 3 years, 4, 6... ? | 18:14 |
| davesp | Does Devuan default to not using TRIM enough or using it too often? | 20:11 |
| fsmithred | I think it's like debian and doesn't use trim by default. | 20:27 |
| davesp | Hmm. On Devuan daedalus, it looks like running "fstrim" depends on one or more settings in "/etc/e2scrub.conf", which seem to default to "off". | 22:28 |
| rrq | "looks like" ? | 22:41 |
| rrq | don't you mean that e2scrub runs fstrim if it's set up to do that? | 22:44 |
| davesp | No; in that file, it means I haven't set "periodic_e2scrub=1" or "fstrim=1" to see if fstrim runs. | 22:58 |
| rrq | aha, you meant that e2scrub doesn't run fstrim if it's not set up to do that. | 23:02 |
| davesp | Also no; I haven't tested it, nor will I. My initial comment about TRIM was meant to be a polite suggestion that the "flood" of TRIM discussion might be better suited to #offtopic. | 23:05 |
| rrq | right. so I misunderstood you completely :) | 23:06 |
| davesp | Or I made myself understood incompletely. :-) | 23:06 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!