# Why force fsck on boot? Why not on shutdown?

## parsim

Once every few weeks, I get a message like:

```
/dev/hda3 has been mounted 23 times without being checked, check forced.
```

It then takes 3 or 4 minutes to do a fsck before continuing with the boot.

I understand the disk needs a periodic fsck. But what's the logic behind performing this on powerup and not powerdown? When I turn off my computer, it's because I'm finished with it. But when I turn it on, it's because I want to do something, preferably right away, and a longer boot (especially a longer than expected boot) slows me down.Last edited by parsim on Tue Dec 07, 2004 10:20 pm; edited 1 time in total

----------

## codergeek42

Fwiw it's worth you can disable that (at least I know you can with ext2/3 systems, not sure how with other FSes). If you're using an ex2/3 FS, tune2fs will help you with this:

```
# man tune2fs
```

Something like 

```
# tune2fs -i 0 /dev/hda3
```

should do it I think... (note that in order to use these, the partition must be unmounted, which means most likely booting from a LiveCD or into single-user mode)

----------

## parsim

Thanks -- I did notice that, but the man page for the -i option in tune2fs says:

```
              It  is  strongly  recommended that either -c (mount-count-depen-

              dent) or -i (time-dependent) checking be enabled to force  peri-

              odic  full  e2fsck(8 ) checking of the filesystem.  Failure to do

              so may lead to filesystem corruption due to bad  disks,  cables,

              memory,  or  kernel  bugs  to go unnoticed until they cause data

              loss or corruption.
```

So okay, I'm happy to tolerate the occasional forced fsck. I just don't get why this task is scheduled during powerup and not powerdown. Am I missing something or is this nuts?

----------

## rhill

considering fsck is generally used to fix problems caused by improper shutdowns (ie. powering down before the disk has a chance to save any write-cached data and unmount) doing it at startup makes the most sense.  it's not the only purpose it has of course, but it's the most common.  if fsck was only run at shutdown, and you had, say, a power outage, you could be mounting a corrupted filesystem on your next boot.  that would be a Bad Thing(c).

the scheduled fscks probably wouldn't be to bad to skip.  they're not critical, just kind of a periodic check to make sure stuff is in order.  if fsck has a reason to suspect something is wrong with the disk, it'll run regardless of schedule.  so i don't think it would be a huge issue if you did a 'tune2fs -i 0 /dev/hda3' and then just added fsck to '/etc/conf.d/local.stop'.  make sure you have 'local' set in your init by doing an 'rc-update show' if you decide to do this.  it'll run everytime you shut down, but maybe checking the /etc/init.d/checkfs and checkroot scripts might have some leads on how to get around that.

you could also consider using reiser on your root partition.  even when it does need to reiserfsck, it takes like a second to do.  

--de.

----------

## apmurray

Actually I am pretty sure this is set via fstab with the last number at the end of a line for a device ie:

 *Quote:*   

