My first post here, I hope I am on topic :-)
If you had tried Xgrid FUSE 0.2.0 last week, and all you had was an unreadable volume, you can give it another try here: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/html/goodies/XgridFUSE-info.html If you had nver heard of it, here is a quick overview. I also have some questions to other filesystem developers towards the end of the post. Summary: Xgrid FUSE combines Xgrid and MacFUSE (duh!) Xgrid FUSE transforms an Xgrid controller into a file system. This means your job results will appear as actual files in the Finder or in the Terminal, and you can browse your jobs just like real folders and manipulate results just like real files (well, read-only files). All of this goodness thanks to the fantastic MacFUSE project! You can read more on Xgrid FUSE and download the application here: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/html/goodies/XgridFUSE-info.html Xgrid FUSE is open source. There are a few things I would like to fix/ implement eventually, but this project is really just a fun side- project I started simply to play with MacFUSE. If anybody feels like contributing anything, send me an email: * filesystem notifications, for Finder live updates, e.g. having differnet icons depending on the status of jobs, live update of jobs downloaded,... I just need to find the time to identify the APIs. Hopefully, that should be relatively easy. * Submissions by dropping files on the disk or a grid --> I tried using the objc Fuse APIs, but could not get somehting to work properly. I am not familiar enough with the FUSE APIs. There are a bunch of different IO calls, and I am not sure how each call should respond during addition of a file. When is a file considered existing? When is the file data considered available?... I will have to look at exisiting code in Fuse-based projects, and will likely need some info from Fuse or MacFuse developers. * Thread safety? The ObjC wrapper runs FUSE in a separate thread. Is it necessary? The reason is probably that it would otherwise hijack the runloop in the main thread, I have to check the code. The Xgrid stuff needs an NSRunLoop, in any case. My current problem: the FUSE thread accesses data from the main GridEZ thread with no protection. When I use an SQLite store backend, I get worrisome error messages in the console with out of order operations going on, not sure what it means. But the store likely gets stuff in and out of disk (fault creations and firings) in both threads at the same time, and that could be the issue. With an in-memroy store, I don't see any apparent problems at runtime. But I am not sure if bad things could still happen with in-memory stores. I tried to access it in a cleaner way by messaging instead to the main thread when accessing the data, but that caused a bad bad bad hang that would take down all the user processes and apps (hard reboot, even killing Xgrid FUSE or Xcode via ssh did not help). Future version will try to address the issue. Maybe a single lock on a global generic object such as an NSDictionary to move the data from the main thread to the FUSE thread. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
