I can't seem to find the answer to this question via web search... I changed some hardware on a server, and upon powering it back on, got the "/dev/xxx has gone 40 days without being check, check forced" message. Now it's running fsck on a huge (2 TB) ext3 filesystem (5400 RPM drives no less). How can I stop this in-progress check? Ctrl-C doesn't seem to have any effect. Is the only answer to wait it out?
Also, as a side question: I always do this---let my servers run for a very long time, power down to change/upgrade hardware, then forget about the forced fsck, then pull my hair out waiting for it to finish (because I can't figure out how to stop it once it starts). I know about tune2fs -c and -i, and also the last (or is it second to last?) column in /etc/fstab. My question is more along the lines of "best practices"---what are most people doing with regards to regular fsck's of ext2/3/4 filesystems? Do you just take the defaults, and let it delay the boot process by however long it takes? Disable it completely? Or do something like taking the filesystem offline on a running system? Something else?
Thanks, Matt
On Tue, 2011-09-13 at 21:39 -0500, Matt Garman wrote:
I can't seem to find the answer to this question via web search... I changed some hardware on a server, and upon powering it back on, got the "/dev/xxx has gone 40 days without being check, check forced" message. Now it's running fsck on a huge (2 TB) ext3 filesystem (5400 RPM drives no less). How can I stop this in-progress check? Ctrl-C doesn't seem to have any effect. Is the only answer to wait it out?
Don't know the answer but apart from the obvious annoyance you can try to look on the good side and be reassured, eventually when it finishes, that your disk and contents are in good condition.
Would be nice if one could schedule this sort of work for off-peak.
Regards,
Paul.
On 09/13/2011 09:39 PM, Matt Garman wrote:
I can't seem to find the answer to this question via web search... I changed some hardware on a server, and upon powering it back on, got the "/dev/xxx has gone 40 days without being check, check forced" message. Now it's running fsck on a huge (2 TB) ext3 filesystem (5400 RPM drives no less). How can I stop this in-progress check? Ctrl-C doesn't seem to have any effect. Is the only answer to wait it out?
Also, as a side question: I always do this---let my servers run for a very long time, power down to change/upgrade hardware, then forget about the forced fsck, then pull my hair out waiting for it to finish (because I can't figure out how to stop it once it starts). I know about tune2fs -c and -i, and also the last (or is it second to last?) column in /etc/fstab. My question is more along the lines of "best practices"---what are most people doing with regards to regular fsck's of ext2/3/4 filesystems? Do you just take the defaults, and let it delay the boot process by however long it takes? Disable it completely? Or do something like taking the filesystem offline on a running system? Something else?
Thanks, Matt _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
my first post here. that same thing happened with me a few years ago with RHEL. i'm trying to remember the steps and seems like booted into single user/rescue mode and then turned the fsck flag to off in fstab for the partition(s). hope that can at least point you in the right direction.
On 09/13/11 8:57 PM, Tracy Bost wrote:
my first post here. that same thing happened with me a few years ago with RHEL. i'm trying to remember the steps and seems like booted into single user/rescue mode and then turned the fsck flag to off in fstab for the partition(s). hope that can at least point you in the right direction.
tune2fs sets the counter (40 days or whatever).
On 09/13/2011 07:39 PM, Matt Garman wrote: ...
Also, as a side question: I always do this---let my servers run for a very long time, power down to change/upgrade hardware, then forget about the forced fsck, then pull my hair out waiting for it to finish (because I can't figure out how to stop it once it starts). I know about tune2fs -c and -i, and also the last (or is it second to last?) column in /etc/fstab. My question is more along the lines of "best practices"---what are most people doing with regards to regular fsck's of ext2/3/4 filesystems? Do you just take the defaults, and let it delay the boot process by however long it takes? Disable it completely? Or do something like taking the filesystem offline on a running system? Something else?
...
I make an effort to note the count before rebooting and if I don't have time to allow the fsck, I will adjust the max-mount-counts to give me some time to plan an fsck on a subsequent reboot.
On Tue, Sep 13, 2011 at 8:39 PM, Matt Garman matthew.garman@gmail.comwrote:
My question is more along the lines of "best practices"---what are most people doing with regards to regular fsck's of ext2/3/4 filesystems? Do you just take the defaults, and let it delay the boot process by however long it takes? Disable it completely? Or do something like taking the filesystem offline on a running system? Something else?
If you are running on LVM and have (enough) free space available then there is a very easy way to check the filesystem for errors. If this finds errors then you can run it on the real filesystem when you can schedule downtime to fix them. It also will give you a good estimate about the amount of time you will need to schedule.
- Create an LVM snapshot of the volume you want to check - Preen the filesystem to fix and minor in-progress stuff the snapshot caused - Force a full filesystem check and watch for any errors
lvcreate -s -L 50G -n fsck_snapshot vg_name/lv_name e2fsck -p -C0 /dev/vg_name/fsck_snapshot e2fsck -fy -C0 /dev/vg_name/fsck_snapshot lvremove -f vg_name/fsck_snapshot
Make sure the 50G above gives you enough room for all the writes that will take place during the fsck operation.
-Shad
-
Always Learning -
John R Pierce -
Josh Miller -
Matt Garman -
Shad L. Lords -
Tracy Bost