make the experimental NFS subsystem the default one

[Rick Macklem]

> Yes, as I noted in my message, you can't enable async client side -
> It's inside of ESX, and you don't have an option to modify.
> 
> And yes, it would also mean that you could really screw things up, but
> even if you have to make it a hidden option, I know it would be
> invaluable to the ESX crowd. When you're running on a ZFS storage
> base, having sync writes in NFS doesn't add any security, as ZFS is
> handling all of that for us, and often with far more
> performance/reliability.
> 
I'm not sure what you are saying here. Are you assuming that ZFS won't
lose data when the server crashes, even if it isn't getting the VOP_SYNC()
for the file when the client assumes it is saved to stable storage (disk
or SSD or ...)? (You say "security", but it sounds like you are referring
to data reliability along the lines of "won't lose any file data if it
crashes/reboots.)

I don't know anything about ZFS, but I would think that, if you see a
major performance improvement, that ZFS isn't committing stuff to logs
so that data won't be lost.

Maybe the ZFS folks can comment? (I don't remember seeing the details
of what you change? If you sent a patch, sorry, but I've misplaced it.)

> I think it would give a nice advantage to a FreeBSD ZFS/NFS solution.
> It definitely makes a speed difference, even with a properly
> configured ZIL.
> 
> Would it be enough to have a big warning on the man page for the
> switch that it breaks RFC compliance, to log that warning when it
> happens, and to generally warn of dire consequences to anyone who
> doesn't understand what they are doing?
> 
Well, my concern is that the sysadmins won't realize that they can lose
file data if the server crashes/reboots with this enabled. Which is what
I believe your changes would do, if I understood it correctly?

If the client is specifying the FILE_SYNC on each write, it is saying
that it expects the data and metadata for the file being written to be
saved to stable storage (so that it won't be lost due to a crash/reboot)
before the server replies to that write rpc. (If you choose not to do
that, file corruption etc can happen. Some environments wouldn't care,
but the sysadmins need to know what they are doing w.r.t. this.) The NFS
spec. writers chose not to make this optional (RFC1813 says "must" for
this) and I suspect it was because they understood that sysadmins wouldn't
be ready for the consequences.

I think it's up to the "collective" whether or not something like this
goes in the code, but I personally thing it's a risky idea.

rick