> > Given ZFS's copy-on-write transactional model, would it not be almost trivial > to implement fbarrier()? Basically just choose to wrap up the transaction at > the point of fbarrier() and that's it. > > Am I missing something?
How do you guarantee that the disk driver and/or the disk firmware doesn't reorder writes ? The only guarantee for in-order writes, on actual storage level, is to complete the outstanding ones before issuing new ones. Or am _I_ now missing something :) FrankH. As Jeff said, ZFS guarantees the write(2) are ordered by the fact that either they show up in the order supplied or they don't at all. So as the transaction closes, we can issue all the I/Os we want in whatever order we choose (more or less), then flush the caches. Up to here none of the I/O would actually be visible upon a reboot. But then, we update the ueberblock, flush the cache and we're done. All writes that associated with a transaction group show up at once in the main tree. -r _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
