Should I run fsck on boot for an amazon ec2 image?

Question

I have an Ubuntu micro instance running on amazon EC2.

Recently after logging in I was alerted:

*** /dev/xvda1 will be checked for errors at next reboot ***

I've rebooted a couple times using init 6, however when I log on I am still getting the same notice, so apparently fsck is not running at startup.

I read this blog post which mentions that if the /etc/fstab <pass> column is set to 0 then a disk check will be skipped during reboot. Here is my fstab file:

<file system>           <mount point><type><options><dump><pass>
LABEL=cloudimg-rootfs   /            ext4  defaults 0     0
/dev/xvdh               /vol         xfs   noatime  0     0

This is the default configuration for an ec2 image fromubuntu.

• Is it normal for <pass> to be set to 0 here?
• Why would it be set to 0?
• What is the best way to run fsck - should I change this value or only run it manually when alerted?

Solution

• Why would it be set to 0?

  I can see a few possible reasons for this.

  Because you are running on EC2, your hardware (storage and compute instance) is virtualized. It is much less likely for such a configuration to encounter failures of any sort causing filesystem corruption, and an actual physical defect in the storage (like bad blocks on magnetic storage) are nearly impossible.

  1. This means filesystem problems are much less common, so checking the filesystem doesn't have to happen as frequently. Perhaps you are expected to run fsck manually when you suspect a problem.

  2. EC2 is "intended" to have a read-only root filesystem, or at least one which restores a fixed state at instance launch. A primary benefit of EC2 is the ability to launch small instances on demand and then terminate them when demand drops, always running the same OS configuration. In that situation, checking the root fs makes no sense, because it will never change. This obviously does not apply if you use the system for 'development' or general use, but I don't perceive that to be Amazon's real intent for EC2.

  3. Running fsck on EC2 wastes bandwidth and processor power. This translates into cost, both for the user and for Amazon.

• Is it normal for <pass> to be set to 0 here?

  I believe 1 is typical for a new Linux installation, but that can be distribution-specific. Amazon's pre-built EC2 images are also pre-configured to fit EC2.

• What is the best way to run fsck - should I change this value or only run it manually when alerted?

  Both options have merit. If you're frequently rebooting, you might prefer to run it manually rather than frequently increase the volume's mount count.

As an aside, I'm not sure if the root fs is typically checked after mounting (when fstab becomes available), or before mounting. If before, a 'typical' Ubuntu installation might actually perform the fsck in initramfs, before even mounting the root fs. In that case, initramfs might be different on EC2, and may ignore any flags that suggest the filesystem should be checked.

Comments

[cwd]

Thank you for a detailed answer. Not having run fsck before could you provide any insight on the way to actually initiate it?

[mrb]

You need the device entry for your filesystem, which you can get by inspecting the output of cat /proc/mounts. Likely it is /dev/xvda1. Then just run /sbin/fsck /dev/xvda1. If there are problems, you may need to unmount it first, which would require a recovery/single-user mode boot (not sure if that's possible on EC2).

[cwd]

Would the other logical option be to change that 0 to 1 and reboot the instance? Or is there something I'm missing there?

[mrb]

Not missing anything :) I'm just not sure how EC2 handles that. Have you tried it? You can check your fs stats with dumpe2fs -h before+after — might help for confirming.

[cwd]

Ok, I will give it a try. ps: Your #2 is not true for using EBS (Amazon Elastic Block Store), which is their newer style root drive. That's the type of drive I'm having issues with (I think it's an ext3 with noatime)

[hookenz]

If you really need to, run shutdown -rF now to force a check on boot. It can be handy when it's turned off otherwise.