Avoiding lenghty fsck

Question

our DB version: 11.2
our OS: SLES11
our fs: ext3
My question: with the FRA residing on ext3, how can I avoid lengthy fsck runs on server reboots: even with clean shutdowns, Linux will eventually trigger forced fsck runs after a period of time (see also [Why the ext3 fsck’s after X days or Y mounts?|http://prefetch.net/blog/index.php/2010/04/18/why-the-ext3-fscks-after-x-days-or-y-mounts]).
Turning off this mechanism with tune2fs is not recommended.
Novell recommends using xfs instead of ext3. But would that really help (and xfs, although supported is not tested by Oracle according to MOS)?
With the FRA partition of a size of 2.1 TB, fsck can take up to 30 minutes or more, and this is a long time for the db server to come back to operation.
Of course, ASM comes to mind, but that would be just another slab of complexity in an otherwise simple installation.
Thanks for your opinion or sharing your XFS experience,
Thomas

Answer 1

here we have some further insight to share.
We did an extensive test to see which filesystem to choose for
our Samba shares, and took EXT3, BTRFS und XFS in the boat (all
supported by Novell SLES 11).
Novell's statement is that BTRFS is mainly a boot partition
choice, and recommends XFS for large amount of data.
The - only for testing purposes - setup, very shortly:
10 TB striping RAID on NearLine Disks in Fujitus Eternus,
formatted in a VMFS5 Datastore.
A VM (SLES11 SP2) on ESXi 5.1 (2 vCPU, 1 GB RAM) gets the space
as vdisks, and will format 3 * 3 TB file systems.
*1st test: creating the 3 TB file systems*
Btrfs: a few seconds
Ext3: about 30 minutes
XFS: about 9 minutes
as we create filesystems only once, let's not further look at
that.
*2nd test: fio throughput*
Without going into many fio details (we took 8GB samples, using
128 KB blocksize):
1.) linear read/write
KB/s | Btrfs Ext3 XFS
------+-------------------------------
read | 89.045 83.262 91.740
write | 13.722 198.622 208.947
2.) random read/write
KB/s | Btrfs Ext3 XFS
------+-------------------------------
read | 41.702 28.920 17.548
write | 59.792 128.033 74.353
Btrfs shows some linear writing lazyness, because of its
checksumming. XFS dissappoints with its random read throughput.
*3dr test: find performance*
we tested how quickly a file is found using the find command. For
that, we filled the file systems with about 1.2 TB test data from
production systems (typical shared Samba drives, with office
documents and all that stuff). After each test, we did a reboot
to ensure a clean file system cache.
Btrfs: 2 m 53 s
Ext3: 9 m 58 s
Xfs: 1 m 9 s
Similarly, we queried du Info for each and the whole of the three
file systems:
Btrfs: 8 m 4 s
Ext3: 19 m 35 s
Xfs: 4 m 20 s
We see that Ext3 is not very efficient when it comes to
traversing large file systeme metadata.
*4th test: fsck runtime*
We force a file system check.
It's worth considering the CAVEAT from the btrfsck man page:
"btrfsck is part of btrfs-progs. Btrfs is currently under heavy
development, and not suitable for any uses other than benchmarking
and review. Please refer to the btrfs wiki
http://btrfs.wiki.kernel.org for further details."
Btrfs (command was "time btrfsck ..."): 9 m 6 s
Ext3 (command was "time fsck -f ..."): 72 m 35 s
XFS (command was "time xfs_repair -n ..."): 11 m 18 s
Ext3 is far slower when checking that sizy file systems: might
its checks simply be more exhaustive?
Back to initial topic: "avoiding lenghty fsck". It does not
appear irrelevant which cooke file system we choose. XFS appears
to be a far better choice in terms of fsck run time.
According to MOS 414673.1 (SuSE/Novell: Linux, Filesystem & I/O
Type Supportability), XFS is a supported choice, although there
are some important CAVEATS regarding bugs and taking most recent
versions.
Also, we read
Oracle does not run certifications on local
filesystems (i.e. except for OCFS2, NFS etc.) except ext2/ext3 as
it is the common default filesystem for all Linux
distributions. So if a problem happens specific to XFS, the Linux
vendor should be engaged.
This will bring us back to probably take ASM for Oracle data in
future (currently still using EXT3), and choose XFS for all other
user data.
For user data, we would also like to choose BTRFS, as we would
favour the automatic checksumming, but the status of btrfsck (see
above) alone is enough to hdissuade us from that choice for the
time being.
Comments welcome!
Regards, Thomas