Safe to stop fsck on boot?

abstracity · 2007-08-08 11:26:03

Hello. I have been mulling over the probability of being able to have a stable system that does not run fsck on journaled filesystems other than those found on the /boot and /root partitions. Would it make any of you nervous to change the pass parameter of all devices other than those mounted as /boot and /root to 0 (zero)? If so, would it still make you equally concerned even if you initialized a daemon to change all pass parameters back to the accepted default of fstab after a certain amount of time had passed, which would then enable the running of fsck to check for cleanliness on the next boot, after which the daemon would once again set the pass parameters for the aforementioned devices back to zero and ad infinitum?

The filesystems in place on my system are ext2 for the /boot partition and Reiserfs for all others (although I am thinking the answer to my question may be applied to other journaled filesystems as well). What possible complications do you all think could arrise from using this particular method to speed up the boot process? Thank you for your time.

Abstracity

Last edited by abstracity (2007-08-08 14:28:42)

steven · 2007-08-08 15:18:58

I don't run fsck on boot - I never have. It's safe, you only really need to run it if you've powered down without unmounting.

abstracity · 2007-08-08 17:29:38

Thank you for your quick response.

So, you don't even think one needs to run fsck on his or her /boot and/or /root partitions during startup? If this is true, then why is it generally recommended to give /root a pass flag of 1 so it is checked by fsck before all other filesystems?

I saw this video of some guy booting Arch with what I guess to be XFS as his most used filesystem. Here is the link. (REQUIRES FLASH) I have inferred that XFS is using fsck in a different manner than other filesystems do during startup, which may cause it to boot 5-10 seconds faster than a system with Reiserfs on its partitions. Does this mean that in the video--and in general--XFS takes less time to perform a filesystem check during boot because it simply checks some sort of log file for discrepancies and that's it, while Reiserfs, on the other hand, has to manually check each one for inconsistency? Or does the person's XFSed system boot up faster because fsck was disabled on startup like steven has stated he currently does?

Those questions may have seemed to fly right by, so to sum up what I've just said, I'll list the possible explanations for the points just discussed.

1. The person in the video disabled the routine consistency check fsck performs on system startup - OR - That is how the XFS filesystem operates, and its normal boot time on a lightweight distro such as Arch is simply just that fast. (Someone who uses or has used XFS on Arch will most likely be able to answer this.)

2. You can disable fsck from startup even for partitions with mount points of /boot and /root, thus safely equaling the normal time it takes to boot a system formatted with XFS.

retsaw · 2007-08-08 19:05:23

Since fsck is only run when the filesystems are not cleanly unmounted, why disable this?

There is the issue of the periodic check which happen by default on ext2/3 filesystems, but you can change the defaults using tune2fs to make them less frequent or even completely disable them.

Just had a look at that video, and the booting isn't exceptionally fast. My desktop machine boots to a full KDE desktop in ~38s and my machine is slower* than the one in that video.

*I didn't see what speed the processor ran at, but did read the message that it does 6435 bogomips, so is clearly faster than my Athlon XP 2800+ which can only do 4380 bogomips.

Last edited by retsaw (2007-08-08 19:22:30)

nikron · 2007-08-08 20:53:33

I don't run fsck on boot, but I turned full journaling on.

abstracity · 2007-08-08 21:35:37

retsaw,

Reiserfs does do a minimal check of the internal tree that can be evidenced by the "Checking all filesystems" stage, which thus increases the amount of time it takes for one's system to boot. For your question, "why disable this?", I can only tell you why I would prefer this barebones way of booting the system: for simplicity and initial speed.

One of my original questions was: Is it (in most desktop user cases) safe to disable this minimal check on the internal tree, or could this way of doing things cause serious consequences to arrise in the future if a check like this wasn't performed. Another user already replied to this by telling me it was in fact safe.

But what I now would be interested in knowing is this: If one considers the sole problem of which filesystem to use to obtain a faster boot-time coupled with future stability, then may it be wise to consider using XFS since its "minimal check" can allow a system to boot at the speed Reiserfs allows its system to boot when not using an internal tree check? In other words, the XFS setup would be safer since it checks if everything is "just right" while running at the fast speed that Reiserfs does when it does not check to see if everything is all right. And again, this only would apply if it is unsafe to not perform this initial check on the filesystem during startup, because if it is safe, then it would be logical to be able to use Reiserfs with the fsck flag disabled to achieve maximum efficiency.

Since I started out comparing only XFS with Reiserfs, then that is what I've continued to do, but I do realize that these concepts may be applied to other journaled filesystems as well.

Arch Linux

#1 2007-08-08 11:26:03

Safe to stop fsck on boot?

#2 2007-08-08 15:18:58

Re: Safe to stop fsck on boot?

#3 2007-08-08 17:29:38

Re: Safe to stop fsck on boot?

#4 2007-08-08 19:05:23

Re: Safe to stop fsck on boot?

#5 2007-08-08 20:53:33

Re: Safe to stop fsck on boot?

#6 2007-08-08 21:35:37

Re: Safe to stop fsck on boot?

Board footer