1

I'm having a problem with my web server: when it's been up for a long time, and then it goes down for some reason, it takes forever to boot.

My workaround to this was to create a cron to reboot the server from time to time (I've been insulted for this, be kind). The reboot was so fast that the server was able to respond to the requests before they timed out, so I was cool with it.

But now I've been told that what might be causing this is fsck being forced after X days, and also after Y mounts, so my fix won't help much.

So the question is what should I do with fsck? Force it to run more frequently, or disable it? Can it run at any time, or it must be during boot? An example of how to do it with tune2fs is also welcome.

1
  • You should really investigate what takes so long to boot. Arch uses systemd, and systemd has a utility called systemd-analyze. I can do systemd-analyze blame and find out what takes so long. Perhaps Ubuntu's upstart has a similar tool. Nov 19, 2012 at 18:32

2 Answers 2

4

To answer the easiest question first: Checking a filesystem "at any time" (i.e., when the system is running) is referred to as "online" checking, and in general, it isn't supported. The reason is simple: when a filesystem is mounted, the kernel is doing arbitrary things to the actual block device--which is fine, because it keeps track of what it's doing. But when you throw fsck into the mix, it too messes with the raw block device and doesn't inform the kernel about what it's doing. So they essentially step on each other's toes when making changes to the disk, and you end up with a corrupted filesystem. Even if you just "check" in read-only mode, the results fsck returns will be meaningless, again because fsck has no idea what the kernel is doing.

To change the frequency the filesystem is checked when you mount it, you will use tune2fs, as you mentioned. Suppose you'd like to fsck every 30 reboots. Do

# tune2fs -c 30 /dev/sdaX

(Substitute the block device for your filesystem.)

Or, if for some reason you'd like to disable mount-count-based checking entirely,

# tune2fs -c 0 /dev/sdaX

If you'd rather check on a calendar, you can use -i. For example, to check every week, do

# tune2fs -i 1w /dev/sdaX

You can use d for days, w for weeks, and m for months. Again, to disable calendar-based checking, give a value of 0 for the interval. Please, please, please don't disable all checking. You will, at some point, corrupt your filesystem.

In general, you can get away with slightly longer intervals if the filesystem is journaled, although it isn't a replacement. For more info, read the man pages for e2fsck and tune2fs; they're where I got most of the info for this. Hope this helps!

4
  • Thanks. But how, with all this, can I make sure that I won't have a slow boot after a crash? (I'm worried about crashes because they usually happen on visits spikes. Add a slow boot to that and I'm screwed) I guess I just need to coordinate a programmed reboot and fsck. But how? Say I program it to run weekly. And I also have a cronjob to reboot weekly. How do I make them happen at the same time? Nov 19, 2012 at 22:21
  • Also, will running fsck frequently make it faster? Or it's always the same? Nov 19, 2012 at 22:23
  • As for my first question here, I think I got it: after setting it to 1w, I can use -l to find the exact date. So I just have to make the reboot cron trigger after that date. Am I right? But they may get out of sync if tune2fs adds a week to the last time fsck was run, instead of the last time fsck became enabled to run on the next boot. Nov 19, 2012 at 22:53
  • The speed of a fsck depends upon the size of the data being checked (not the partition size; there's a difference); additionally, finding a lot of errors will slow it down a bit. If you could split up your data onto several partitions and then stagger the fscks then each one would complete faster. As for your last question, if you set the fsck interval to something like 6d, then when you rebooted every week via cron, the check would be guaranteed to run. Nov 21, 2012 at 17:57
0

Change you scheduled reboot to have one of the following included

touch /forcefsck; reboot

or

shutdown -rF now

The existence of the /forcefsck will tell the OS to scan the disks (I am pretty sure this is what the second command does anyway.

Use cron to schedule this for a period when the server has the least load and disable the other scheduled scans (date / number of mounts) once you are confident it is running correctly.

You must log in to answer this question.

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