* [linux-lvm] Snapshots and mmaped files.
@ 2005-04-19 17:08 David Brown
2005-04-20 21:36 ` Dan Stromberg
0 siblings, 1 reply; 3+ messages in thread
From: David Brown @ 2005-04-19 17:08 UTC (permalink / raw)
To: linux-lvm
I'm using lvm2 snapshots to do backups of several machines. (lvm2
2.00.33, device-mapper 1.01.00,
ftp://sources.redhat.com/pub/dm/patches/2.6-unstable/2.6.9/2.6.9-udm1.tar.bz2
minus patch 13) (I've tried some newer patches, without success, but
that'll be a separate mail).
The problem shows up with files that contains Berkeley databases. These
files seem to be modified on both the original and the snapshot. They
show up in my 'var' partition with imapd, and exim, and anything else that
has a berkeley database opened, and modifies the file after the snapshot
is taken.
The mtime of the file is not modified, only the contents. I suspect that
if one side grew, then the size change would not be affected.
Thanks,
David Brown
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [linux-lvm] Snapshots and mmaped files.
2005-04-19 17:08 [linux-lvm] Snapshots and mmaped files David Brown
@ 2005-04-20 21:36 ` Dan Stromberg
2005-04-21 4:06 ` David Brown
0 siblings, 1 reply; 3+ messages in thread
From: Dan Stromberg @ 2005-04-20 21:36 UTC (permalink / raw)
To: LVM general discussion and development
[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]
If lvm2 snapshots are like most snapshots, then they aren't a panacea -
they only decrease the window during which your database must be
quiescent.
EG, with snapshotting:
1) Shut down database
2) bifurcate off a snapshot
3) Start up database
4) Do backup against snapshot
5) Eliminate snapshot
EG without snapshotting:
1) Shut down database
2) Do backup
3) Start up database
The first case has more steps, but it also has a lot shorter time during
which your database is inactive.
On Tue, 2005-04-19 at 10:08 -0700, David Brown wrote:
> I'm using lvm2 snapshots to do backups of several machines. (lvm2
> 2.00.33, device-mapper 1.01.00,
> ftp://sources.redhat.com/pub/dm/patches/2.6-unstable/2.6.9/2.6.9-udm1.tar.bz2
> minus patch 13) (I've tried some newer patches, without success, but
> that'll be a separate mail).
>
> The problem shows up with files that contains Berkeley databases. These
> files seem to be modified on both the original and the snapshot. They
> show up in my 'var' partition with imapd, and exim, and anything else that
> has a berkeley database opened, and modifies the file after the snapshot
> is taken.
>
> The mtime of the file is not modified, only the contents. I suspect that
> if one side grew, then the size change would not be affected.
>
> Thanks,
> David Brown
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [linux-lvm] Snapshots and mmaped files.
2005-04-20 21:36 ` Dan Stromberg
@ 2005-04-21 4:06 ` David Brown
0 siblings, 0 replies; 3+ messages in thread
From: David Brown @ 2005-04-21 4:06 UTC (permalink / raw)
To: LVM general discussion and development
I don't think this is an issue of the database needing to be quiescent.
The problem I'm seeing is that when the application modifies the database
_after_ the snapshot is taken, the modifications partially appear in the
snapshot as well. I'm guessing that file modification that goes through
write does the right thing in the snapshot, but modifications done via
mmap don't cause the snapshot to duplicate the data.
The Berkely DB code should be able to recover from a coherent snapshot
taken at any point in time.
Dave
On Wed, 20 Apr 2005 14:36:19 -0700, Dan Stromberg
<strombrg@dcs.nac.uci.edu> wrote:
> If lvm2 snapshots are like most snapshots, then they aren't a panacea -
> they only decrease the window during which your database must be
> quiescent.
>
> EG, with snapshotting:
>
> 1) Shut down database
> 2) bifurcate off a snapshot
> 3) Start up database
> 4) Do backup against snapshot
> 5) Eliminate snapshot
>
>
> EG without snapshotting:
>
> 1) Shut down database
> 2) Do backup
> 3) Start up database
>
>
> The first case has more steps, but it also has a lot shorter time during
> which your database is inactive.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-04-21 4:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-04-19 17:08 [linux-lvm] Snapshots and mmaped files David Brown
2005-04-20 21:36 ` Dan Stromberg
2005-04-21 4:06 ` David Brown
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.