Find the answer to your Linux question:
Results 1 to 4 of 4
So say you have a file server. It's OS resides on /dev/sda. However, all of the data resides on MDADM arrays, /dev/md###. The number of different arrays is, say for ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jan 2005
    Posts
    54

    Unhappy Delay fsck routine disc checks until after OS has booted


    So say you have a file server. It's OS resides on /dev/sda. However, all of the data resides on MDADM arrays, /dev/md###. The number of different arrays is, say for arguments sake, five.

    Now, we know that fsck will run a routine check on partitions once every 120 (?) days or every ### (?) mounts. The numbers aren't important in this scenario.

    If a system administrator needs to reboot the server after, say, 200 days, clearly, all disks will want a routine check. So when the system reboots (after maintenance or what have you), instead of the system being down for the time it takes to reboot, now it's down for the time it takes to reboot PLUS the time it takes to scan all the partitions/disks/arrays. This can be an incredibly long downtime especially if there are huge partitions/arrays and lots of data to check.

    Quite unfortunate.

    How can we configure fsck to DELAY it's scan until after the system and services come online?

    The best example here is:
    * Say that all disks were recently scanned, except one, which has had it's routine scheduled check duration pass by, so next time we reboot, the system will scan this array for errors.
    * When we reboot, wouldn't it be ideal to have the entire system come up (SSH, web services, the rest of the file shares, etc) and only have the array scheduled for scanning be temporarily down? indeed ;-0

    Any ideas?
    Thanks!

  2. #2
    Linux Guru
    Join Date
    Nov 2007
    Posts
    1,746
    A) Google

    How to edit and understand /etc/fstab
    The 6th column is a fsck option. fsck looks at the number in the 6th column to determine in which order the filesystems should be checked. If it's zero, fsck won't check the filesystem.
    B) fsck.ext2( 8 ) - Linux man page

    Note that in general it is not safe to run e2fsck on mounted filesystems.

    This can be an incredibly long downtime especially if there are huge partitions/arrays and lots of data to check.
    Lack of planning/design is the biggest problem with any server configuration.

  3. #3
    Just Joined!
    Join Date
    Jan 2005
    Posts
    54
    Quote Originally Posted by HROAdmin26 View Post
    A) Google

    How to edit and understand /etc/fstab


    B) fsck.ext2( 8 ) - Linux man page
    Indeed, but how does DISABLING fsck solve anything? Also changing the order helps, but fsck will scan all required disks before proceeding with the boot process. Changing the order of scanning doesn't really help the issue does it?

    Quote Originally Posted by HROAdmin26 View Post
    Note that in general it is not safe to run e2fsck on mounted filesystems.

    Lack of planning/design is the biggest problem with any server configuration.
    I never suggested that I wanted to run fsck on a mounted filesystem.

    My point is, that instead of fstab running disk checks on on non-os dependent filesystems, we should be able to configure it such that it performs any required (regular) checks via the usual means, but for disks that aren't dependent for the OS or services, they be checked "later" in the boot process, after the OS has fully come online.

    i.e.

    1> Power On System
    2> fstab notices that ALL drives/partitions/arrays need to be checked
    3> fstab scans the OS drive (simplest case: /dev/sda)
    4> System continues to boot the OS and any other services (web services, SSH server, etc. come online sooner)
    5> Now it can run fsck on the rest of the drives (which might be a lengthy ordeal) ... when the scans are complete, mount the filesystem and resume normal operation.

    NOTE: I realize though that some services (let's say Apache for example), might actually require files on other partitions ... so it isn't an easy feat to simply say "what's required and what's not required" for the "services" to run.

  4. #4
    Linux Guru
    Join Date
    Nov 2007
    Posts
    1,746
    Indeed, but how does DISABLING fsck solve anything? Also changing the order helps, but fsck will scan all required disks before proceeding with the boot process. Changing the order of scanning doesn't really help the issue does it?
    If you don't want fsck to run, set it to 0. If you want fsck to run on your "system" volumes, then DON'T set it to 0 for that volume. How hard is that to understand?

    I realize though that some services (let's say Apache for example), might actually require files on other partitions ... so it isn't an easy feat to simply say "what's required and what's not required" for the "services" to run.
    So you have identified why this is not "default" behavior and you're asking...what? Are you going to redesign the startup process and define an inter-dependency framework between some fsck logic, volume definitions, and any/all services that could be running on a machine? If so, get to it. Otherwise, write a script that does what you want and move on.

    (If you want to see what a startup/dependency framework might look like, Google "solaris service management framework.")

    1) Set fsck to check what you consider your "system" volumes and set the others to 0. (If any other volumes are corrupt, they will just fail to mount at boot.)

    2) Write a script that:
    A) Shuts down any services that depend on the "non-system" volumes.
    B) Dismounts the "non-system" volumes.
    C) Runs fsck on the "non-system" volumes.
    D) Re-mounts the volumes and starts your services.

    It could be run manually when needed (if you see a volume doesn't mount/service fails) or automatically at boot time.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •