> fsync() is, indeed, expensive. Lots of calls to fsync() that are not > necessary for correct application operation EXCEPT as a workaround for > lame filesystem re-ordering are a sure way to kill performance.
IMO the fundamental problem is that the only way to achieve a write barrier is fsync() (disregarding direct I/O etc). Again I would just like an fbarrier() as I've mentioned on the list previously. It seems to me that if this were just adopted by some operating systems and applications could start using it, things would just sort itself out when file systems/block devices layers start actually implementing the optimization possible (instead of the native fbarrier() -> fsync()). As was noted previously in the previous thread on this topic, ZFS effectively has an implicit fbarrier() in between each write. Imagine now if all the applications out there were automatically massively faster on ZFS... but this won't happen until operating systems start exposing the necessary interface. What does one need to do to get something happening here? Other than whine on mailing lists... -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schul...@infidyne.com>' Key retrieval: Send an E-Mail to getpgp...@scode.org E-Mail: peter.schul...@infidyne.com Web: http://www.scode.org
pgpZpZZfcWwR3.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
