From: Goswin v. B. <gos...@we...> - 2010-03-07 19:04:19
|
Alberto Miranda <alb...@bs...> writes: > Hi, > > I haven't done any work on inotify for our filesystem, so I don't really > know if it is supported or not.As far as I know, FUSE doesn't provide a > callback for inotify, therefore forwarding it is out of the question as > of now. But since inotify works through a file descriptor interface, I > think it might work out of the box on a FUSE filesystem, although it > wouldn't detect changes to the underlying filesystem, but changes to the > FUSE filesystem. I really don't know because I haven't tested it. > > The problem with poll()/select() calls (I don't know about the inotify > API) is that you can have an infinite timeout when polling fds, > therefore, directly calling poll()/select() from the fuse_poll() > callback could end up locking all fuse threads, thus deadlocking the > filesystem. There must be another way to forward this type of calls, and > I believe the fuse_notify_poll() function is used to avoid this kind of > locking, but I haven't found enough clues in the source yet so as to > confirm my theory or not. What you do is store the FD to poll/select and in the main loop you poll/select the list of stored FDs + the fuse FD. That way activity on either the file you wait for or fuse will wake you up. I do this with libaio, which gives me an event FD. When a read/write request comes in I start the libaio request and go back to sleep. Then either libaio wakes me up and I reply to fuse that the requets has completed or fuse wakes me up and I handle a second request in parallel to the ones pending. > It'd be very nice if someone could provide a bit of insight in the > implementation FUSE's poll() support. > > Best regards, > alberto MfG Goswin |