Peter Schuller <peter.schul...@infidyne.com> wrote:
> > 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()).
In addition, POSIX does not mention that close() needs to sync the file to
disk. If an application like star likes to verify whether files could be
written to disk in order to create a correct exit code, the only way is to call
fsync() before close().
With UFS, this creates an performance impact of aprox. 10%, with ZFS this
was more than 10% the last time I checked.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.schill...@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
