Hi Erik, > Basically release a) features locking that is extremely conservative. The > entire kernel extension code is locked down with a 'huge lock' each time a > thread enters. I.e. if one call blocks on one file system, all other MacFUSE > file systems are also blocked until the call completes. This is pretty > unsuitable for general-purpose use, and was never meant to be a final > solution.
You are right, a finer grained locking would be much better. My intentions releasing the 2.1.7 build were just to make your early stage locking mechanism available to those enthusiasts who wanted to use Snow Leopard's 64 bit kernel like me without missing out on MacFUSE. At that time I was not sure whether you would release a MacFUSE version for the rest of us eventually or use it just in your commercial NTFS driver under the name TUFS. > Release b) features per-filesystem locking and node locking which means that > filesystems are more independent of each other. The 'biglock' that is > associated with each file system is also released during external calls that > could block (otherwise deadlocks could result) but the node lock stays in > place most of the time to ensure that nobody modifies the vnode that is being > accessed. This is all a bit error-prone and needs to be tested, which is why > I posted a release with lots of debug messages. Since nobody seems to have > experienced any deadlocks, maybe it's time to share the source code of this > build: > http://www.tuxera.com/mac/macfuse-rebel-2.1.9-src.tar.bz2 Thanks for clearing that up and for releasing the source code. I really appreciate it. >> Could be that the panic Zev encountered is locking related and could have >> been avoided when using Tuxera's build. > > A panic log would have been helpful, otherwise we cannot know what was the > cause. Panics are actually unlikely to result from the locking code itself. > If there's a problem with locking, the result is usually a system-wide lockup > (deadlock inside the kernel). Maybe Zev will send his panic report, but I think we should concentrate on testing your build since its locking mechanism seems to be a big step ahead of the TUFS 2010.10.07 source code I used. > I simply set the version to 2.1.9 to signal that it's different from the > previous build that was released from backporting the 'TUFS' modifications. > Version numbers can be discussed, this was just a test release anyway. > We generally favour a YEAR.MONTH(.something)-type versioning scheme at Tuxera. Since we most likely cannot continue using the original google code project and do not have Amit's official private key file used to sign the official releases the update mechanism (MacFUSE Prefpane) is broken anyway. So we could start fresh. But on the other hand there might be some other applications around relying on MacFUSE and therefore checking its version number. This might lead to problems if the scheme is changed. Regards Benjamin -- 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.
