Fsck at runtime/shutdown?

Message

CoderMan · Post by **CoderMan** » Mon Nov 09, 2009 10:42 pm

I've got Gentoo installed on my Dell Mini Inspiron 10v which I take with me everywhere. Waiting for fsck to scan my partitions at startup is simply too annoying, and it can also be an embarrassment when I am showing off Linux to my buddies. So I just told fstab not to check anything.

Maybe this is something I could be doing automatically as part of the shutdown process instead...? Thoughts? If not, maybe manually during runtime? (I'd have to unmount the partitions first, right?)

My system:

AMD Opteron 32-bit
Two real partitions: /dev/sda1, /dev/sda2
boot is mounted on /dev/sda1
/dev/sda2 is a luks encrypted partition containing an LVM physical volume with one volume group and five logical volumes

eccerr0r · Post by **eccerr0r** » Mon Nov 09, 2009 11:09 pm

If you shutdown your machine properly at shutdown (eek...) then you wouldn't need to fsck at startup!

I almost never need to fsck. If you have to fsck every startup, something is wrong. Is the machine turning off before it unmounts the disks?

BTW, you might well shutdown the machine and restart it, if you want to fsck during the day... but then again, why do you need to fsck in the first place?

CoderMan · Post by **CoderMan** » Mon Nov 09, 2009 11:17 pm

eccerr0r wrote:If you shutdown your machine properly at shutdown (eek...) then you wouldn't need to fsck at startup!

I almost never need to fsck. If you have to fsck every startup, something is wrong. Is the machine turning off before it unmounts the disks?

BTW, you might well shutdown the machine and restart it, if you want to fsck during the day... but then again, why do you need to fsck in the first place?

I don't really know why we fsck... doesn't it have something to do with journaling file systems and restoring inodes if data is lost during a sudden power loss?

eccerr0r · Post by **eccerr0r** » Mon Nov 09, 2009 11:36 pm

Was covering all the bases here...

So you're running a journaling file system, it should have even less of a reason to fsck. It should be able to replay the journal and save some of the issues during the improper shutdown.

Are you sure the machine is using a journaling file system? It should replay them.

Are you shutting down improperly regularly? Just making sure you aren't... Journaling file systems does not mean you can shutdown any time, it's just to help try to keep your files are consistent in case something goes wrong. It won't catch all cases.

Another thing is the time limits between fscks. Are you hitting those? For ext3fs you can use tune2fs to increase the number of mounts between forced checks and/or time between checks. You should be able to see from bootup logs whether these are being hit or not.

CoderMan · Post by **CoderMan** » Mon Nov 09, 2009 11:45 pm

eccerr0r wrote:Was covering all the bases here...

So you're running a journaling file system, it should have even less of a reason to fsck. It should be able to replay the journal and save some of the issues during the improper shutdown.

Are you sure the machine is using a journaling file system? It should replay them.

Are you shutting down improperly regularly? Just making sure you aren't... Journaling file systems does not mean you can shutdown any time, it's just to help try to keep your files are consistent in case something goes wrong. It won't catch all cases.

Another thing is the time limits between fscks. Are you hitting those? For ext3fs you can use tune2fs to increase the number of mounts between forced checks and/or time between checks. You should be able to see from bootup logs whether these are being hit or not.

Sorry, forgot to mention: all paritions and logical volumes are XFS.

No, I usually shut down properly.

I don't want to fsck during startup because, even if it only happens once every two-hundred mounts, it is still really annoying and sometimes embarrassing.

So, you think I should just forget about fsck and just keep it turned off in fstab?

eccerr0r · Post by **eccerr0r** » Mon Nov 09, 2009 11:55 pm

I find nothing embarrassing with fscking on startup, it's perfectly normal for Un*x. Annoying, yes, when you "know" the filesystem is fine, but who knows, maybe fsck finds something. Nothing is more embarrassing than losing data that could have been caught by a fsck. A hybrid solution which I'm not sure someone has implemented is to simply do a y/n question whether to fsck or not on startup...

Sounds like in your case, you might as well just shut off fsck and run it manually (go to single user mode and mount disks read only first). Likely need to reboot afterwards, then again, probably cant do much else anyway with the disks readonly. Yes fsck, for highest benefit, should be done before disks are mounted read-write. Writing to disk to a corrupt file system has the tendency to make the inconsistency even worse, potentially leading to massive data loss.

CoderMan · Post by **CoderMan** » Tue Nov 10, 2009 3:58 am

eccerr0r wrote:I find nothing embarrassing with fscking on startup, it's perfectly normal for Un*x. Annoying, yes, when you "know" the filesystem is fine, but who knows, maybe fsck finds something. Nothing is more embarrassing than losing data that could have been caught by a fsck. A hybrid solution which I'm not sure someone has implemented is to simply do a y/n question whether to fsck or not on startup...

Sounds like in your case, you might as well just shut off fsck and run it manually (go to single user mode and mount disks read only first). Likely need to reboot afterwards, then again, probably cant do much else anyway with the disks readonly. Yes fsck, for highest benefit, should be done before disks are mounted read-write. Writing to disk to a corrupt file system has the tendency to make the inconsistency even worse, potentially leading to massive data loss.

Thanks. I just decided to shut fsck off (sounds like an obscene statement...) and forget about it. Not afraid of losing data because all the important stuff is either backed up or on a remote server.

Just to clarify, the embarrassing part is when you been telling your Windoze buddies how awesome and fast Linux is, and then you go to start up your laptop for them, and this just happens to be the time when boot up takes three minutes instead of one. And then you have explain how this doesn't happen everytime, but you've already lost their attention. (Yes, this has happened to me.)

zyko · Post by **zyko** » Tue Nov 10, 2009 7:45 am

Maybe this is something I could be doing automatically as part of the shutdown process instead...?

That's possible, at least with OpenRC. The file /etc/conf.d/fsck contains the following:

Code: Select all

# fsck_shutdown causes fsck to trigger during shutdown as well as startup.
# The end result of this is that if any periodic non-root filesystem checks are
# scheduled, under normal circumstances the actual check will happen during
# shutdown rather than at next boot.
# This is useful when periodic filesystem checks are causing undesirable
# delays at startup, but such delays at shutdown are acceptable.
fsck_shutdown="NO"

Switch fsck_shutdown to YES and be happy.

This may also be available with baselayout-1. otherwise you have to unmask baselayout and openrc.

emerald · Post by **emerald** » Tue Nov 10, 2009 1:43 pm

CoderMan wrote: Sorry, forgot to mention: all paritions and logical volumes are XFS.

XFS is never fsck'd on my system, since the fsck.xfs is just a placeholder to tell you to use xfs_check or xfs_repair to do the job. So I wonder what's wrong with your system that your XFS partitions are fsck'd by a placeholder?