Why not? Some of the issues should be easy to avoid in kernel space.
> For example: how does moving the overwrite into the kernel make it any easier to decide whether we should break hard links or not?
What does the non-atomic case do? I'd do the same in the atomic case.
> IOWs, the issue here is that nobody has defined what the operations being asked for are supposed to do, the use cases, the expected behaviour, constraints, etc.
My request was quite clear: Could any of the fsync advocates post real code that does the atomic variant of open, write, close?
Isn't that quite well-defined?
> Before asking kernel developers to do something the problem space needs to be scoped and specified
Before that, we should agree that these are valid issues / assumptions / regressions.
> But what really needs to happen first is that someone asking for this new kernel functionality steps up and takes responsibility for driving this process.....
That'd be great, but at the moment most (FS) devs (and others) just declare these non-issues and refuse to discuss.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds