cibomato 8 Posted June 29, 2015 Share Posted June 29, 2015 Hi, I'm using an hdd at my cubietruck and moved the root-fs to hdd. Now I'm wondering, whether it would be better, to change the commit settings in /etc/fstab to a lower value than 600? I assume, the 600 was meant for data on a flash storage in order to reduce the writes on it!? But in order to keep "things in sync", shouldn't I better reduce it? Or delete the whole commit option? What do you mean? Thanks and best regards, Jochen Link to post Share on other sites More sharing options...
Guest Blisk Posted June 30, 2015 Share Posted June 30, 2015 For a normal HDD the defaults are fine. For a SSD it's recommended to add "noatime" and "commit=600" mount options. The "discard" is not recommended, and fstrim should be used instead. 1 Link to post Share on other sites More sharing options...
cibomato 8 Posted June 30, 2015 Author Share Posted June 30, 2015 Thank you! So I'll delete the commit=600. Link to post Share on other sites More sharing options...
tkaiser 1642 Posted June 30, 2015 Share Posted June 30, 2015 I assume, the 600 was meant for data on a flash storage in order to reduce the writes on it!? But in order to keep "things in sync", shouldn't I better reduce it? Or delete the whole commit option? Simply remove it. The commit option had bad SD cards in mind that implement only crappy/insufficient forms of wear-leveling. You won't find any SSD today that is affected by that (and the references to commit=600 are copy&paste from aging SSD experiences linux users had 5 or more years ago). Same applies to "noatime" (no real need to supply this parameter since no SSD today will wear out significantly faster if not set). But I would set it since these small writes might come along with high write amplification. BTW: recommendations to disable journaling with ext4 since 'the SSD might wear out faster' one can read still here and there -- same outdated stuff / 'urban myths' today. In my opinion there's also no need to not rely on discard as long as you have ensured that your SSD implements TRIM correctly -- see here for a recent example where this did not happen: https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ Exception: If you use a modern filesystem like btrfs then you shouldn't use discard because btrfs is more of a combined volume manager / filesystem than just the latter and does care for TRIM on it's own (also detects SSDs automagically and adjusts accesses/settings accordingly). If you really care about low wear-out on your SSD and want to stick with ext4 then to avoid high write amplification it would be necessary to adjust filesystem boundaries to the SSD's page and erase block sizes (compare with Theodore Ts'o's observations and keep in mind that this isn't that easy with some modern SSDs) Regarding SSDs an Armbian with Mainline kernel: I wouldn't rely on ext4 but go with btrfs instead and use the following mount options: "-o compress=lzo,noatime" EDIT: Haha, should've answered Blisk instead :-) Link to post Share on other sites More sharing options...
Guest Blisk Posted June 30, 2015 Share Posted June 30, 2015 One more thing to perhaps watch out for is making sure that the /tmp folder is mounted on a tmpfs. I've been thinking of also moving the /var/log to tmpfs, and mounting most other parts of the system read-only except when updating packages. Things like /var and /etc and /home obviously can't be mounted read-only. If you're compiling a lot on that platform it's best to do it from RAM as well. You could also move the browser cache into memory on a desktop system. Link to post Share on other sites More sharing options...
rufik 4 Posted October 8, 2018 Share Posted October 8, 2018 On 6/30/2015 at 12:18 PM, tkaiser said: In my opinion there's also no need to not rely on discard as long as you have ensured that your SSD implements TRIM correctly -- see here for a recent example where this did not happen: https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ Exception: If you use a modern filesystem like btrfs then you shouldn't use discard because btrfs is more of a combined volume manager / filesystem than just the latter and does care for TRIM on it's own (also detects SSDs automagically and adjusts accesses/settings accordingly). Regarding SSDs an Armbian with Mainline kernel: I wouldn't rely on ext4 but go with btrfs instead and use the following mount options: "-o compress=lzo,noatime" What commit interval do you advise for kernel 4.14.y using btrfs? Default (5 sec) or just armbian's default 600 sec? I've just migrated to Transcend TS32GMTS400S SSD + USB UASP adapter (ASM1351) via nand-sata-install option... Link to post Share on other sites More sharing options...
Recommended Posts