85

With previous versions of Ubuntu (using Ext3 filesystem) I used to tune it for better performance with noticeable results by setting the noatime parameter in /etc/fstab.

Is it still worth it to do that with the Ext4 filesystem, which is now default in Ubuntu? If so, does the procedure changed in some way?

An example of this tuning can be found here.

2 Answers 2

73

On Ubuntu 10.04, relatime is part of the default mount options, unless overridden in /etc/fstab. The previous few releases had relatime explicitly in /etc/fstab. relatime gives the same speed (and flash write cycle conservation) benefits as noatime, without causing trouble to old-fashioned mail notifiers.

The article you cite recommends data=writeback. Ubuntu defaults to data=ordered. Ubuntu's setting is slower in case of heavy disk load, but carries significantly less risk of data loss in case of a crash or power failure. So I would not recommend changing from the Ubuntu default.

Changing commit=5 to commit=100 increases the time window during which data will be lost in case of a crash, for little benefit in most circumstances.

Summary: leave the settings as they are, they were chosen for a reason.


ADDED: There are other things beyond mount options than can make a difference. Switching from ext3 to ext4 is itself often a visible improvement. Here are a few more tips for laptop users.

  • If you have a slow SSD, check out this thread at SU. The important tips are to use tmpfs for /tmp and for the browser cache (and perhaps history).

  • If you have a hard disk and you want it to stop spinning for extended lengths of time, then install noflushd, which allows the disk to spin down by delaying all writes until the RAM is full. (Of course, reads can cause the disk to spin up; you'll want to get into the habit of running cat /files/I/m/likely/to/need >/dev/null before the disk spins down.) In order for noflushd to be effective, turn off all swap and mount your filesystems with something like commit=3600.

    Using noflushd effectively means that your data can remain unwritten to disk for an extended length of time. This is a risk, to be weighed against the benefit of not having any noise or heat coming from the disk for a while. Don't use noflushd if you're not comfortable with that risk.

4
  • I understand the danger of tweaking like this, some of the step on that tutorial I don't agree with, like the comit=100 as you mentioned too. But I'm willing to take some moderated risks to increase performance, since I use a laptop and (almost) regularly backups.
    – Decio Lira
    Aug 13, 2010 at 12:58
  • 2
    @Decio: noatime vs atime can make a visible difference, but I'd be surprised that noatime vs relatime would. I've added a few laptop-specific tips to my answer; I've personally observed visible improvements from these tips. Noflushd carries a risk that I was willing to take when I used it. Aug 13, 2010 at 13:32
  • Yeah, I was just googling about the differences between noatime and relatime, and you are right. relatime (which is now default in ubuntu) is a good compromise between atime and noatime.
    – Decio Lira
    Aug 13, 2010 at 14:55
  • 1
    I've read about data=writeback — it simply writes file data and metadata in random order (as opposed to ordered which always writes metadata after the data). This means upon power outage you can find your file α bytes long, where 0 bytes been actually written. Well… But this is absolutely natural! I've been always thinking that filesystem first increases file size, and then writes the data. Finding that it can be in the reverse order requires transforming this pattern to add caching in RAM. I am not convinced why not to use writeback if it can help on improving latency.
    – Hi-Angel
    Nov 3, 2017 at 7:02
25

Yes, it still may make sense to use noatime as of Ubuntu 12.10

relatime is a default mount option. And relatime is much better than atime. The former requires a write for the first read after a write, the latter requires a write for every read. But with noatime each read is free of a write.

This basically means that the number of writes to a disk for relatime mount is close to double relative to a noatime mount other thing being equal. It is a serious concern for partitions on flash memory devices.

The detailed discussion by linux kernel community is at http://kerneltrap.org/node/14148

4
  • 3
    The factor of two is not correct in general. In theory the factor is between 1 (infinitely often used file) and 2 (infinitely seldom used file). This means, that the true factor is basically 1, as the seldom factors close to 2 do not account significantly in the average. Jan 5, 2014 at 17:56
  • 1 is for write-only files. 2 is for all the others. There is no point in write-only files, but they can appear from time to time. So my original estimate should be relevant.
    – yanychar
    Jan 7, 2014 at 18:09
  • @yanychar : thanks for explaining relatime drawbacks and sharing the kerneltrap discussion, but saying "there is no point in write-only files" is nonsense: all of /usr and /lib are read-only files. Actually, most of the tree, sans /home and /var, are read-only. Files at /etc also change very seldom.
    – MestreLion
    Sep 10, 2015 at 17:59
  • 5
    @MestreLion : Ubuntu installs tons of packages. The packages are upgraded from time to time. If there were no reads of a file between the times when the package is installed and upgraded, the file was "write-only". There are no additional writes with relatime compared to noatime for the file. For all the rest, there is an additional write when the file is read.
    – yanychar
    Dec 13, 2015 at 9:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .