Crackpot Ideas

After responding to Jeremy’s message on Oracle-L, it got me reading his blog.  On one post, he asks if OCFS2 has a future given the rumored introduction of “ASMfs“, and if it’s worth considering for various purposes, specifically:

”

• database binaries (vs local files or NFS)
• diag top (11g) or admin tree (10g) (vs local files or NFS)
• archived logs
• backups”

I’ll go through my opinion on each of these four scenarios in a sec.  But first, I do believe OCFS has a long and prosperous future ahead of it.  First, it’s part of the mainstream Linux kernel – so it’s grown beyond just something Wim Coekearts cooked up in the lab.  Second, even if Oracle does introduce an ASM filesystem driver for Linux (I actually got about 1/2 through writing one myself, and I’m glad I dropped it if Oracle is building one), there’s going to be people who don’t want to trust ASM as a filesystem store, or sysadmins who believe filesystems are meant to be in the OS, dammit.  Third, even if there’s an ASM filesystem, chicken-and-the-egg problems mean that things like Oracle binaries won’t be able to be stored in ASM.  So – Oracle ain’t dropping OCFS2 anytime soon.

But – back to the original question.  What is OCFS2 good for?  I’ve seen how a lot of shops use RAC, and there are some clear advantages to using OCFS2 for certain things in a block environment.   Let’s go through Jeremy’s areas and see where there’s a fit:

• Database binaries – definitely not.  I don’t believe in shared ORACLE_HOME installs to begin with, whether it’s on NFS, OCFS2, GFS, or any CFS.  Shared storage is usually expensive storage, and having multiple homes allows you to survive patching problems or horrible operator error.  Local disk space is cheap.
• Diag top/admin directories – yes, this probably makes sense. It’s convenient to be able to put your tracefiles and everything else in one place. Performance isn’t a real consideration there too, and this doesn’t take a bunch of disk space.
• Archive logs – definitely, especially if you’re using ASM in addition to OCFS2, keeping a copy of archive logs outside of ASM is just what the doctor ordered for when your ASM instance explodes and you need to recover your database
• Backups – well, it’s not clear what kind of backups we’re talking about here, but I typically don’t recommend putting your FRA on OCFS2, as its just easier to put it in ASM.  If we’re talking about exports, rman backups, etc. – I would say it’s probably easier to just put that on non-clustered shared disks, and you’ll get better performance.  You can always unmount and remount the disks on another node if you need to.

So there we go.  But even if you’re looking at an environment where all the datafiles will be in ASM, there’s one more area where OCFS2 can help:

• OCR and voting – why dedicate little baby SAN disks to OCR and voting when you can just put them on an OCFS2 filesystem?  If you’re at an unfortunate organization where you can only get disks of a certain size (9G,18G,etc.), no need to waste the whole disk on the OCR and voting, make them OCFS2 filesystems, put the OCR and voting on them, and then use the rest of the space for scripts, dump areas, etc.

So, there we go.  IMHO, how to use OCFS2 the right way.