* A possible flaw in the fsnotify design. @ 2010-11-15 22:05 Alexey Zaytsev 2010-11-15 22:11 ` Eric Paris 0 siblings, 1 reply; 7+ messages in thread From: Alexey Zaytsev @ 2010-11-15 22:05 UTC (permalink / raw) To: Eric Paris Cc: Tvrtko Ursulin, linux-fsdevel, stefan@buettcher.org, linux-kernel, Al Viro Just some thoughts. Consider the situation: Files A and B both point to the same inode. File A is being watched, but the user won't get notifications if B is modified. This might be a problem for indexers, or, in my case, backup programs. Even if the user is watching the mont point, he still needs to get all the possible links to the modified file, and in my understanding, there is no way to do this without scanning the whole filesystem. I've got no idea how to fix the problem yet, or if it would be possible to fix at all. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible flaw in the fsnotify design. 2010-11-15 22:05 A possible flaw in the fsnotify design Alexey Zaytsev @ 2010-11-15 22:11 ` Eric Paris 2010-11-15 22:44 ` Alexey Zaytsev 0 siblings, 1 reply; 7+ messages in thread From: Eric Paris @ 2010-11-15 22:11 UTC (permalink / raw) To: Alexey Zaytsev Cc: Tvrtko Ursulin, linux-fsdevel, stefan@buettcher.org, linux-kernel, Al Viro On Tue, 2010-11-16 at 01:05 +0300, Alexey Zaytsev wrote: > Just some thoughts. > > Consider the situation: Files A and B both point to the same inode. > File A is being watched, but the user won't get notifications if B is > modified. That's not true. Users watch inodes, not files (this is true for both inotify and fanotify). Give it a try, it works. -Eric ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible flaw in the fsnotify design. 2010-11-15 22:11 ` Eric Paris @ 2010-11-15 22:44 ` Alexey Zaytsev 2010-11-15 22:51 ` Eric Paris 0 siblings, 1 reply; 7+ messages in thread From: Alexey Zaytsev @ 2010-11-15 22:44 UTC (permalink / raw) To: Eric Paris Cc: Tvrtko Ursulin, linux-fsdevel, stefan@buettcher.org, linux-kernel, Al Viro On Tue, Nov 16, 2010 at 01:11, Eric Paris <eparis@redhat.com> wrote: > On Tue, 2010-11-16 at 01:05 +0300, Alexey Zaytsev wrote: >> Just some thoughts. >> >> Consider the situation: Files A and B both point to the same inode. >> File A is being watched, but the user won't get notifications if B is >> modified. > > That's not true. Users watch inodes, not files (this is true for both > inotify and fanotify). Give it a try, it works. > debian-i386:~/tmp# touch a debian-i386:~/tmp# ../fanotify a & debian-i386:~/tmp# link a b debian-i386:~/tmp# ls -li total 0 3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 a 3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 b debian-i386:~/tmp# echo 123 > b /root/tmp/b: pid=2143 mask = 20 open /root/tmp/b: pid=2143 mask = a modify 0 - 4 close(writable) 0 - 4 Am I doing something wrong? Same thing happens if I watch the mount point. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible flaw in the fsnotify design. 2010-11-15 22:44 ` Alexey Zaytsev @ 2010-11-15 22:51 ` Eric Paris 2010-11-15 23:03 ` Alexey Zaytsev 0 siblings, 1 reply; 7+ messages in thread From: Eric Paris @ 2010-11-15 22:51 UTC (permalink / raw) To: Alexey Zaytsev Cc: Tvrtko Ursulin, linux-fsdevel, stefan@buettcher.org, linux-kernel, Al Viro On Tue, 2010-11-16 at 01:44 +0300, Alexey Zaytsev wrote: > On Tue, Nov 16, 2010 at 01:11, Eric Paris <eparis@redhat.com> wrote: > > On Tue, 2010-11-16 at 01:05 +0300, Alexey Zaytsev wrote: > >> Just some thoughts. > >> > >> Consider the situation: Files A and B both point to the same inode. > >> File A is being watched, but the user won't get notifications if B is > >> modified. > > > > That's not true. Users watch inodes, not files (this is true for both > > inotify and fanotify). Give it a try, it works. > > > > debian-i386:~/tmp# touch a > debian-i386:~/tmp# ../fanotify a & > debian-i386:~/tmp# link a b > debian-i386:~/tmp# ls -li > total 0 > 3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 a > 3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 b > debian-i386:~/tmp# echo 123 > b > /root/tmp/b: pid=2143 mask = 20 open > /root/tmp/b: pid=2143 mask = a modify 0 - 4 close(writable) 0 - 4 > > Am I doing something wrong? Same thing happens if I watch the mount point. Maybe I don't understand the problem, you watched the inode behind A. You made changes accessing this inode via B, you got notification about those changes. Isn't that what you wanted? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible flaw in the fsnotify design. 2010-11-15 22:51 ` Eric Paris @ 2010-11-15 23:03 ` Alexey Zaytsev 2010-11-15 23:12 ` Eric Paris 0 siblings, 1 reply; 7+ messages in thread From: Alexey Zaytsev @ 2010-11-15 23:03 UTC (permalink / raw) To: Eric Paris Cc: Tvrtko Ursulin, linux-fsdevel, stefan@buettcher.org, linux-kernel, Al Viro On Tue, Nov 16, 2010 at 01:51, Eric Paris <eparis@redhat.com> wrote: > On Tue, 2010-11-16 at 01:44 +0300, Alexey Zaytsev wrote: >> On Tue, Nov 16, 2010 at 01:11, Eric Paris <eparis@redhat.com> wrote: >> > On Tue, 2010-11-16 at 01:05 +0300, Alexey Zaytsev wrote: >> >> Just some thoughts. >> >> >> >> Consider the situation: Files A and B both point to the same inode. >> >> File A is being watched, but the user won't get notifications if B is >> >> modified. >> > >> > That's not true. Users watch inodes, not files (this is true for both >> > inotify and fanotify). Give it a try, it works. >> > >> >> debian-i386:~/tmp# touch a >> debian-i386:~/tmp# ../fanotify a & >> debian-i386:~/tmp# link a b >> debian-i386:~/tmp# ls -li >> total 0 >> 3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 a >> 3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 b >> debian-i386:~/tmp# echo 123 > b >> /root/tmp/b: pid=2143 mask = 20 open >> /root/tmp/b: pid=2143 mask = a modify 0 - 4 close(writable) 0 - 4 >> >> Am I doing something wrong? Same thing happens if I watch the mount point. > > Maybe I don't understand the problem, you watched the inode behind A. > You made changes accessing this inode via B, you got notification about > those changes. Isn't that what you wanted? I'd expect to get two notifications in this case. Might not be a problem when you are watching individual files, but there is no clear way to get all the modified files, if you are watching a mount point. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible flaw in the fsnotify design. 2010-11-15 23:03 ` Alexey Zaytsev @ 2010-11-15 23:12 ` Eric Paris 2010-11-15 23:15 ` Alexey Zaytsev 0 siblings, 1 reply; 7+ messages in thread From: Eric Paris @ 2010-11-15 23:12 UTC (permalink / raw) To: Alexey Zaytsev Cc: Tvrtko Ursulin, linux-fsdevel, stefan@buettcher.org, linux-kernel, Al Viro, agruen On Tue, 2010-11-16 at 02:03 +0300, Alexey Zaytsev wrote: > On Tue, Nov 16, 2010 at 01:51, Eric Paris <eparis@redhat.com> wrote: > > On Tue, 2010-11-16 at 01:44 +0300, Alexey Zaytsev wrote: > >> On Tue, Nov 16, 2010 at 01:11, Eric Paris <eparis@redhat.com> wrote: > >> > On Tue, 2010-11-16 at 01:05 +0300, Alexey Zaytsev wrote: > >> >> Just some thoughts. > >> >> > >> >> Consider the situation: Files A and B both point to the same inode. > >> >> File A is being watched, but the user won't get notifications if B is > >> >> modified. > >> > > >> > That's not true. Users watch inodes, not files (this is true for both > >> > inotify and fanotify). Give it a try, it works. > >> > > >> > >> debian-i386:~/tmp# touch a > >> debian-i386:~/tmp# ../fanotify a & > >> debian-i386:~/tmp# link a b > >> debian-i386:~/tmp# ls -li > >> total 0 > >> 3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 a > >> 3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 b > >> debian-i386:~/tmp# echo 123 > b > >> /root/tmp/b: pid=2143 mask = 20 open > >> /root/tmp/b: pid=2143 mask = a modify 0 - 4 close(writable) 0 - 4 > >> > >> Am I doing something wrong? Same thing happens if I watch the mount point. > > > > Maybe I don't understand the problem, you watched the inode behind A. > > You made changes accessing this inode via B, you got notification about > > those changes. Isn't that what you wanted? > > I'd expect to get two notifications in this case. Might not be a > problem when you are watching individual files, but there is no clear > way to get all the modified files, if you are watching a mount point. Ah, you were hoping for 4 events. Yeah, not possible. You get notified when the inode changes, which way you get notified is up to the kernel and we leave it as an (impossible) exercise to userspace to map hard linked inodes back together :) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible flaw in the fsnotify design. 2010-11-15 23:12 ` Eric Paris @ 2010-11-15 23:15 ` Alexey Zaytsev 0 siblings, 0 replies; 7+ messages in thread From: Alexey Zaytsev @ 2010-11-15 23:15 UTC (permalink / raw) To: Eric Paris Cc: Tvrtko Ursulin, linux-fsdevel, stefan@buettcher.org, linux-kernel, Al Viro, agruen On Tue, Nov 16, 2010 at 02:12, Eric Paris <eparis@redhat.com> wrote: > On Tue, 2010-11-16 at 02:03 +0300, Alexey Zaytsev wrote: >> On Tue, Nov 16, 2010 at 01:51, Eric Paris <eparis@redhat.com> wrote: >> > On Tue, 2010-11-16 at 01:44 +0300, Alexey Zaytsev wrote: >> >> On Tue, Nov 16, 2010 at 01:11, Eric Paris <eparis@redhat.com> wrote: >> >> > On Tue, 2010-11-16 at 01:05 +0300, Alexey Zaytsev wrote: >> >> >> Just some thoughts. >> >> >> >> >> >> Consider the situation: Files A and B both point to the same inode. >> >> >> File A is being watched, but the user won't get notifications if B is >> >> >> modified. >> >> > >> >> > That's not true. Users watch inodes, not files (this is true for both >> >> > inotify and fanotify). Give it a try, it works. >> >> > >> >> >> >> debian-i386:~/tmp# touch a >> >> debian-i386:~/tmp# ../fanotify a & >> >> debian-i386:~/tmp# link a b >> >> debian-i386:~/tmp# ls -li >> >> total 0 >> >> 3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 a >> >> 3433 -rw-r--r-- 2 root root 0 Nov 15 22:37 b >> >> debian-i386:~/tmp# echo 123 > b >> >> /root/tmp/b: pid=2143 mask = 20 open >> >> /root/tmp/b: pid=2143 mask = a modify 0 - 4 close(writable) 0 - 4 >> >> >> >> Am I doing something wrong? Same thing happens if I watch the mount point. >> > >> > Maybe I don't understand the problem, you watched the inode behind A. >> > You made changes accessing this inode via B, you got notification about >> > those changes. Isn't that what you wanted? >> >> I'd expect to get two notifications in this case. Might not be a >> problem when you are watching individual files, but there is no clear >> way to get all the modified files, if you are watching a mount point. > > Ah, you were hoping for 4 events. Yeah, not possible. You get notified > when the inode changes, which way you get notified is up to the kernel > and we leave it as an (impossible) exercise to userspace to map hard > linked inodes back together :) > Yeah, I see now, it's impossible to get all the files linking to an inode even from the kernel space without scanning the fs. Thanks for the clarification. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-11-15 23:15 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-11-15 22:05 A possible flaw in the fsnotify design Alexey Zaytsev 2010-11-15 22:11 ` Eric Paris 2010-11-15 22:44 ` Alexey Zaytsev 2010-11-15 22:51 ` Eric Paris 2010-11-15 23:03 ` Alexey Zaytsev 2010-11-15 23:12 ` Eric Paris 2010-11-15 23:15 ` Alexey Zaytsev
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).