| gnarface | davesp, rrq: from what i've read it's filesystem specific not distro specific, and all the dire warnings about how much it matters to drive life are based on years outdated info with buggy drivers and disk firmware long since patched, it's purely a performance concern now, and most filesystems will handle it transparently as necessary iirc | 01:51 |
|---|---|---|
| ted-ious | gnarface: I can confirm that not trimming the sd card in a raspberry pi means it will die and so far trimming a different sd card in the same raspberry pi has let me use it much more over the past year and a half. | 01:54 |
| gnarface | probably a ancient buggy firmware as mentioned | 01:55 |
| ted-ious | I have had 3 die and so far 2 are running with weekly trims and working perfectly. | 01:55 |
| gnarface | what they're supposed to do is just invoke trim internally when they hit the wall, it's just that there's a big performance impact doing that... i've got SD cards in service for years now i've never trimmed | 01:55 |
| ted-ious | In one case it was a 32gb samsung sd card that died and was replaced with another one purchased in the same batch that is still working perfectly now that I started trimming regularly. | 01:56 |
| gnarface | data loss, corruption, hardware failure, all of those things are supposed to have been solved at the manufacturer's end and in the filesystem drivers | 01:56 |
| gnarface | for performance, some filesystems that don't invoke trim right though still need it | 01:56 |
| gnarface | (xfs, notably) | 01:56 |
| ted-ious | Do you mean some linux filesystems invoke trim without the user requesting it? | 01:57 |
| gnarface | well it's not like a periodic job, calling trim the binary, no, it's just properly accessing the internal mechanism, which iirc you can still disable if you want | 01:58 |
| gnarface | at least in ext4 | 01:58 |
| gnarface | some people still opt to do that for performance enchancement | 01:58 |
| gnarface | but nothing should be actually burning out or corrupting data unless it's really old hardware and really old kernels | 01:58 |
| gnarface | at least, so i've read, and as i said, i've got numerous SD cards in operation i've never bothered trimming... | 01:59 |
| ted-ious | Well I think the other person who I won't mention because I don't want to ping him was certainly correct that automatic trim is a terrible idea for most systems especially windows from what I have read. | 01:59 |
| gnarface | they write and delete gigabytes a day, so i know it would have died by now on timeframes you're talking about | 01:59 |
| ted-ious | But that's because you're trimming every single filesystem block you delete so of course that is going to cause write amplification. | 01:59 |
| ted-ious | That's very interesting. | 02:00 |
| gnarface | yes, like i said, many people still opt to disable trim and set their own schedule for a manual call to trim even if their filesystem can handle it, because it's a raw performance concern | 02:00 |
| ted-ious | Are they respberry pi's running devuan? | 02:00 |
| gnarface | one is | 02:00 |
| gnarface | i googled the information i got, it should still be possible to find this... all the dire warnings about hardware failures and filesystem corruptions related to failure to set your own trim job should now be stale info from the very early months of SSD support in linux | 02:02 |
| gnarface | if you're for example running xfs though and don't set your own trim job, you'll still see the slow creeping write-throughput reduction issue early windows users were complaining about, but it shouldn't actually lose data or burn out the hardware unless you've got very old drive firmwares and very old kernels running on them | 02:03 |
| gnarface | that raspberry pi running devuan on a SD card had been writing and then deleting about 5.2GB of raw timelapse images for something like 5 or 6 years already before i even heard the rumor you're supposed to even trim SD cards (it's actually older than devuan though and initially it was running raspbian) | 02:06 |
| ted-ious | Wow that's great to know. | 02:06 |
| gnarface | sometimes i try to trim the microsd in my pinephone to see if it'll make waydroid boot faster but it seems to actually make it slower so i'm not even sure it's always a good idea for performance improvement these days either | 02:07 |
| ted-ious | How big is the sd card in your raspberry pi and how full is it? | 02:08 |
| gnarface | well it's 32GB, i write and delete about 5GB to it daily, then re-upload a ~115-145MB compressed synopsis of that every evening or so, and i think about every 6 months it fills up then i re-compress a longer-term timelapse from those, upload that to an external backup server and delete the whole lot and start over | 02:10 |
| gnarface | like i said, been doing this with the same SD card since the raspbian that before devuan jessie | 02:11 |
| gnarface | *that came before | 02:11 |
| gnarface | raspbian wheezy? | 02:11 |
| gnarface | it might matter that i'm using resierfs on it; ext3/ext4 have been known to be very hard on flash media and if you've burned out multiple SD cards in the same amount of time i'd blame ext* on it in general rather than the trim jobs specifically | 02:12 |
| gnarface | you might want to turn up the discard interval a bit to | 02:12 |
| gnarface | to reduce journaling related wear | 02:12 |
| gnarface | (or just switch to xfs) | 02:13 |
| ted-ious | Oh so xfs is actually good about automatically trimming? | 02:15 |
| ted-ious | I thought you said that it didn't do it properly. | 02:16 |
| gnarface | no no, i'm saying the exact opposite; ext3/ext4 are "good about automatically trimming" and i'm suggesting you might want to actually turn it off or increase the "discard" interval to slow it down - xfs doesn't support trim at all and if you care to use it you'll have to set a cron job | 02:17 |
| gnarface | (discard is a mount option) | 02:17 |
| gnarface | but xfs, like reiserfs, just seems to be more gentle on SD cards than ext3/ext4 | 02:18 |
| gnarface | i have burned out at least 1 flash key by using ext4 on it, and after far less wear too | 02:18 |
| gnarface | i'm wary of it in general, i've also had several issues of unrelated data corruption just due to bugs in the e2fsprogs | 02:19 |
| ted-ious | Oh ok sorry I was forgetting that discard meant automatic and didn't realize you were talking about doing it manually. | 02:20 |
| gnarface | sorry i'm kinda jumping back and forth between both parts of the topic | 02:22 |
| ted-ious | So when you say xfs doesn't support trim at all do you mean fstrim too or just discard? | 02:24 |
| gnarface | lemme try to clarify | 02:24 |
| gnarface | xfs doesn't support trim so you might want to run fstrim manually if you're using it, but on modern hardware you shouldn't have to strictly speaking | 02:25 |
| ted-ious | Ok. :) | 02:25 |
| gnarface | ext4 does support trim, but you might want to mount ext4 drives with options like: defaults,discard,commit=100 for example, to slow it down a bit | 02:25 |
| ted-ious | And relatime. | 02:26 |
| gnarface | (just because ext4 seems a bit rough on flash media in my experience) | 02:26 |
| gnarface | relatime should be the default now, that's also old news | 02:26 |
| gnarface | more stale than the trim info, in fact | 02:26 |
| gnarface | the SSD i have ext4 on that i mount with "defaults,discard,commit=100" options doesn't have much write traffic, it's just a media streaming box, so write throughput to disk is not as important, but i turn up the journal commit interval a bit anyway just to try to reduce wear, there's some risk of data loss in theory if there were a sudden power loss but it's on a UPS and it's not storing anything of value anyway | 02:29 |
| gnarface | (turning the commit interval up much higher than 100 seemed to destabilize the system but ymmv) | 02:31 |
| gnarface | but all drives are supposed to handle triggering trim themselves when necessary now, it's supposed to be purely a performance concern, except in the case of some buggy firmware shipped with very early products that started all these rumors | 02:32 |
| gnarface | so i've read, anyway | 02:33 |
| fluffywolf | my impression is that trim is obsolete on any modern real ssd, as they all do wear leveling that moves data from infrequently-written blocks. | 02:34 |
| gnarface | yea i haven't benchmarked it myself really, but i'm lead to believe that sometimes you might want to take it into your own hands just to have more predictable performance metrics | 02:35 |
| ted-ious | How do they know that a block was actually deleted? | 02:35 |
| gnarface | i don't know, but i expect with most products in the wild you'd need some sort of proprietary toolkit from the manufacturer | 02:36 |
| fluffywolf | why do they care, is the real question. | 02:37 |
| gnarface | (the type of thing they don't give out without a NDA) | 02:37 |
| ted-ious | fluffywolf: Because if the flash controller doesn't know which blocks aren't being used anymore it can't do wear leveling. | 02:39 |
| fluffywolf | but it can. it can move blocks around that are in use. the only possible benefit for trim is write speed improvements on sustained writes at full speed. | 02:41 |
| fluffywolf | the controller will keep track of how many writes each block has, and swap frequently used ones with infrequently used ones to keep wear level, even if both are in use. | 02:42 |
| gnarface | hmm, google's AI response still says it's about drive longevity - the obvious issue of feeding the AI with years of unfiltered bullshit | 02:45 |
| gnarface | but i'm pretty sure the updated contradictory information was written by a kernel dev... | 02:45 |
| fluffywolf | with old ssds with crappy controllers it was definitely true... but controller brains have increased with time. | 02:45 |
| fluffywolf | that said, I'm not an expert - it's just what I've heard. modern controllers are smart enough that it doesn't matter, except for large sustained writes where having the pages already blanked saves an erase. | 02:47 |
| fluffywolf | filesystems that are smart enough to understand ssd layout and minimize fragmentation make a difference, but I don't remember which one claims that. lol | 02:48 |
| gnarface | yea, one would expect to still hit a performance wall at the point the drive has to trigger its internal trim mechanism, so for performance many people opt to schedule a preemptive trim | 02:48 |
| gnarface | fluffywolf: an inherent side-effect of journaling itself in any journaling filesystem is supposed to be that it obviates the concept of fragmentation | 02:49 |
| gnarface | they should pretty much all be able to do that now | 02:51 |
| gnarface | ok, dunked my head in water and now with more of my wits intact i have a couple corrections/amendments to the above information: | 04:14 |
| gnarface | 1) the "commit" interval mount option apparently has nothing to do with trim (though i stand by my advice to consider increasing it above the default to potentially extend the life of SSDs with low disk traffic) | 04:15 |
| gnarface | 2) trim in ext4 (which it unhelpfully calls "discard" in the mount options) may actually not be on by default; i thought it was but both the man page and my old notes say otherwise - but both those may be stale so if you care you'd better check to be sure | 04:16 |
| gnarface | well, the man page doesn't really say one way or another it just kinda seems to imply it's off | 04:17 |
| gnarface | i generally try to avoid ext4 these days though so someone who has more current installs of it might have a better perspective | 04:18 |
| Guest88 | how can I turn off services and prevent them from starting up at startup? | 21:11 |
| rwp | The easiest and probably best thing is to uninstall anything that you don't want running. | 21:13 |
| rwp | If you don't want to uninstall it then the second best thing is to install sysv-rc-conf and then use it to manage the symlinks. | 21:13 |
| rwp | Third best is to manage the init symlinks manually yourself. Which is easy enough. | 21:13 |
| Guest88 | you mean removing the symlinks? | 21:14 |
| Guest88 | sorry I got disconnected? | 21:17 |
| Guest88 | did you reply to my question of whether or not I should delete the symlinks manually? | 21:18 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!