lvsplit and "bitmap" that's tracked...

[B. Chapman]

Fellow admins,

I've been trying to search for my answer on this - but putting the word "bitmap" into the search ends up with nothing but HP LJ fixes, desktop wallpaper fixes, etc. ;-)

So - I guess I'll have to pose the question:

What kind of processing overhead is associated with LVM keeping track of some "bitmap" immediately following an "lvsplit"?

What I'm looking for is to have ZERO PROCESSING OVERHEAD following an lvsplit. In particular (just for this ONE-TIME task), I'd like to LVSPLIT, immediately FSCK the lvol*b "splits", and then mount them up. I WILL *NEVER* LVMERGE! And, since I'll NEVER LVMERGE, I don't want any OS processes keeping track of a "bitmap".

Any suggestions? I've checked the man pages - and see that UNTIL a reboot, or increasing lvol sizes, or lvreducing the "b"s, that the "bit map will remain in existence". Well - to me - "remain in existence" = BACKGROUND OS PROCESSING - and that's what I *really* want to avoid.

Quick background on what I'm trying to accomplish: We'll be performing a BIG Oracle Financials upgrade next week during Thanksgiving downtime, and, of course the 1st task before starting step 1 is to BACKUP THE "OLD" ENVIRONMENT. And then, in the event of a FAILED UPGRADE (say it ain't so!), I'd need to quickly RESTORE. I'm thinking that instead of tape backup/restore, to use lvmirroring, lvsplit, and then in the event of a major upgrade failure, mount the lvol*b's to production mountpoint names, and, voila! It's restored.

Does this make sense? Am I attacking this in the right way?

As always - many many thanks in advance to any answers and/or advice.

Later,
Ben Chapman
chapmanb@saic.com

[Sanjay_6]

Hi Ben,

Is this what you are looking for.

This is a doc from itrc,

http://www2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000068501572

the doc id is A4286984.

hope this helps.

regds

[Sridhar Bhaskarla · Accepted solution]

Hi Ben,

I believe unless you guarantee it to the OS that you are never going to 'merge' them again, the bit map will be stored in memory. Since it is in memory, it will be lost once the system is rebooted.

To guarantee it, you will need to change the size of the logical volume. Since 'lvreduce' is not an option, I suggest you increase the filesystem by just one extent which is enough for the OS to ignore the bit map. Yes - I agree that split is a clever backout plan.

-Sri

[B. Chapman]

Sanjay, Sri,

Many thanks for the pointer to the memory structure - and many thanks for the confirmation that the bitmap will get DROPPED after lvextending.

Just an FYI - that's exactly what I/we have decided that we're going to do next week - lvsplit, then vgextend all of the *original* lvols +1 PE (and, just to get usage out of the whopping extra 4Mb, we'll also "fsadm" to increase the filesystem size that lives on each lvol). Then, we can start our upgrade on those lvols/mountpoints - with the knowledge that NO BITMAP is getting "tracked" (and because of that, hopefully, no extra OS processing overhead). Actually - as a bonus - while the upgrade is running - we're going to fsck/mount the lvolB's (the split-off lvols) to different mountpoint names - and snap a backup of those - to put on the shelf FOR GOOD (a final backup of our pre-upgraded system, to have around for 7 glorious years to cover auditing limitations).

Again Gents - many thanks for your input. Points have been assigned.

Later,
Ben Chapman
chapmanb@saic.com