> > 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. > > Zfs writes data in transaction groups and each bunch of data which > gets written is bounded by a transaction group. The current state of > the data at the time the TXG starts will be the state of the data once > the TXG completes. If the system spontaneously reboots then it will > restart at the last completed TXG so any residual writes which might > have occured while a TXG write was in progress will be discarded. > Based on this, I think that your ordering concerns (sync writes > getting to disk "faster" than async writes) are unfounded for normal > file I/O.
So you're saying that while the OS is building txg's to write to disk, the OS will never reorder the sequence in which individual write operations get ordered into the txg's. That is, an application performing a small sync write, followed by a large async write, will never have the second operation flushed to disk before the first. Can you support this belief in any way? If that's true, if there's no increased risk of data corruption, then why doesn't everybody just disable their ZIL all the time on every system? The reason to have a sync() function in C/C++ is so you can ensure data is written to disk before you move on. It's a blocking call, that doesn't return until the sync is completed. The only reason you would ever do this is if order matters. If you cannot allow the next command to begin until after the previous one was completed. Such is the situation with databases and sometimes virtual machines. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss