On Tue, Feb 26, 2008 at 06:34:04PM -0800, Uwe Dippel wrote:
> > 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.
The filesystem knows if a filesystem operation completed. It can't know
application state. You keep missing that.
> > 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 ;)
You'd rather the filesystem guess application state than have the app
tell it? Weird. Your other alternative -- saving a history of every
write -- doesn't work because you can't tell what point in time is safe
to restore to.
> 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.
So modify the office suite to call a new syscall that says "I'm
internally consistent in all these files" and boom, the filesystem can
now take a useful snapshot.
> 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).
Now think of an application like this but which uses, say, SQLite (e.g.,
Firefox 3.x, Thunderbird, ...). The app might never close the database
file, just fsync() once in a while. The DB might have multiple files
(in the SQLite case that might be multiple DBs ATTACHed into one
"database connection"). Also, an fsync of a SQLite journal file is not
as useful to CDP as an fsync() of a SQLite DB proper. Now add any of a
large number of databases and apps to the mix and forget it -- the
heuristics become impossible or mostly useless.
> 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
"Chances"? So what, we tell the user try restoring to this snapshot,
login again and if stuff doesn't work, then try another snapshot? What
if the user discovers too late that the selected snapshot was
inconsistent and by then they've made other changes?
> 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
That sounds mighty painful.
I'd rather modify some high-profile apps to tell the filesystem that
their state is consistent, so take a snapshot.
> 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'm giving you the best answer -- modify the apps -- and you reject it.
Given how many important apps Apple controls it wouldn't surprise me if
they did what I suggest. We should do it too. But one step at a time.
We need to setup a project, gather requirements, design a solution, ...
And since the solution will almost certainly entail modifications to
apps where heuristics won't help, well, I think this would be a project
with fairly wide scope, which means it likely won't go fast.
Nico
--
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
