Status of NFS4.1 FS_RECLAIM in FreeBSD 10.1?

Mahmoud Al-Qudsi mqudsi at neosmart.net
Thu May 21 02:57:13 UTC 2015


On May 20, 2015, at 8:57 PM, Rick Macklem <rmacklem at uoguelph.ca> wrote:
> Only the global RECLAIM_COMPLETE is implemented. I'll be honest that
> I don't even really understand what the "single fs reclaim_complete"
> semantics are and, as such, it isn't implemented.

Thanks for verifying that.

> I think it is meant to be used when a file system is migrated from
> one server to another (transferring the locks to the new server) or
> something like that.
> Migration/replication isn't supported. Maybe someday if I figure out
> what the RFC expects the server to do for this case.

I wasn’t clear on if this was lock reclaiming or block reclaiming. Thanks.

>> I can mount and use NFSv3 shares just fine with ESXi from this same
>> server, and
>> can mount the same shares as NFSv4 from other clients (e.g. OS X) as
>> well.
>> 
> This is NFSv4.1 specific, so NFSv4.0 should work, I think. Or just use NFSv3.
> 
> rick

For some reason, ESXi doesn’t do ESXi 4.0, only v3 or v4.1.

I am using NFS v3 for now, but unless I’m mistaken, since FreeBSD supports
neither “nohide” nor “crossmnt” there is no way for a single export(/import)
to cross ZFS filesystem boundaries. 

I am using ZFS snapshots to manage virtual machine images, each machine
has its own ZFS filesystem so I can snapshot and rollback individually. But 
this means that under NFSv3 (so far as I can tell), each “folder” (ZFS fs) 
must be mounted separately on the ESXi host. I can get around exporting 
them each individually with the -alldirs parameter, but client-side, there does
not seem to be a way of traversing ZFS filesystem mounts without explicitly
mounting each and every one - a maintenance nightmare if there ever was one.

The only thing I can think of would be unions for the top-level directory, but I’m
very, very leery of the the nullfs/unionfs modules as they’ve been a source of 
system instability for us in the past (deadlocks, undetected lock inversions, etc).
That and I really rather a maintenance nightmare than a hack.

Would you have any other suggestions?

Thanks,

Mahmoud



More information about the freebsd-stable mailing list