0.9.x is just a prerelease prelude to 1.0.0, which I plan on releasing right after Leopard is released.
I might do a more public 0.9.x prerelease in the near future. I'd say just keep using this one until then and do let me know if you come across more problems. Thanks for reporting this--very nice and subtle problem that I'm happy to fix. Amit On Oct 2, 2:05 pm, dberton <[EMAIL PROTECTED]> wrote: > Thank you for the insight on the problem. > > I have re-tested this again without the -d flag, so things are running > at full speed. Again, there was no crash with iTunes, or under > extemely heavy load all day long. I would call this fixed. > > Is there any sort of timeframe for 0.9.x to be officially released? > > Thanks so much for your efforts, > > db > > On Oct 2, 2:04 pm, Amit Singh <[EMAIL PROTECTED]> wrote: > > > > What was your hunch? Those who are interested in the MacFUSE internals > > > may appreciate knowing what the exact fix was. > > > The kernel sends the user-space library calls like the following: > > > open ... read/write ... fsync ... flush ... release > > > After "release", there must not be any calls for that particular file > > handle. sshfs implements both fsync and flush through a single backend > > function (sshfs_flush). It also does a flush from its release > > implementation. In your case, a ton of fsync/flush/release calls were > > being generated. These can be served by a pthread each in user space. > > The library was launching the pthreads in the correct order (in the > > order the calls were received), but that doesn't guarantee the calls > > will execute/finish in that order. Once in a while, it was so > > happening that a "release" finished before the last flush could > > finish. Since release frees the file handle/context, when flush did > > finish, it would crash while trying to manipulate the now-freed > > memory. > > > MacFUSE can send any/all of these calls to user space either > > synchronously or asynchronously. In most cases, it has to be > > synchronous because it needs to know the reply. Even though fsync is > > meant to be synchronous (with respect to some definition of "sync"), > > MacFUSE has a different situation (wildly different kernel > > architecture) as compared to the Linux FUSE implementation. For > > certain reasons (too much detail to repeat here), MacFUSE was sending > > asynchronous fsync messages. This caused many in-flight such messages > > in user space. Since the library doesn't have any special handling to > > enforce in-order execution of fsync/release, we ran into your > > situation. My fix was to get rid of the aforementioned "certain > > reasons" and make all fsync's synchronous. > > > Amit --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" 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-devel?hl=en -~----------~----~----~----~------~----~------~--~---
