Date: Sun, 16 Dec 2001 00:01:17 -0800 From: Conrad Minshall <conrad@apple.com> To: Matthew Dillon <dillon@apollo.backplane.com>, Jordan Hubbard <jkh@winston.freebsd.org>, Peter Wemm <peter@wemm.org>, Mike Smith <msmith@freebsd.org>, hackers@freebsd.org, msmith@mass.dis.org Subject: Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step ) Message-ID: <l03130302b841fdae1ebc@[17.219.180.26]> In-Reply-To: <200112160122.fBG1Mtq18851@apollo.backplane.com> References: <58885.1008217148@winston.freebsd.org> <l03130304b8413ae1338b@[17.219.180.26]>
next in thread | previous in thread | raw e-mail | index | archive | help
At 5:22 PM -0800 12/15/01, Matthew Dillon wrote: > Ho! Will do. I'm going to try to speed things up a bit by > having the NFS server export an MFS filesystem. > > -Matt Two things I've done to speed it up are to restrict the size of transfers (use the -o flag) and eliminate all the size checks (use the -n flag). Why would MFS be much faster than UFS? On the server doesn't the whole file end up cached? ...and the metadata changes likewise via softupdates. Running fsx during resource shortages (low memory or buf structs) has exposed a bug or two. Running it with operations 512 or page aligned also exposed bugs - see usage for those flags. Note that if you get a failure at operation 50 million there is an fsx flag which allows you to restart at, say, 49 million. Of course some failures don't reproduce reliably at the same spot anyway. I gave out fsx source code at the recent CIFS (SMB) plugfest. If I make the 2002 Connectathon I'll give it out there too. I don't test it on Windows so those defines may be in need of repair. Please send me any patches or cool additions. -- Conrad Minshall, conrad@apple.com, 408 974-2749 Apple Computer, Mac OS X Core Operating Systems To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03130302b841fdae1ebc>