Pavel Machek wrote:
This means ONLY SOME metadata (or no metadata) is flushed and
then all metadata updates are stopped. User/kernel writes
to already allocated file pages WILL go to a frozen disk.
That's the difference here. They do write file data, and thus avoid
mmap()-writes problem.
...and they _still_ provide auto-thaw.
Pavel
One of the hardest things to make people understand is that
stopping file data writes in the filesystem during a freeze
is not just dangerous, it is also __worthless__ unless you
have a complete "user environment freeze" mechanism.
In a real 24/7 environment, the DB and application stack
may be poorly glued together stuff from multiple vendors.
And unless each independent component has a freeze and they
can all be coordinated, the data in the pipeline is never
stable enough to say "if you stop all writes to disk and
take a snapshot, this is the same as an orderly shutdown,
backup, restore, and startup".
If you need to stop applications before a freeze, there
is no reason to implement "stop writing file data to disk".
The only real way to make it work (and what the smart apps
do) is to have application "checkpoint" commands so they
can roll-back to a stable point from the snapshot while
allowing new user activity to proceed.
People who don't have checkpoints or some other way to
make their environment stable with a transitioning snapshot
must stop all user activity before snapshotting and have
maintenance windows defined to do that.
jim
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
