Home > Oracle in general > ext3 – beware of periodic file system checks

ext3 – beware of periodic file system checks

Users running Oracle on Red Hat or Oracle Enterprise Linux will most probaly use ext3 as default file system. It is robust, well maintained, a journaling file system and supports file system sizes up to 32 TB.

Database servers must be “high available” – so they are booted infrequently if ever.

Even if ext3 is a journaling file system there are periodic full file system checks which will check the entire file system just like ext2 did after a crash. On todays large file systems this can take hours. Thats especially bad if you just “quickly” rebooted the server after applying a patch and now facing a long running file system check.

Many users complained about this behavior and said ext3 is a journaling file system and should be running without periodic checks. On the other hand this is a security feature. Even with journaling corruptions may be introduced and remain undetected for a long time.

So lets take a look at the defaults chosen on Oracle Enterprise Linux 5 Update 3 when creating a ext3 file system:

[root@rac1 ~]# mkfs.ext3 /dev/asm/testvol1-132
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
131072 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
 32768, 98304, 163840, 229376

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 22 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

The last two lines are the ones of interest: “The file system will be checked every 22 mounts or 180 days, whichever comes first”. On database serverss 22 mounts seems a long time but 180 days are quite short. So administrators should change these values accordingly. Turning it off completely is a loss of data protection but still possible.

You can check the mount counts, maximum mount counts and check intervals with the following command:

tune2fs -l /dev/asm/testvol1-132
Mount count:              0
Maximum mount count:      22
Last checked:             Thu Oct  1 10:44:53 2009
Check interval:           15552000 (6 months)
Next check after:         Tue Mar 30 10:44:53 2010

You are free to change these values with tune2fs:

[root@rac1 ~]# tune2fs -c 100 /dev/asm/testvol1-132
tune2fs 1.39 (29-May-2006)
Setting maximal mount count to 100

[root@rac1 ~]# tune2fs -i 360 /dev/asm/testvol1-132
tune2fs 1.39 (29-May-2006)
Setting interval between checks to 31104000 seconds


tune2fs -l /dev/asm/testvol1-132
Filesystem created:       Thu Oct  1 10:44:53 2009
Last mount time:          n/a
Last write time:          Thu Oct  1 11:02:09 2009
Mount count:              0
Maximum mount count:      100
Last checked:             Thu Oct  1 10:44:53 2009
Check interval:           31104000 (12 months)
Next check after:         Sun Sep 26 10:44:53 2010

So based on this information:

To which values should max mount count and check interval be set?

The actual values depend completely on your requirements. But they should be set completely different for different volumes. This will prevent a full check on all your volumes at once.

Categories: Oracle in general Tags:
  1. November 14th, 2009 at 17:38 | #1

    Have you been able to measure the (performance) impact of such filesystem checks on a running Oracle database ?

    Hemant K Chitale

  2. Ronny Egner
    November 14th, 2009 at 18:29 | #2

    The file system will only be checked at reboot. Just imaginge: You install a service pack / patch and need to reboot your system. When rebooting the file system says: “Hey… its been 180 days without check.. i will do this right NOW”… and you wait many minutes (if not hours).

    The performance impace of using a file system over raw/block devices havent been measured by me so far.

  3. Sayantan
    February 18th, 2010 at 14:49 | #3

    its looked nice…

  4. Mugnier102
    August 23rd, 2011 at 23:33 | #4

    Thanks for the tip… I will check this on a daily basic before the fatidic reboot !

  1. July 22nd, 2010 at 07:14 | #1