DragonFly users List (threaded) for 2008-08
DragonFly BSD
DragonFly users List (threaded) for 2008-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Hammer: Transactional file updates

From: "Dmitri Nikulin" <dnikulin@xxxxxxxxx>
Date: Wed, 20 Aug 2008 11:39:36 +1000

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

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]