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.
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.
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.
-Erik
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
