Date: Wed, 27 Apr 2011 17:10:46 -0300 From: Chris Forgeron <cforgeron@acsi.ca> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: RE: make the experimental NFS subsystem the default one Message-ID: <BEBC15BA440AB24484C067A3A9D38D7E01637BBA4B6A@server7.acsi.ca> In-Reply-To: <1143723691.393441.1303384281461.JavaMail.root@erie.cs.uoguelph.ca> References: <BEBC15BA440AB24484C067A3A9D38D7E016364A6643A@server7.acsi.ca> <1143723691.393441.1303384281461.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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? Otherwise I just have to hack up the source and release a patch to those who want the feature, which seems counterproductive. I'd be very appreciative of the switch, and can offer you some heavy testing of it and your NFS code and report back to help with your code adoption. -----Original Message----- From: Rick Macklem [mailto:rmacklem@uoguelph.ca] Sent: Thursday, April 21, 2011 8:11 AM Have you tries the "async" mount option on the client side? (or did you say you couldn't do that above?) I would be very hesitant to do it on the server side, since it would violate the RFC (and you do run a risk of losing data, which many might not realize uptil it is too late). rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BEBC15BA440AB24484C067A3A9D38D7E01637BBA4B6A>