> The sixth field, (fs_passno), is used by the fsck( program to  deter-
> 
>        mine the order in which filesystem checks are done at reboot time.  The
> 
>        root filesystem should be specified with a fs_passno of  1,  and  other
> ...

 

----------

## parsim

Thanks, that makes sense... clearly fsck needs to happen on powerup following a shutdown failure. Thanks also for the suggestion on a workaround. 

Perhaps if people will be using ReiserFS in the future, this won't be such an issue. And if you're running an always-on server, I guess it doesn't matter one way or the other. But for home users, having your desktop be completely unavailable for several minutes, as it is during an fsck, at the very point you sit down to start work, seems bizarre. It's incredibly user-unfriendly and I wonder if there's a good reason for it.

----------

## codergeek42

 *parsim wrote:*   

> Perhaps if people will be using ReiserFS in the future, this won't be such an issue.

 

n00b warning: why not? I thought ReiserFS used a metadata journal similar to how ext3 does it...

----------

## parsim

Oh, I read this as suggesting fsck was faster with ResierFS. Maybe I misinterpreted.

 *dirtyepic wrote:*   

> you could also consider using reiser on your root partition. even when it does need to reiserfsck, it takes like a second to do. 

 

----------

## codergeek42

 *parsim wrote:*   

> Oh, I read this as suggesting fsck was faster with ResierFS. Maybe I misinterpreted.
> 
>  *dirtyepic wrote:*   you could also consider using reiser on your root partition. even when it does need to reiserfsck, it takes like a second to do.  

 Ah. I misunderstood I think.   :Embarassed: 

Thanks.

----------

## parsim

I hit the magic 23rd boot again today, which reminded me to keep on with this issue.

I think this is crazy: last night when I shut down, my computer was off in about 10 seconds. This morning, when I sit down to work, it took 7 minutes to boot. I just don't think it's acceptable for a desktop OS to regularly take that long to boot.

dirtyepic posted above a possible way to get scheduled fsck checks to happen on (every) powerdown rather than boot, but what I really want to know is why this isn't the default behavior. Why are we making the majority of Linux users sit through fsck checks on every Xth boot, when they need their computer, and not on every Xth shutdown, when they don't? Is there a dev I could write to?

----------

## jbpros

This has been said: fsck'ing at boot permits bad shutdowns recovery.

You may want to try setting interval-based checks instead of both interval and mounts count:

tune2fs -c 0 -i 14d /dev/hda1

Will make the system check the partition hda1 every 14 days, no matter the mounts count. This is a good idea on a desktop system.

----------

## parsim

Thanks, but I do appreciate that. My issue is that given:

   (a) scheduled fscks have nothing to do with crash-recovery fscks

   (b) scheduled fscks are a good idea

why:

   (c) scheduled fscks occur during boot and not shutdown

 :Question: 

----------

## Archangel1

How about (d): If fsck is annoying you, why are you still using ext2?

Isn't this one of the biggest reasons to go with a journaled filesystem?

But if you want an answer to (c), it's pretty simple once you engage your brain muscle: fsck is run to check the filesystem for corruption. If the filesystem is corrupted, the system may not boot or may boot improperly.

Now if your fs corrupts, and it locks up halfway through boot, you're not gonna be too happy about fsck running at shutdown are you?

----------

## parsim

 *Archangel1 wrote:*   

> How about (d): If fsck is annoying you, why are you still using ext2?

 

I'm not; I'm using ext3. And I'm using it because it's recommended by the Gentoo install doc. I thought most people used it.

 *Quote:*   

> But if you want an answer to (c), it's pretty simple once you engage your brain muscle: fsck is run to check the filesystem for corruption. If the filesystem is corrupted, the system may not boot or may boot improperly.

 

Sorry, I feel like I'm going in circles here. I thought the above posts had already established that the scheduled fscks ("It's the 23rd boot since our last fsck, time for another one!") have nothing to do with the crash recovery fscks ("We didn't shutdown properly, better fsck"). I completely understand why the latter should occur during boot. I don't understand why the former do.

----------

## jbpros

 *parsim wrote:*   

>  *Archangel1 wrote:*   How about (d): If fsck is annoying you, why are you still using ext2? 
> 
> I'm not; I'm using ext3. And I'm using it because it's recommended by the Gentoo install doc. I thought most people used it.
> 
> 

 

You are using ext2 with journalling, it's called ext3. Most people use it.

 *Quote:*   

>  *Quote:*   But if you want an answer to (c), it's pretty simple once you engage your brain muscle: fsck is run to check the filesystem for corruption. If the filesystem is corrupted, the system may not boot or may boot improperly. 
> 
> Sorry, I feel like I'm going in circles here. I thought the above posts had already established that the scheduled fscks ("It's the 23rd boot since our last fsck, time for another one!") have nothing to do with the crash recovery fscks ("We didn't shutdown properly, better fsck"). I completely understand why the latter should occur during boot. I don't understand why the former do.

 

The scheduled fscks HAVE something to do with recovery. In case of errors on the partition that are not caused by an unclean shutdown, it will correct your filesystem someday. this is important. The longuest is the check interval the more you risk malicious corruption (in opposition to corruption generated by unclean shutdowns). The fact this check is performed at boot is explained by what Archangel1 told you. Those checks are simply "last-chance checks". If they were run at shutdown time you would NEVER have any boot sequence where you could affirm your partitions are 100% clean because corruption could occur while your computer is off (during transport, higi/low ambient temperatures, etc.). There could even be a failing hard disk working when powered on but losing data when it's off.

----------

## feld

If you fsck on shutdown, won't this prevent an improper shutdown? So then you'd only need to fsck on boot if somehow u powered off instead of shutting down?

I think this is the goal that the author is trying to reach, and i think it makes perfect sense.

-Feld

----------

## vonhelmet

Not acceptable for a desktop OS to take that long to boot? Plenty of people put up with worse from Windows 98 when it decides it needs to scandisk every single boot.

As has been mentioned, fsck is normally used to recover from an unclean shutdown i.e. a power failure, so you can't always guarantee that it will run when a PC is shut down. It makes more sense to do it at boot in this case, because this is the time when it is most likely to need it.

If you don't like it, then disable the automatic fsck-ing, I think you can do it with the numbers at the end of the lines in fstab. If you want to get it to fsck on shutdown then create an init script that does nothing when it starts and fsck's when it stops.

----------

## parsim

 *jbpros wrote:*   

> The scheduled fscks HAVE something to do with recovery. In case of errors on the partition that are not caused by an unclean shutdown, it will correct your filesystem someday. this is important. The longuest is the check interval the more you risk malicious corruption (in opposition to corruption generated by unclean shutdowns). The fact this check is performed at boot is explained by what Archangel1 told you. Those checks are simply "last-chance checks". If they were run at shutdown time you would NEVER have any boot sequence where you could affirm your partitions are 100% clean because corruption could occur while your computer is off (during transport, higi/low ambient temperatures, etc.). There could even be a failing hard disk working when powered on but losing data when it's off.

 

This doesn't make sense to me. My system schedules fsck for every 23rd mount. What are the chances that (a) I will experience filesystem damage while the system is powered off, (b) it will be of the type that fsck can correct, and (c) that will just so happen to be the 23rd boot when my scheduled fsck runs?

Well, actually I can tell you the chance of (c): it's 4%. So even if I am unlucky enough to experience filesystem corruption during power off, I have a 96% chance that my scheduled fsck won't run, and I'll need to boot from a CD anyway.

You say that data corruption can occur in a variety of ways during power off and it's important to know you have a 100% clean filesystem on boot, but I can't square this with the fact that scheduled fscks only happen occasionally. If it's such an issue, why isn't fsck forced every single boot? If it's not such a big issue, why can't they happen during shutdown?

 *vonhelmet wrote:*   

> Not acceptable for a desktop OS to take that long to boot? Plenty of people put up with worse from Windows 98 when it decides it needs to scandisk every single boot. 

 

I don't think many people consider Win98 to be an acceptable OS these days, though. And I certainly don't want to defend Linux with, "Well, Windows 98 was just as bad."

 *Quote:*   

> As has been mentioned, fsck is normally used to recover from an unclean shutdown i.e. a power failure

 

Sure, and as I have already mentioned, I'm not talking about fscks after system crashes; I completely agree they should happen on boot. I'm talking about fscks that are scheduled for every Xth boot, regardless of whether the system was properly shut down or not. These are "strongly recommended" by the tune2fs man page, because:

 *tune2fs man page wrote:*   

> Failure to do so may lead to filesystem corruption due to bad  disks,  cables, memory,  or  kernel  bugs  to go unnoticed until they cause data loss or corruption.

 

Please, I want to be clear: this is not about recovering from a power failure or system crash.

 *vonhelmet wrote:*   

> If you don't like it,

 

Thanks, and others in this thread also pointed out that I can disable scheduled fscks. But it's not that I don't want them at all; I do, for the reasons given by the tune2fs man page. I simply don't want to have to sit through them during boot if I don't have to.

----------

## chunderbunny

I think the reason that fsck runs at boot and not at shutdown is that people expect it to behave like that. If fsck ran at shutdown people might wonder why their computer was taking so long to power down and just hit the power button. 

Similarly if a scheduled fsck does find a problem then you want the user to be around so that they can read and respond to any error messages that might pop up. If fsck had run on shutdown then the user is likely to have left by the time fsck completes (and when they come back they'll probably just see a blank screen and hit the reset switch.)

----------

## parsim

 *chunderbunny wrote:*   

> if a scheduled fsck does find a problem then you want the user to be around so that they can read and respond to any error messages

 

Ah, now that's a good point.  :Smile: 

Although I'm still not totally convinced that's worth making people sit through fscks for.  :Wink: 

----------

## Jengu

Solution: Switch to ReiserFS.

Rock solid stable for me and I don't have this problem (gentoo-dev-sources).

----------

