| |||||||||||||
Another new ABI for fanotifyAnother new ABI for fanotifyPosted Nov 12, 2009 16:06 UTC (Thu) by xav (guest, #18536)Parent article: Another new ABI for fanotify
How fun ... here we have two consecutive articles, one dealing with making several file operations a transaction, the other trying to break down open() into two distinct operations (call userspace to check if I can open(), then open() for real).
I hardly see how both these approches can coexist ...
(Log in to post comments)
Another new ABI for fanotify Posted Nov 13, 2009 2:41 UTC (Fri) by bronson (subscriber, #4806) [Link]
Why? Btrfs is dealing with bits on the platter, fanotify hooks in at the VFS. There's very little logical or conceptual overlap.
Another new ABI for fanotify Posted Nov 13, 2009 10:13 UTC (Fri) by xav (guest, #18536) [Link]
There's not much overlap, but I wonder how you can implement a transaction containing one or more open() if these operations can block, call userspace and eventually abort.
Another new ABI for fanotify Posted Dec 20, 2009 17:01 UTC (Sun) by Blaisorblade (guest, #25465) [Link]
> There's not much overlap, but I wonder how you can implement a transaction containing one or more open() if these operations can block, call userspace and eventually abort.
Transactions have been invented in databases, and in that context it's obvious that part of a transaction may fail; and even in btrfs transactions allow for failures. So, what's the problem here? A bigger problem is instead that during the transaction the filesystem is locked, so userspace needs to avoid modifying the fs during the check, if btrfs is used. It's possible I guess, the atime change problem needs to be solved to perform reads, but that's doable. But if developers don't test this scenario, they won't notice.
|
|||||||||||||