Home > Linux > Using noatime, And Related Gems In Linux’s fstab

Using noatime, And Related Gems In Linux’s fstab

One of the more important configuration files in Linux is the File Systems Tab: fstab. Generally located in the /etc/ directory, it’s used to define how stuff should be mounted into Linux. What that means is that if you have a decent idea what you’re doing, you can enjoy some pretty significant performance increases on any servers you happen to be running, whether they’re physical or virtual.

It sort of goes without saying that if you’re going to be running a server, you need to understand how it works.

That’s what we’re going to discuss today. We’ll start by explaining a bit about exactly how fstab works, before moving into a description of the different attributes you can define in order to modify how it loads your files. By the time we’re done, you should have a relatively sound concept of how to modify your Linux file system for performance – and for a whole lot of other stuff, too.

How Does fstab Work, Anyway?

(Information in this section is courtesy of The ArchLinux Wiki)

Function

The File Systems Tab is closely connected to systemd, in that it contains a series of instructions on how, where, and in what order file systems should be loaded when a Linux installation is booted up – for example, whether or not a particular file system should be mounted automatically or mounted manually. systemd can also be initialized through the mount command.

Layout/Format

On accessing fstab, you’ll be presented with a table – all the different file systems accessible to your current Linux installation will be arranged into rows, each of which contains the following fields:

 

  • file system: This denotes the partition or device to be mounted. For the purpose of this tutorial, we’re going to assume you aren’t going to be messing around with this.
  • dir: mountpoint to which a particular filesystem is mounted.
  • type:
  • options:
  • dump:
  • pass: btrfs system, in which case it should be set to 0.

How To Identify File Systems

Assuming you’ve assigned persistent names to all your block devices, there are a number of different ways fstab can be instructed to identify which file systems will be mounted:

Using the lsblk -f command

 

  • Kernel Name Descriptors: Prefix all values in the NAME column with /dev/
  • Labels:
  • UUIDs:Prefix values in the UUID column with UUID=

Using the blkid command

 

  • GPT Labels: Preface entries in the file system column with PARTLABEL=
  • GPT UUIDs:

If you want to see what each of the methods described above looks like in fstab, you can find a list of examples here.

At any rate, now that we’ve got a working understanding of fstab, let’s talk about a few of the things you can do with it.

What Is noatime, And How Can It Improve Performance?

(Commands in this section are via howtoforge)

By default, Linux records information about three things when working with file systems:

  • When the file was created.
  • When the file was last modified.
  • When the file was last accessed.

What this means is that, if you don’t make any changes to your file systems, every time you access the file, you’re performing a write operation – regardless of whether or not you modify anything. Understandably, that creates an unnecessary performance overhead. That’s where noatime comes in.

By adding noatime to the options section of a file system, you’ll disable atime updates for that system – meaning you’ll be able to access and read files without also performing a disk write operation.

Applying noatime is a relatively simple process in most Linux installations, one which doesn’t even require a reboot. Simply edit your fstab as normal, then use the command mount -o remount.  If you’re using an OpenVZ container, however, you’re going to need to enter a series of commands:

 

  • Set noatime for the virtual machine: vzctl set veid –noatime yes –save
  • Restart the VM: vzctl set 101 –noatime yes –save
  • Restart the container: vzctl restart 101

The process in Red Hat is similar to the above.

How Do nodiratime And relatime Factor Into All Of This?

Now that you understand what noatime is, let’s expand things even further, with the introduction of two additional – yet closely-related – attributes: nodiratime and relatime. They can be defined as follows:

 

  • relatime: Performs an atime update only if a file or directory has been modified since the last atime update.
  • nodiratime:

Both commands can be applied to a file system in the same fashion as noatime, though it’s worth noting that in certain installations – such as Ubuntu – relatime is enabled as a mount attribute by default.

Other Attributes You Should Know About

In addition to atime, nodiratime, and relatime, there are a number of other attributes that can be applied to a file system’s mount options, such as auto/noauto, dev/nodev, exec/noexec, and dirsync. If you’re so inclined, you can find a complete list – which includes an explanation of each attribute – here.

Are There Any Risks To Fiddling With All These Attributes?

Now, it sort of goes without saying that you need to exercise a bit of caution and care when applying new attributes to a file system. Although you probably won’t completely destroy your Linux installation, there are certain applications in Linux that need certain attributes in order to function properly. Using noatime as an example:

  • Some systems contain a process or program that deletes files which haven’t been accessed for a set amount of time. If you have atime updates disabled, you could end up losing a ton of work.
  • Some applications require atime updates – mailer apps such as Mutt in particular.

The best advice I can give you here is that you know your installation before you start tweaking your mount options.

In Closing: A Few Extra fstab Resources

Before we wrap things up, here’s a short list of additional resources that’ll help you learn a little bit more about fstab and the various attributes associated with it:

Image credit: Danielle Nelson

Jay Caissie

Jay Caissie

Jay Caissie is Systems Analyst at ServerMania.