Hi Amit, Thanks for the quick reply, but in fact, it was my fault (something very stupid) :-)
I was not looking at the low-level output, but was tracing all callback invocations to syslog. Without the "-l" option, getattr() is not called for the directory entries for which a stat structure is provided trough the filler function. With the "-l" option, getattr() is called for all directory entries, even if a stat struct was provided. This is the behavior on Linux. On Mac, I have ls aliased to "ls -G", which as well enforces the getattr() calls. When I use "/bin/ls", the MacFUSE library behaves exactly the same as FUSE on Linux for this particular case. Regards, Frank On Mar 3, 11:45 am, Amit Singh <[email protected]> wrote: > On Mar 3, 1:30 am, "f...@nk" <[email protected]> wrote: > > > When I provide a stat argument to the filler callback in the readdir() > > function, then the getattr() function will not be called for that > > directory entry on Linux. With MacFUSE however, the getattr() > > function is still called, and the stat buffer that is passed to it is > > empty. > > How are you checking that the getattr() callback is not called on > Linux? Are you just looking at libfuse's debug output (the -d > argument)? I'll presume you are. That debug output shows low-level > FUSE API operations. If you actually trace your file system's getattr > () callback, you should see *that* being called on Linux even if you > fill in the stat structure in filler(). > > The last I checked, Linux FUSE does not do much with the stat > structure you populate in filler(). It takes only st_mode and > potentially st_ino from it and discards the other stat contents. On > Linux, when you do an "ls -l" in a directory, and in your user-space > file system you do fill in the stat structure, you will not see a > GETATTR for each directory entry in the debug output. Instead, you > will see a LOOKUP for each directory entry. Both the GETATTR and > LOOKUP low-level operations end up calling the high-level getattr() > callback. > > Now, if you compare this with the libfuse debug output on Mac OS X, > you'll indeed see GETATTRs, but then you will not see LOOKUPs like in > the case of Linux. Based on what I said above, this means that one way > or another, your file system's getattr() callback will still be > called. Upon the first "ls -l", you should see a LOOKUP for each > directory entry. On subsequent "ls -l"s, you'll see GETATTRs instead. > This is because MacFUSE employs vnode name caching in the kernel. > (That is, the lookups are cached.) Even though a name is found in the > cache, if the attributes aren't valid, the kernel has to call up to > user space. > > You can see the cache in action this way: cd to the mounted file > system so that it becomes busy. Then try to unmount it from another > shell. This will flush all vnodes except the root vnode, and the file > system will fail to unmount becuase it is busy. Now repeat your "ls - > l". You'll see that things go back to the first "ls -l" case. Because > the name cache has been purged, you'll see LOOKUPs for each directory > entry. > > That said, on both Mac OS X and Linux, there's potential for > *marginally* optimizing things by better utilizing the stat > information you might supply in filler(). Then again, even now, if you > specify a large attr_timeout value, say, 60 seconds, you should not > see GETATTR calls for that duration. > > > Is this normal behavior of MacFUSE? > > Yes it is. > > Rule of thumb: The nature of the Mac OS X and Linux file system layers > are vastly different. The MacFUSE and Linux FUSE kernel extension > implementations are also vastly different. MacFUSE gives you (a > superset of) the FUSE API, but because of the aforementioned > differences, behavioral differences will abound. Comparing number of > callbacks for similar operations, sequence of callbacks received, > etc., isn't going to be very useful. > > Amit --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MacFUSE" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/macfuse?hl=en -~----------~----~----~----~------~----~------~--~---
