by David Härdeman <firstname.lastname@example.org>
If you are running your NSLU2 on a USB flash key, there are a number of things you might want to do in order to reduce the wear and tear on the underlying flash device (as it only supports a limited number of writes).
- The ext3 filesystem per default writes metadata changes every five
seconds to disk. This can be increased by mounting the root filesystem
commit=Nparameter which tells the kernel to delay writes to every
- The kernel writes a new atime for each file that has been read which
generates one write for each read. This can be disabled by mounting the
filesystem with the
- Both of the above can be done by adding e.g.
/etc/fstab. This can also be done on an already mounted filesystem by running the command:
mount -o remount,noatime,commit=120 /
- The system will run
updatedbevery day which creates a database of all files on the system for use with the
locatecommand. This will also put some stress on the filesystem, so you might want to disable it by adding
- syslogd will in the default installation sync a lot of log files to disk
directly after logging some new information. You might want to change
/etc/syslog.confso that every filename starts with a
-(minus) which means that writes are not synced immediately (which increases the risk that some log messages are lost if your system crashes). For example, a line such as:
- In addition, syslogd likes to write
-- MARK --lines to log files every 20 minutes to show that syslog is still running. This can be disabled by changing
/etc/default/syslogdso that it reads
- If you have a swap partition or swap file on the flash device, you might want to move it to a different part of the disk every now and then to make sure that different parts of the disk gets hit by the frequent writes that it can generate. For a swap file this can be done by creating a new swap file before you remove the old one.
- If you have a swap partition or swap file stored on the flash device, you
can make sure that it is used as little as possible by setting
- The kernel also has a setting known as
laptop_mode, which makes it delay writes to disk (initially intended to allow laptop disks to spin down while not in use, hence the name). A number of files under
/proc/sys/vm/controls how this works:
/proc/sys/vm/laptop_mode: How many seconds after a read should a writeout of changed files start (this is based on the assumption that a read will cause an otherwise spun down disk to spin up again).
/proc/sys/vm/dirty_writeback_centisecs: How often the kernel should check if there is "dirty" (changed) data to write out to disk (in centiseconds).
/proc/sys/vm/dirty_expire_centisecs: How old "dirty" data should be before the kernel considers it old enough to be written to disk. It is in general a good idea to set this to the same value as
/proc/sys/vm/dirty_ratio: The maximum amount of memory (in percent) to be used to store dirty data before the process that generates the data will be forced to write it out. Setting this to a high value should not be a problem as writeouts will also occur if the system is low on memory.
/proc/sys/vm/dirty_background_ratio: The lower amount of memory (in percent) where a writeout of dirty data to disk is allowed to stop. This should be quite a bit lower than the above
dirty_ratioto allow the kernel to write out chunks of dirty data in one go.
All of the above kernel parameters can be tuned by using a custom init
script, such as this example script.
Store it to e.g.
/etc/init.d/kernel-params, make it executable with
chmod a+x /etc/init.d/kernel-params
and make sure it is executed by running
update-rc.d kernel-params defaults
Note: Most of these settings reduce the number of writes to disk by increasing memory usage. This increases the risk for out of memory situations (which can trigger the dreaded OOM killer in the kernel). This can even happen when there is free memory available (for example when the kernel needs to allocate more than one contiguous page and there are only fragmented free pages available).
As with any tweaks, you are advised to keep a close eye on the amount of free memory and adapt the tweaks (e.g. by using less aggressive caching and increasing the swappiness) depending on your workload.
This article has been contributed by David Härdeman <email@example.com>