fsck would run on it's own when I reboot my server, but most of the time it doesn't. But when it does run, it takes too long to finish. Is it safe to disable this permanently?
If this is a production server, it's not a good idea to disable fsck's automatically scheduled checks on boot.
fsck automatically runs on boot after M mounts or N days, whichever comes first. You can tune this schedule using
I would suggest leaving the automatic check enabled, but using tune2fs to adjust the check schedule if appropriate, and forcing
fsck to run when it is more convenient.
When fsck runs, it will reset the
Mount count to
0 and update the
Last checked field, effectively rescheduling the next automatic check.
If you don't want to run
fsck manually but you know it will be convenient on the next scheduled reboot, you can force
fsck on the next boot:
You can make your system run fsck by creating an empty 'forcefsck' file in the root of your root filesystem. i.e.: touch /forcefsck Filesystems that have 0 or nothing specified in the sixth column of your /etc/fstab, will not be checked
With ext2, ext3 and ext4 you can use
dumpe2fs -h /dev/diskname
I wouldn't. You can disable it if you have a policy for manually running fsck periodically, and use a fully journaling file system, but otherwise it is important for long term file system health. With boot checking disabled, you will only have fsck run automatically if your journal is marked as dirty, but it will not do things like bad sector checks, or manually look for file system issues that have not already been recorded.
I am glad to complement the "no-no-no" answers with some new ideas.
It depends on the importance of the server.
If it is extreme important (for example, your job depends on it): what you want to fix, is not your problem. Your problem is not the slow fsck, but the frequent rebooting. This is what you should fix.
If it is not so important: go ahead! If your reboots are clean (there is always clean shutdown), the only way for a filesystem error to happen, is a serious kernel or hardware bug. But they have mostly alternative symptoms too (see dmesg).