Re: superblock backups, ASM vs OCFS2

I totally agree about always using partitions in Linux.

However in this particular case the ASMLIB labels were created on top of entire disks - and I don't think that ASMLIB never issued any warnings about not using partitions. (I don't remember ever seeing any warnings - is this a new feature in 11g?) FYI, this was a rushed setup of a test environment for some basic load testing... I always create partitions for production setups and somehow this particular case was the exception. (I don't remember; they may have had ASM setup for this machine before I arrived onsite. The entire setup and load testing of five different platforms was done in 4 days, according to their requirements.)

An SA apparently went in later and created partition tables and LVM labels on the partitions. I'm pretty sure that partition tables are written at the *end* of the first block - which is why the ASMLIB labels were fine (at the top of the block). And the LVM labels were in the partition - corrupting the ASM disk headers but leaving the ASMLIB labels untouched again.

It was actually a pretty tricky situation to figure out at first - they called back several months after I'd come onsite to do the testing and wanted help figuring out why they couldn't mount the ASM disks. And I assumed that I'd made the partitions at first and couldn't figure out why the ASM disk headers didn't point to the partitions. Took a little detective work. :)

Jeremy

On 12/16/07, Alex Gorbachev <ag_at_oracloid.com> wrote:
> Jeremy,
>
> Oracle normally skips the first block of datafiles on raw devices to
> avoid intervention with LVM headers. I wish they do that for ASM but
> in ASM that space if used by ASM itself for similar purpose as in LVM.
>
> On the other hand, ASM disks should be created on top of partitions
> (in Linux terminology) but not the whole disks themselves. In fact,
> ASMLib (if you happen to use it) requires that - it won't mark ASM
> disk unless it's a partition. This would save your disk in case when
> the header of the LUN/physical disk is corrupted. Though, partition
> table may be hosed but that's recoverable and you can easilly back it
> up with "dd" - it's static.
>
> Cheers,
> Alex
>

-- 
Jeremy Schneider
Chicago, IL
http://www.ardentperf.com/category/technical
--
http://www.freelists.org/webpage/oracle-l