> atomic view?
Your post was on the gory details on how ZFS writes. "Atomic View" here is,
that 'save' of a file is an 'atomic' operation: at one moment in time you click
'save', and some other moment in time it is done. It means indivisible, and
from the perspective of the user this is how it ought to look.
> The rub is this: how do you know when a file edit/modify has completed?
Not to me, I'm sorry, this is task of the engineer, the implementer. (See
'atomic', as above.)
It would be a shame if a file system never knew if the operation was completed.
> If an application has many files then an "edit/modify" may include
> updates and/or removals of more than one file. So once again: how do
> you know when an edit/modify has completed?
So an 'edit' fires off a few child processes to do this and that and then you
forget about them, hoping for them to do a proper job.
Oh, this gives me confidence ;)
No, seriously, let's look at some applications:
A. User works in Office (Star-Office, sure!) and clicks 'Save' for a current
work before making major modifications. So the last state of the document (odt)
is being stored. Currently we can set some Backup option to be done regularly.
Meaning that the backup could have happened at the very wrong moment; while
saving the state on each user request 'Save' is much better.
B. A bunch of e-mails are read from the Inbox and stored locally (think
Maildir). The user sees the sender, doesn't know her, and deletes all of them.
Of course, the deletion process will have fired up the CDP-engine ('event') and
retire the files instead of deletion. So when the sender calls, and the user
learns that he made a big mistake, he can roll back to before the deletion
(event).
C. (Sticking with /home/) I agree with you, that the rather continuous changes
of the dot-files and dot-directories in the users HOME that serve JDS, and many
more, do eventually not necessarily allow to reconstitute a valid state of the
settings at all and any moment. Still, chances are high, that they will. In the
worst case, the unlucky user can roll back to when he last took a break, if
only for grabbing another coffee, because it took a minute, the writes (see
above) will hopefully have completed. "oh, s***", already messed up the
settings? Then try to roll back to lunch break. Works? Okay! But when you roll
back to lunch break, where is the stuff done in between? The backup solution
means that they are lost. The event-driven (CDP) not: you can roll over all the
states of files or directories between lunch break and recover the third latest
version of your tendering document (see above), within the settings of the
desktop that were valid this morning.
Maybe SUN can't do this, but wait for Apple, and OSX10-dot-something (using ZFS
as default!) will know how to do it. (And they probably also know, when their
'writes' are done.)
Uwe
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
