On 7/16/10 3:07 PM -0500 David Dyer-Bennet wrote:
On Fri, July 16, 2010 14:07, Frank Cusack wrote:
On 7/16/10 12:02 PM -0500 David Dyer-Bennet wrote:
It would be nice to have applications request to be notified
before a snapshot is taken, and when that have requested
notification have acknowledged that they're ready, the snapshot
would be taken; and then another notification sent that it was
taken. Prior to indicating they were ready, the apps could
have achieved a logically consistent on disk state. That
would eliminate the need for (for example) separate database
backups, if you could have a snapshot with the database on it
in a consistent state.
Any software dependent on cooperating with the filesystem to ensure that
the files are consistent in a snapshot fails the cord-yank test (which
is
equivalent to the "processor explodes" test and the "power supply bursts
into flames" test and the "disk drive shatters" test and so forth). It
can't survive unavoidable physical-world events.
It can, if said software can roll back to the last consistent state.
That may or may not be "recent" wrt a snapshot. If an application is
very active, it's possible that many snapshots may be taken, none of
which are actually in a state the application can use to recover from.
Rendering snapshots much less effective.
Wait, if the application can in fact survive the "cord pull" test then by
definition of "survive", all the snapshots are useful.
Useful, yes, but you missed my point about recency. They may not be as
useful as they could be, and depending on how data changes older data or
transactions may be unrecoverable due to an inconsistent snapshot.
They'll be
everything consistent that was committed to disk by the time of the yank
(or snapshot); which, it seems to me, is the very best that anybody could
hope for.
This is true only if transactions are journaled somehow, and thus a snapshot
could return the application to it's current state -1.
Also, just administratively, and perhaps legally, it's highly desirable
to know that the time of a snapshot is the actual time that application
state can be recovered to or referenced to.
Maybe, but since that's not achievable for your core corporate asset (the
database), I think of it as a pipe dream rather than a goal.
Ah, because we can't achieve this ideal for some very critical application,
we shouldn't bother getting there for other applications.
Also, if an application cannot survive a cord-yank test, it might be
even more highly desirable that snapshots be a stable that from which
the application can be restarted.
If it cannot survive a cord-yank test, it should not be run, ever, by
anybody, for any purpose more important than playing a game.
Nice ideal world you live in ... wish I were there.
It's not as if a notification mechanism somehow makes things worse for
applications that don't use it.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
