Re: Hammer: Transactional file updates

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:On Tue, Aug 19, 2008 at 07:00:23PM -0700, Matthew Dillon wrote:
:>     * Unix in general does not guarantee atomicy between mmap-read or
:>       mmap-written blocks and read() or write() ops.  This is because
:>       it has no way to know what the user program actualy wants when,
:>       since all memory accesses are page-based.
:
:Unix in practise *does* guarantee this. The only exception of an
:Operating System still in use is OpenBSD. It is non-trivial to do, e.g.
:in NetBSD it was done with the switch to the Unified Buffer Cache,
:FreeBSD did as you very likely know did it by changes to the Buffer
:Cache etc. Otherwise I agree.
:
:Joerg

    That's just cache coherency.  That isn't atomicy.  If program #1
    bcopy()'s data into a mmap'd space that operation is not guaranteed
    to be atomic against program #2 read() ing the same chunk of data.
    There is no interlock between the two operations so the read() might
    see the written data half way through the copy.

    Similarly if a program is modifying data via mmap() it has no way to
    control when the OS syncs that data to disk, or what the OS syncs to
    disk.  So the program might be modifying data within even a single
    page and the OS might sync it to disk half way through the copy.

    Or you might be doing a forward copy that crosses a page boundary
    and the OS might decide to flush the second page first, and the first
    page second.

    Then if your system crashes you get inconsistent data.  For all intents
    and purposes the operation is not atomic.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>