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.
>
>
This is the consistency problem. It isn't enough to know a write()
completed, you must also know that a group of write()s leaves the
file in a state which is consistent for the application.
>> 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.
>
StarOffice can record changes. So you should never lose a change, no?
Other editors and office suites have similar features. Some editors even
keep backup copies of modified documents.
> 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).
>
SOX compliance? ;-)
> 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.
>
>
Actually, there is case where you wouldn't want this
enabled for $HOME, in general. I use a browser every
day. Actually I use several browsers every day. Each
browser has a cache located somewhere in my home
directory and the cache is managed so that it won't
grow very large. With CDP, I would fill my disk in
a week or less, just by caching everything on the
internet that I pass by.
Similarly, I have an e-mail account that is pop-based
and tends to collect large amounts of spam, which due
to some irritating circumstances, I can't remotely filter.
I *really* don't want to fill up my disk with enlargement
spam. The only thing that would get larger is my disk
space requirement :-)
> 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.)
>
I use firefox and thunderbird on my mac... so I guess I
would fill up my disk with the internet and spam ;-/
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
