Re: [PATCH 23/26] ceph: nfs re-export support

[Miklos Szeredi]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/