On Wed, 11 Feb 2009, David Dyer-Bennet wrote:
As a practical matter, it seems unreasonable to me that there would be uncommitted data in the pool after some quite short period of time when there's no new IO activity to the pool (not just the filesystem). 5 or 10 seconds, maybe? (Possibly excepting if there was a HUGE spike of IO for a while just before this; there could be considerable stuff in the ZIL not yet committed then, I would think.)
I agree. ZFS apparently syncs uncommitted writes every 5 seconds. If there has been no filesystem I/O (including read I/O due to atime) for at least 10 seconds, and there has not been more data burst-written into RAM than can be written to disk in 10 seconds, then there should be nothing remaining to write.
Regardless, it seems that the ZFS problems with crummy hardware are primarily due to the crummy hardware writting the data to the disk in a different order than expected. ZFS expects that after a sync that all pending writes are committed.
The lesson is that unprofessional hardware may prove to be unreliable for professional usage.
Bob ====================================== Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
