On Sun, Oct 08, 2006 at 03:38:54PM -0700, Erik Trimble wrote:
> Joseph Mocker wrote:
> >Which brings me back to the point of file versioning. If an
> >implementation were based on something like when a file is open()ed
> >with write bits set. There would be no potential for broken files like
> >this.
> >
> >Also, it would seem that your statement about snapshots as being "what
> >is there at time X" in a nutshell, describes why snapshots are
> >different than file versioning. File versioning is not temporal in
> >the same way.
> >
> That is correct. File Versioning is primarily User-Driven (that is,
> executed and completed at the End-User's command), if you implement it
> using open() and close() as the drivers. (which, seems to be the
> consensus, is the sane way to do FV). So, in theory, FV should never
> result in any file Inconsistency or Corruption. Snapshots are
> essentially System-driven, and as such, about a Point-in-Time for the
> System, not a Point-in-State of an App, which FV centers on.
I don't agree entirely. For many apps heuristic FV boundaries will do.
There are apps for which it won't.
And we've not talked about files unlinked on rename. Should the new
file's FV history replace the old one's? Should the histories be
merged?
I think heuristic FV has its place, but it won't do in general.
> Snapshots and Backup definitely can result in Inconsistency, as the
> don't tend to communicate with the app holding a file open. Backups have
> mitigated this problem with certain apps which tend to hold files open
> for extended time (primarily DBs), by allowing the Backup program to
> talk to the app, and have the app write a consistent state to disk
> before the Backup program run.
Sortof. If you can quiesce the application then you can snapshot the FS
safely. Or if the application has any sort of recovery (journalling +
rollback, say), then you may be able to snapshot safely at any time.
Of course, if you have large filesystems dedicated to multiple apps
(e.g., home directories), then you typically can't quiesce all of those
apps.
> Snapshots are indeed a different beast than FV, in both subtle and
> not-so-subtle ways. They fit much more into the class of Backup.
> Honestly, I've thought that through this FV thread, we should never
> reference snapshots for functionality, as they really aren't comparable.
> Apples to Oranges and all.
More like giant oranges (snapshots) to mini-mandarins (FV).
I'm not saying that FV is a bad idea -- IMO it's a good idea. I'm
concerned about the interfaces. VMS-style in-your-face FV seems like a
bad idea to me, and only heuristic-driven FV does too. And then there's
semantics to iron out (e.g., unlinks on rename).
Things to work out:
- APIs for creating FV (magic EAs provide an easy answer)
- APIs for accessing FV (EAs provide an easy answer)
- UIs for acessing FV (EAs provide an easy answer)
- heuristics for automatic FV (open for write, atomic appends,
fsyncs, unlinks, ...)
- UIs for controlling automatic FV (ideas? FS properties come to
mind; EAs; LD_PRELOAD has been
mentioned)
- FV semantics in the face of POSIX
Nico
--
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
