CentOS - Sep 2011 - how to stop an in-progress fsck that runs at boot?

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 at 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/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.


-- 
Josh Miller
Open Source Solutions Architect
http://itsecureadmin.com/

On Tue, Sep 13, 2011 at 8:39 PM, Matt Garman <matthew.garman at
gmail.com>wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos/attachments/20110914/656cfc65/attachment.html>