#16145: Erlang R12B-3 needs a patch for fsync problem -------------------------------------+-------------------------------------- Reporter: jerry.jalava@gmail.com | Owner: bfulgham@macports.org Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.6.0 Resolution: | Keywords: -------------------------------------+-------------------------------------- Comment (by febeling@macports.org): It is a bit hard to tell because the errors you get are potentially dependent load and io patters of the OS kernel. I had problems in fairly simple test cases though, and those are indeed gone now. Just for the record, the whole problem is not something esoteric which only couchdb encounters, but it is simply the behavior of the function file:sync/1 from kernel. OTOH, one can't really speak of an erlang bug, because the documented behavior explicitly makes no guarantee: {{{ sync(IoDevice) -> ok | {error, Reason} Types: IoDevice = io_device() Reason = ext_posix() | terminated Makes sure that any buffers kept by the operating system (not by the Erlang runtime system) are written to disk. On some platforms, this function might have no effect. }}} But I don't see how you could program any serious disk persistence without this function. This is also the view held in the fsync man page from Apple. After the patch I used dtruss to watch syscalls while syncing a file from an erlang shell and this confirms, that we call fctnl now {{{ 79500/0x7f944f0: fcntl(0x7, 0x33, 0xFFFFFFFFB01A8BD8) = 0 0 }}} 0x33 or 51 is the value of F_FULLSYNC {{{ ./sys/fcntl.h:206:#define F_FULLFSYNC 51 /* fsync + ask the drive to flush to the media */ }}} And that was the intention of the patch. So I think this issue could be closed. -- Ticket URL: <http://trac.macports.org/ticket/16145#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS