Hi Gordon, Gordon Ross wrote:
In case anyone would like to have a look, here are the slides from my presentation on "FUSE with in-kernel meta-data caching" at SCALE 10x last month. (Summary: doors based fuse is more efficient by a factor of almost 2:1) http://yalms.org/docs/fuse-scale-2011.pdf
Great, but do not be confused by the implementation bugs in the fuse kernel module. The cacheing of pages being written to is wrong : if the application uses a 512 byte buffer, and the cluster size is 4K, the kernel module sends 512 bytes (0-511) 1024 bytes (0-1023) 1536 bytes (0-1535) .... 4096 bytes (0-4095) 512 bytes (4096-4617) etc. So in average each byte is sent twice. Note : the fuse module looks like it has never been debugged.
Here's the doors-based fuse described in the SCALE presentation: https://bitbucket.org/gwr/illumos-fuse2
I do not agree with the need to rebuild the full path at any stage, at least for a local file system (network file systems may have different requirements). At the vnode level, a file is identified by its nodeid or by a file name in a directory and the nodeid of the directory. At the file system level, it is just the same, the full path is not needed anywhere. Moreover the full path creates complexity when a file has several paths (hard links) : you have to make sure a single record in the caches is used when a file has several names. Getting rid of the full path may also help managing ghost files which have been deleted, though kept open by other processes. So, why not try to eliminate the "fuse high level" ? Regards Jean-Pierre _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
