Re: superblock backups, ASM vs OCFS2
- From: "Jeremy Schneider" <jeremy.schneider@xxxxxxxxxxxxxx>
- To: "Finn Jorgensen" <finn.oracledba@xxxxxxxxx>
- Date: Thu, 13 Dec 2007 13:03:44 -0600
OCFS2 and ASM both support async and directIO (note 279069.1)**.
Performance-wise, I'm pretty sure that there's not a big difference one way
or the other for day-to-day operation. There may be some minor differences
when extending files or creating new ones but I don't think that they're
anything to fuss over.
Since there's no major difference in performance-related capabilities, for
me the choice would probably hinge on other factors.
- OCFS2 is open-source. (+1 for power-users!)
- OCFS2 already does superblock backups. (+1 for recoverability.)
- ASM is integrated with Database Console/Grid Control. (+1 for
manageability.)
- ASM does cluster-aware volume management. (+1 for flexibility.)
I do think that the last one is a strong point in favor of ASM. Volume
management really can simplify things. And with ASM you get volume
management and still have a single point of contact for any bugs you
discover - no finger-pointing. Also, I don't know of any open-source LVM
that I'd really want to use to do any kind of redundancy - so if you need
software mirroring on linux then I think that ASM is really the best
solution for you. And if you want ease-of-management then ASM is better in
that area too.
Now you could get volume management and stay open-source with OCFS2 by using
cLVM. However I don't think that cLVM currently supports mirroring or
parity. IBM's EVMS also has cluster functionality and is GPL - but from the
release history and mailing lists it seems like noone's maintaining it
anymore. And I think you can buy ServiceGuard for Linux and get
cluster-aware volume management there too. There might be more commercial
solutions that I'm not aware of.
Not to mention GFS, which I'd also really like to spend more time learning
someday. GFS has its own feature called "pools" which also provide volume
management though I think that RedHat is moving toward cLVM for cluster
volume management with GFS. You can run your Oracle RAC database on GFS
(note 329530.1) but if there are any filesystem-related bugs then Oracle
will tell you to call RedHat for the fix (note 423207.1).
Anyway, just some random musings... I've always liked being able to dig
into the source code of whatever's running on my systems so I'm kindof keen
on OCFS2... but it does appear that the general push is toward ASM these
days.
DB+RAC+ASM/OCFS+OEL+Oracle VM... is there anything Oracle doesn't do these
days? Next year I'm anticipating Oracle Open Office... after all it's the
final frontier...
========
Addendum: while I was writing this email there were a few responses on the
ocfs-users list (I cross-posted).
Definitive answers:
OCFS: "Backup superblock has been available with ocfs2-tools 1.2.3 (Mar
2007)."
http://oss.oracle.com/projects/ocfs2/dist/documentation/ocfs2_faq.html#BACKUPSB
ASM: "In 11.1.0.7 (and beyond) we will have a backup of the disk header (the
first 4k). Prior to that, we have been able in most circumstances to
reconstruct the disk header using KFED. KFED will still be the tool to
restore the disk header going forward, it will just be a simpler, more
reliable procedure."
So it looks like OCFS backs up your superblock as long as you got it after
March. And it is often possible to reconstruct an ASM disk header and
backups will be made in 11.1.0.7 and beyond. And if you ever wondered what
that KFED tool was for...
========
On 12/13/07, Finn Jorgensen <finn.oracledba@xxxxxxxxx> wrote:
>
> Jeremy,
>
> I don't know the answer to your question but this reasoning :
>
> >This seems to me to be a great reason to choose OCFS2 over ASM.
> Recovering a backup superblock is MUCH faster than recreating the entire
> volume and restoring data from backup!!!
>
> is like saying you should use MySQL instead of Oracle because if you lose
> one file you can just restore that one file and carry on. No downtime, no
> recovery. Once human error enters the picture all bets are off. What if your
> "someone" had decided to dd a bunch of data into the device your OCFS2
> filesystem is built on? Your superblock backup would have been obsolete.
> What if the performance requirements for your database aren't satisfied by
> OCFS2?
>
> Your question is valid and interesting I just don't see it as a reason to
> choose one option over the other.
>
> Finn
>
>
> On 12/13/07, Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx > wrote:
> >
> > Just wondering, does anyone know much about "superblock" backups in ASM
> > vs OCFS2?
> >
> > I ran into an interesting case a month or so back where someone had
> > accidentally tried to initialize their ASM disks with linux LVM... and
> > written the LVM headers to the disk. It was just a few bytes at the very
> > top of the disk - but it was enough to totally hose ASM. Which started me
> > thinking, "if this was a filesystem then I'd have a backup superblock that I
> > could recover". Who knows - maybe ASM has a backup of its header block -
> > but it's all proprietary and if there's a tool that will recover an ASM
> > header then it's probably buried at Oracle support somewhere.
> >
> > Looks like OCFS2 includes superblock backups since this patchset:
> > http://lkml.org/lkml/2007/1/22/148
> >
> > Not sure if ckfs will recover them but since it's open source it'd be
> > trivial to put together a utility that would recover a superblock.
> >
> > This seems to me to be a great reason to choose OCFS2 over ASM.
> > Recovering a backup superblock is MUCH faster than recreating the entire
> > volume and restoring data from backup!!! I don't even know if you could use
> > dd to try to backup your ASM disk headers - since it's proprietary I don't
> > know what's in those blocks.
> >
> > Anyone have any thoughts on this? Is there something I'm missing here?
> >
> > Jeremy
> >
> >
> > --
> > Jeremy Schneider
> > Chicago, IL
> > http://www.ardentperf.com/category/technical
> >
>
>
--
Jeremy Schneider
Chicago, IL
http://www.ardentperf.com/category/technical
Other related posts:
