Anantha N. Srirama wrote On 01/17/07 08:32,:
Bug 6413510 is the root cause. ZFS maestros please correct me if I'm quoting an incorrect bug.
Yes, Anantha is correct that is the bug id, which could be responsible for more disk writes than expected. Let me try to explain that bug. The ZIL as described in http://blogs.sun.com/perrin collects transactions in memory of all system calls until they are committed in a transaction group (txg) at the pool level. If a request arrives to force to stable stoarge a particular file (fsync or O_DSYNC) then the ZIL used to write out all in memory transactions for the file system. This meant transactions unrelated to that file were written including directory creations, renames etc - which might be important in being able to re-create the file. However, it also pushed out user data for other files, which can be voluminous. The problem was originally seen when a ksh history file was fsync-ed during a large data write. It would take many seconds to flush the large write through the log, just to ensure a "pwd" command typed was safely on disk! This inefficiency occurs only when a "mismatch" of applications use the same file system. The fix was essentially to push out all meta data for the file system but only the file data related to the file being fsync-ed or O_DSYC-ed. This problem was fixed in snv_48 last September and will be in S10_U4. Neil. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
