lkml.org 
[lkml]   [2002]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Backups done right (was [ANNOUNCE] Ext3 vs Reiserfs benchmarks)
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:4.097 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site