On Wed, Aug 20, 2008 at 9:26 AM, Dmitri Nikulin <[EMAIL PROTECTED]> wrote: > On Tue, Aug 19, 2008 at 2:14 AM, Joerg Sonnenberger > <[EMAIL PROTECTED]> wrote: >> On Sun, Aug 17, 2008 at 08:40:20PM +1000, Dmitri Nikulin wrote: >>> I personally believe that Unix should have had a transactional file IO >>> API from the start, so that all modern file systems would implement it >>> and atomicity would be the standard, not a rare feature. >> >> I am not exactly sure what you mean with "atomicity", but can you >> demonstrate even *one* filesystem where writes of two processes are >> atomic relative to each other? I don't know any. > > The COW approach in ZFS appears to do exactly that. The block pointer > is not updated to the new copy of the block until it's finished > writing, so one process can write and the other won't read the new > block until the write completes and therefore the block pointer is > updated. That's regardless of whether or not the change has been > finalised on-disk.
Just to clear up, yes, this is just at the block level as far as I know, but if your application is actually relying on specific atomicity semantics then you should be using range locking in the first place. However if there was a transactional API from the beginning we wouldn't need to roll our own per-application. It's too late to complain about that now, but maybe it can find its way into a future standard. -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia