change commit setting when using hdd?


Recommended Posts

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
Donate and support the project!

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
Guest Blisk
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
Guest
This topic is now closed to further replies.