stoffel@lucent.com wrote:
> 1. lock application(s), flush any outstanding transactions.
> 2. lock filesystems, flush any outstanding transactions.
> 3a. lock mirrored volume, flush any outstanding transactions, break
> mirror.
> 3b. snapshot filesystem to another volume.
Or, to avoid the penalty of locking everything and bringing it down
and stuff:
1. set a flag.
2. start backing up blocks (read them raw of course, don't want to load
those stressed higher level systems)
3. If something wants to write to a block, quickly back up the old
contents of the block before you write the new contents. Unless of
course you've already backed up that block.
Of course, step 3 does place a bit more unschedulable load on the
disk. Heck, when the backups have just started, you're doubling the
latency of the devices. You can avoid this with a transaction
journal; in fact, the cockier RDBMSes out there (eg, DMSII) don't even
bother to do this and assume that your transaction journal is on a
mirrored device - and hence there's no point in backing up the old
data, you just want to do one sweep of the disk - and replay the
journal to get current.
(note: implicit assumption: you're dealing with applications using
synchronous I/O, where it needs to be written to all mirrors before
it's trusted to be stored)
Ah, moot points - the Linux MD/LVM drivers are far too unsophisticated
to have journal devices ;-)
--
Sam Vilain, sam@vilain.net WWW: http://sam.vilain.net/
7D74 2A09 B2D3 C30F F78E GPG: http://sam.vilain.net/sam.asc
278A A425 30A9 05B5 2F13
Law of Computability Applied to Social Sciences:
If at first you don't suceed, transform your data set.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:30 EST