> >> How you interpret "on every write" depends on where in the > stack you are > >> coming from. If you think about an application a > "write" is whey you > >> save the document but at the ZPL layer that is multiple > write(2) calls > >> and maybe even some rename(2)/unlink(2)/close(2) calls as well. > > That's one big problem with the naive plan of using snapshots. > > > > Another one is that snapshots are per-filesystem, while the > intention> here is to capture a document in one user session. > Taking a snapshot > > will of course say nothing about the state of other user > sessions. Any > > document in the process of being saved by another user, for example, > > will be corrupt. > > Would it be? I think that's pretty lame for ZFS to corrupt data. > If I > were to manually create a snapshot and two users were writing to > the FS, > how would ZFS handle that? Are you saying it would corrupt the > data? I > thought snapshots could be taken regardless of if there is activity.
Just as said above, ZFS write(2)'s some blocks to a file system. There may be many files open and used on this filesystem. The moment when one file is close()'d other files may remain open. Say at this moment you take a snapshot. This per se does not break stuff. It just places a cutoff line - blocks on disk are in the snapshot, unclosed files are not yet completed from its point of view, their new blocks will go into the live dataset and ultimately into next snapshot. And then you find that you need to roll back to this snapshot, or to clone it, or extract random files from its read-only view into the filesystem. Those files which were incomplete at the moment of snapshot - they would remain incomplete. If you try to use these half-files, most applications would agree that they are broken - just as if you pressed "reset" in the middle of a heavy write. Some programs such as databases can roll back incomplete writes and forget they were there - but the rest of their data in such incomplete files will become consistent. Thanks to ZFS COW, they will have available any blocks ever written to disk and referenced in this snapshot, so they can decide what and how to roll back according to their internal structures. For this reason many well-behaved backup tools for, say, databases, trigger a cache flush and read-only freeze for the database, then they make a snapshot and unfreeze the DB. After that the snapshot data may be sent to tape or a remote server, and it will be consistent on-disk if it ever needs to be rolled back to.
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
