On Thu, Feb 28, 2008 at 04:05:50AM -0800, Uwe Dippel wrote: > Again, there's nothing that I "wanted". I was only thinking. And I am > a server person. Now, if I switch from the > /export/home/userfoo/Documents (for Richard, who might be happier with > UZFS-CDP than with the shots of TimeMachine), to a file server, do the > arguments still hold, that > 1. The application (NFS - sftp) does not know about the state of > writing?
The application isn't NFS -- the application is whatever is running on the client. And yes, if we add syscalls by which apps can mark their fs transactions as such, then we'll need a similar extension to NFSv4. > 2. Obviously nobody sees anything in having access to all versions of > a file stored there? Why obviously? Once you have versioned files/CDP/whatever and expose APIs by which to create and access these things, then why shouldn't apps use this much like RCS, SCCS, ...? One possible answer: because CDP snapshots may be subject to automatic deletion when space is running low, whereas traditional version control systems aren't. > [...] > reason (see Subject): to confirm if ZFS can be instructed to produce a > copy of each version of a file, initiated by some event instead of a > scheduler. You can write a program that uses the OpenSolaris / Solaris Nevada user-land file event notification API to locally monitor files and make copies, take snapshots, whatever. But this is not provided on the system, and it will be a lot coarser than you like (e.g., you won't be able to distinguish dirty pages naturally being written to disk from calls to close(2) or fsync(2). > Somewhat to my surprise, my presentation was a good success, and Q&A > was focused on the event-driven backups, what the technical problems > were, etc. A good handful of people approached me later, being curious > and fascinated by the idea to replace the backup scheduler with an > event-driven creation of the versions. > > Therefore, to me the case is closed; my presentation done, on the > successful side. Well, it hasn't been successful yet; once implementations appear that are actually useful, then it will have been successful. Although, in so far as you got people talking about high-level design issues then is has been a success, even if you don't like the content of those discussions. To begin with, we (you) could certainly do a prototype that isn't necessarily generally useful as anything other than a proof of concept. You could begin with something like what is described above and which matches your vision. Then you could add some library of fs transaction marking APIs and modify some sample apps. Compare the results. In both cases you must try popular, complex apps and must attempt to restore from CDP backups. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
