3 ms·
Specifically (to hopefully clarify your point), the operation we wish to be atomic is 'replacing the mapping path A->data X with path A->data Y'. This is hoped
by rcxdude 3y ago
Specifically (to hopefully clarify your point), the operation we wish to be atomic is 'replacing the mapping path A->data X with path A->data Y'. This is hoped to be done by placing data Y in path B (which does not need to be atomic )and then using the atomicity of the rename to move around the path. This then puts an ordering constraint that any observer (whether after a crash and looking at the written filesystem, or during the normal operation of the system) sees data Y going into path B before the rename B to A, and this is what POSIX does not guarantee.
- throwaway09223 3y agoYeah, I get it. The issue is that filesystems don't work like you've assumed. I outlined why this idea cannot work here: https://news.ycombinator.com/item?id=38407472 https://news.ycombinator.com/item?id=38407472 Again, manipulating links has nothing to do with file data.
- rcxdude 3y agoIt blatently can work, it's just not guaranteed by the standard (at least without an fsync). I don't think anyone is talking about situations where B is being actively written to while the rename happens.
- throwaway09223 3y agoThis is like saying sync() works. You can sync to durable storage at any point, yes. But you cannot do it in a semantically useful fashion. "I don't think anyone is talking about situations where B is being actively written to while the rename happens." Well, you specifically are ignoring this. I'm not. Filesystems are free to generate extra syncs whenever they like. You could even have a filesystem sync every single write operation to durable storage - why not?