Date: Fri, 9 Mar 2018 01:18:58 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: NAGY Andreas <Andreas.Nagy@frequentis.com>, "'freebsd-stable@freebsd.org'" <freebsd-stable@freebsd.org> Subject: =?iso-8859-1?Q?Re:_NFS_4.1_RECLAIM=5FCOMPLETE_FS=A0failed_error_in_combin?= =?iso-8859-1?Q?ation_with_ESXi_client?= Message-ID: <YQBPR0101MB104272F35F3BBD095BAE61E8DDDE0@YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <D890568E1D8DD044AA846C56245166780124AFCFF8@vie196nt> References: <c5c624de-42bb-45cf-8cf0-b25be56e5f58@frequentis.com> <YQBPR0101MB1042DEF0825996764CBCA829DDC40@YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM>, <D890568E1D8DD044AA846C56245166780124AFB90E@vie196nt> <YQBPR0101MB1042479407CAA253674BBAEBDDDB0@YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM> <D890568E1D8DD044AA846C56245166780124AFBD21@vie196nt>, <D890568E1D8DD044AA846C56245166780124AFBD91@vie196nt> <YQBPR0101MB104225B6884FEC70A03C61CCDDDA0@YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM>, <D890568E1D8DD044AA846C56245166780124AFC0E2@vie196nt>, <YQBPR0101MB1042040D2BFB3681E940D271DDDA0@YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM>, <2feda1e2-16d5-43b5-98eb-dcc71cc67c6f@frequentis.com> <YQBPR0101MB10427C97161C74A5C441D1DCDDD80@YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM>, <D890568E1D8DD044AA846C56245166780124AFCABC@vie196nt> <YQBPR0101MB1042B17763E2605A7CE72EF5DDDF0@YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM>, <D890568E1D8DD044AA846C56245166780124AFCFF8@vie196nt>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] NAGY Andreas wrote: >Actually I have only made some quick benchmarks with ATTO in a Windows VM >which has a vmdk on the NFS41 datastore which is mounted over two 1GB links in >different subnets. >Read is nearly the double of just a single connection and write is just a bit faster. >Don't know if write speed could be improved, actually the share is UFS on a HW >raid controller which has local write speeds about 500MB/s. I took a quick look at your packet trace and it appears that this client does all write FILESYNC. As such, setting vfs.nfsd.async=1 won't have any affect. If you apply the attached patch, it should change the FILESYNC->UNSTABLE so that vfs.nfsd.async=1 will make a difference. Again, doing this does put data at risk when the server crashes. rick [-- Attachment #2 --] --- fs/nfsserver/nfs_nfsdserv.c.sav2 2018-03-08 20:44:43.163080000 -0500 +++ fs/nfsserver/nfs_nfsdserv.c 2018-03-08 20:54:50.225719000 -0500 @@ -912,6 +912,15 @@ nfsrvd_write(struct nfsrv_descript *nd, } /* + * If nfs_async is non-zero, pretend that all writes are being + * done NFSWRITE_UNSTABLE. Doing this violates the RFCs and runs the + * risk of data loss/corruption when the NFS server crashes. + * + */ + if (nfs_async != 0 && (nd->nd_flag & (ND_NFSV3 | ND_NFSV4)) != 0) + stable = NFSWRITE_UNSTABLE; + + /* * For NFS Version 2, it is not obvious what a write of zero length * should do, but I might as well be consistent with Version 3, * which is to return ok so long as there are no permission problems.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB104272F35F3BBD095BAE61E8DDDE0>