On Wed, 3 Mar 2010, Sage Weil wrote: > On Wed, 3 Mar 2010, Christoph Hellwig wrote: > > On Tue, Mar 02, 2010 at 04:46:54PM -0800, Sage Weil wrote: > > > Basic NFS re-export support is included. This mostly works. However, > > > Ceph's MDS design precludes the ability to generate a (small) > > > filehandle that will be valid forever, so this is of limited utility. > > > > So don't include it if it's broken by design. > > Well, there are changes we can make to the MDS to make it work that are on > the roadmap (they'll also help with disaster recovery). They will require > some change on the client side, though, so it's not like the current > implementation will suddenly work perfectly with a server-side upgrade. > > That said, I don't think Ceph is the only filesystem that has this problem > (fat? fuse? cifs?), and it is still useful in its current state. But I > can leave it off by default (via Kconfig option), or include a kern.log > warning, or leave it out entirely, if that's what people prefer. Fuse uses a fixed 64bit handle on the userspace/kernel API and on the "low level" userspace API, so that's NFS export compatible. On the "high level" API fuse uses path strings, which are not so suitable for NFS exporting. Despite that, people have been exporting these fuse filesystems over NFS and dealing with the occasional ESTALE if the inode has been evicted from the cache on the server side but the client still holds a file handle. CIFS doesn't seem to have any export capability. FAT tries, but is also not guaranteed to work if the inodes are no longer in the cache. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
