> This approach does not solve the problem. When you do a snapshot, > the txg is committed. If you wish to reduce the exposure to loss of > sync data and run with ZIL disabled, then you can change the txg commit > interval -- however changing the txg commit interval will not eliminate > the > possibility of data loss.
The default commit interval is what, 30 seconds? Doesn't that guarantee that any snapshot taken more than 30 seconds ago will have been fully committed to disk? Therefore, any snapshot older than 30 seconds old is guaranteed to be consistent on disk. While anything less than 30 seconds old could possibly have some later writes committed to disk before some older writes from a few seconds before. If I'm wrong about this, please explain. I am envisioning a database, which issues a small sync write, followed by a larger async write. Since the sync write is small, the OS would prefer to defer the write and aggregate into a larger block. So the possibility of the later async write being committed to disk before the older sync write is a real risk. The end result would be inconsistency in my database file. If you rollback to a snapshot that's at least 30 seconds old, then all the writes for that snapshot are guaranteed to be committed to disk already, and in the right order. You're acknowledging the loss of some known time worth of data. But you're gaining a guarantee of internal file consistency. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
