On Sat, Aug 2, 2008 at 7:47 AM, Michael Neumann <[EMAIL PROTECTED]> wrote: > That's not what I want. fsync only guarantees that the data is stored > permanently. That's not my problem. I want to ensure that some > write-operations are performed either-all-or-nothing.
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. Because right now, even if a couple of file systems supported it, nobody would use it because it's non-portable and the semantics aren't standardised. Aatomic IO is pretty heavyweight compared to just streaming bytes onto a block device. However, most new file systems are implementing it one way or another, via journalling or COW or whatever, so obviously it's a tradeoff we're willing to make. Having a proper standard API to harness that potential would be a great advancement for Unix. The same problem applies here... even if HAMMER had such an API and it worked perfectly, relying on that API would forever tie your implementation to HAMMER. If you decided to support UFS, ext3, ZFS, etc. for storage, you'd have to write a custom transactional format anyway, which becomes redundant when running on HAMMER. You'd have to wait until an API becomes standard on at least the platforms you intend to support. -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia
