Are you indicating that the filesystem know's or should know what an
application is doing??
It seems to me that to achieve what you are suggesting, that's exactly
what it would take.
Or, you are assuming that there are no co-dependent files in
applications that are out there...
Whichever the case, I'm confused...!
Unless you are perhaps suggesting perhaps an IOCTL that an application
could call to indicate "I'm done for this round, please snapshot" or
something to that effect. Even then, I'm still confused as to how I
would do anything much useful with this over and above, say, 1 minute
snapshots.
Nathan.
Uwe Dippel wrote:
>> 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
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
