User: Password:
|
|
Subscribe / Log in / New account

How disappointing

How disappointing

Posted Sep 11, 2011 16:00 UTC (Sun) by sionescu (subscriber, #59410)
In reply to: How disappointing by butlerm
Parent article: Ensuring data reaches disk

No, it's the common way of implementing atomic commit when *modifying* the data, but it's not what I have in mind, which is this:

open(path, O_REPLACE) only allocates a new inode

close(fd, CLOSE_COMMIT) atomically replaces the reference to the old inode with the new inode(just like rename) copying all metadata except for the (a|c|m)time, then calls fsync()

easy, isn't it ?


(Log in to post comments)

How disappointing

Posted Sep 11, 2011 20:45 UTC (Sun) by nix (subscriber, #2304) [Link]

Sure. Practicalities: you could do it to open() (though you'd have to get the change into POSIX before Ulrich would let it past), but you could never do that to close() without breaking every C program ever written. You could call it close_replace(), perhaps?

How disappointing

Posted Sep 11, 2011 21:10 UTC (Sun) by sionescu (subscriber, #59410) [Link]

Why POSIX ? There are other Linux-specific open flags, did Ulrich object to every one of them ?

The new syscall could be called close2, adding a "flags" parameter - in the spirit of accept4() et al.

How disappointing

Posted Sep 11, 2011 21:52 UTC (Sun) by nix (subscriber, #2304) [Link]

True, though close2() is a horrible name (as is wait$num() and accept$num()): give it a name that reflects its purpose.

How disappointing

Posted Sep 11, 2011 22:14 UTC (Sun) by sionescu (subscriber, #59410) [Link]

How about "close_with_flags" ?

How disappointing

Posted Sep 11, 2011 23:51 UTC (Sun) by nix (subscriber, #2304) [Link]

Again, ugh ('with'?). I'd simply say close_replace(), no need for a flag or indeed any parameters at all. This means it has the same prototype as close(), so if anyone wants to choose between calling close() or close_replace() at runtime, they can just use a function pointer.

How disappointing

Posted Sep 23, 2011 0:59 UTC (Fri) by spitzak (guest, #4593) [Link]

If it is opened with the atomic-replace semantic, I would just have plain close() do the replacement.

There may be a need to somehow "abort" the file so that it is as though you never started writing it. But it may be sufficient to do this if the process owning the fd exits without calling close().

I very much disagree with others that say POSIX should be followed. The suggested method of writing a file is what is wanted in probably 95% of the time that files are written. It should be the basic operation, while "dynamic other processes can see the blocks change as I write them" is an extremely rare operation that should be the one requiring complex hacks.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds