On Nov 13, 6:04 pm, Benjamin Fleischer <[email protected]> wrote: > > I poked around with it a bit more after rebooting and didn't encounter > > any problems -- I'll continue doing so though and see if I can > > reproduce it (if so I'll report back with any findings). I guess if > > we're trying to debug 2.1.7 I should probably stick with that for now, > > but would there be any benefit to trying out the "Release B" (2.1.9) > > mentioned above with finer-grained locking? > > The finer-grained locking should be noticeable especially when working with > more than one filesystem mounted through MacFUSE at the same time. As Erik > explained earlier "Release A" would lock each filesystem when using one of > them. From a performance point of view this is really bad. In your case sshfs > would add some network overhead which should thwart your encfs volume even > more. > > Erik's release "Release B" (2.1.9) should therefore be the first choice in > your case. > > I did some basic but synthetic testing with Erik's code and did not encounter > any problems so far. I mounted two filesystems and let 100 simultaneous > read/write threads loose on each volume. This has been running for about an > hour by now. I did not encounter a kernel panic or data corruption. > > > And of course, if there's anything else I can do to help debug, let me > > know (wish I had time to actually dig into the code, but grad school's > > keeping me pretty busy). > > After Eric released the source code for his build and explained how he > improved the locking mechanism I don't see any point in investing time > debugging the 2.1.7 build I released. Feature-wise there is no difference. > Erik's release is missing the preference pane but to be honest it is pretty > much useless if there is no update server around.
I'm having some trouble building 2.1.9 -- I downloaded and unpacked the tarball linked above (http://www.tuxera.com/mac/macfuse- rebel-2.1.9-src.tar.bz2), but running 'macfuse_buildtool -t dist' in macfuse-rebel-2.1.9/core failed to find /etc/macfuse/private.der. I copied in core/private_key.der from the 2.1.7 tree and hacked the build script's M_CONF_PRIVKEY to refer to it (assuming it's just a "throwaway" private key for signing the build for distribution, and not much of a concern since I'm not actually distributing anything). The build still failed though, and the source of the problem wasn't immediately obvious to me (output is at http://pastebin.com/TevasaHj). Does this version require some different build steps I'm not aware of? Thanks, Zev -- 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.
