Anthony Wright wrote: > I realise that using FUSE would add a whole layer of inefficiency but > it's a clean, well defined API to write to. My other thought was whether > the OpenAFS server includes an API which is similar in concept to FUSE > which I could use to publish my filesystem directly to OpenAFS, avoiding > FUSE & kernel VFS altogether. It would mean that I could publish the > file system over OpenAFS, but not over other networked file systems, for > example Samba. However, if the API wasn't too complex, I couldn't see > that being a big problem as I could publish to both APIs if I needed. > Does OpenAFS have such an API?
OpenAFS does not have such an API. OpenAFS does not serve files the way most file systems do. All files in AFS are currently stored in a portable volume format that permits the data to be easily migrated and replicated between file servers running on heterogeneous architectures with otherwise incompatible local file storage. Data stored in AFS can only be accessed through an AFS client. Even on the machine on which the data is physically located. The hostafsd project that we have mentioned to you is a first attempt at permitting the contents of the local file system to be served to AFS clients without requiring that the data be stored in AFS volumes. While this approach will permit AFS clients to access data stored on arbitrary local file systems what is lost are the AFS volume management capabilities including AFS replication. Eventually we hope to have a multi-backend file server implementation that will permit a mixture of AFS volume based backends (inode and namei) and local file system export (hostafs) to exist in the same file server at the same time. This would permit easy transitions into and out of AFS. Once this architecture is in place you could write just about any backend you wish provided that the underlying file system could satisfy the requirements of AFS. The most important of which is the ability to notify the file server when the contents or metadata of a directory or file have changed. There are no estimates for when the multi-backend file server will be completed. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
