>> 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?
When a system boots and it finds the snapshot, then all the data referred by the snapshot are on-disk. But the snapshot doesn't guarantee more than the last valid uberblock. >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. When a pointer to data is committed to disk by ZFS, then the data is also on disk. (if the pointer is reachable from the uberblock, then the data is also on dissk and reachable from the uberblock) You don't need to wait 30 seconds. If it's there, it's there. >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. I don't know what ZFS guarantees when you disable the zil; the one broken promise is that when fsync() returns, that the data may not have committed to stable storage when fsync() returns. I'm not sure whether there is a "barrier" when there is a "sync()/fsync()", if that is the case, then ZFS is still safe for your application. Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
