Hammer: Transactional file updates

[Dmitri Nikulin]

On Wed, Aug 20, 2008 at 9:26 AM, Dmitri Nikulin <dnikulin at gmail.com> wrote:
> On Tue, Aug 19, 2008 at 2:14 AM, Joerg Sonnenberger
> <joerg at britannica.bec.de> 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