Re: Found NFS data corruption bug... (was Re: NFS: How to makeFreeBSD fall on its face in one easy step )
At 12:24 PM -0800 12/16/01, Matthew Dillon wrote:
program runs fine in an overnight test. We still have a known issue
with out-of-order operations from nfsiod's that apparently may come
up after a week or so of testing. I asked Jordan to try to track down
the NeXT guy who fixed that one in the old NFS stack.
This bug showed up recently here with fsx testing. I seem to have fixed it
last week in MacOS X. The diffs were widespread but the idea was simple
enough so a few code snippets should suffice:
nfs_request gets a new argument (u_int64_t *xidp) and fills it in here:
m = nfsm_rpchead(cred, nmp-nm_flag, procnum, auth_type, auth_len,
auth_str, verf_len, verf_str, mrest, mrest_len, mheadend, xid);
if (xidp)
*xidp = xid + ((u_int64_t)nfs_xidwrap 32);
nfsm_rpchead bumps nfs_xidwrap when avoiding a zero xid.
Callers of nfs_request take the returned xid and pass it via the macros to
nfs_loadattrcache, from which the following code is snipped:
if (*xidp np-n_xid) {
/*
* We have already updated attributes with a response from
* a later request. The attributes we have here are probably
* stale so we drop them (just return). However, our
* out-of-order receipt could be correct - if the requests were
* processed out of order at the server. Given the uncertainty
* we invalidate our cached attributes. *xidp is zeroed here
* to indicate the attributes were dropped - only getattr
* cares - it needs to retry the rpc.
*/
np-n_attrstamp = 0;
*xidp = 0;
return (0);
}
Further down in nfs_loadattrcache:
np-n_xid = *xidp;
Note xids are kept in a 64 bit form so relative comparison won't fail in
the unlikely case that xids wrap around zero.
Here's the change in nfs_getattr. I don't expect to ever see the panic.
avoidfloods = 0;
tryagain:
nfsstats.rpccnt[NFSPROC_GETATTR]++;
nfsm_reqhead(vp, NFSPROC_GETATTR, NFSX_FH(v3));
nfsm_fhtom(vp, v3);
nfsm_request(vp, NFSPROC_GETATTR, ap-a_p, ap-a_cred, xid);
if (!error) {
nfsm_loadattr(vp, ap-a_vap, xid);
if (!xid) { /* out-of-order rpc - attributes were dropped */
m_freem(mrep);
if (avoidfloods++ 100)
goto tryagain;
/*
* avoidfloods1 is bizarre. at 100 pull the plug
*/
panic(nfs_getattr: getattr flood\n);
}
--
Conrad Minshall, [EMAIL PROTECTED], 408 974-2749
Apple Computer, Mac OS X Core Operating Systems
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Found NFS data corruption bug... (was Re: NFS: How to makeFreeBSD fall on its face in one easy step )
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, [EMAIL PROTECTED], 408 974-2749 Apple Computer, Mac OS X Core Operating Systems To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NFS: How to make FreeBSD fall on its face in one easy step
At 2:56 PM -0800 12/12/01, Jordan Hubbard wrote: The only thing I get is a math exception because closeprob is zero since no -c option was given. Can you provide some sample parameters please ? Hmmm, how strange, now that I look at the code it's obvious that a divide by zero will occur with a zero closeprob and the docs state the default to be infinity, which is obviously not the case. The strange part is that I ran this on freebsd.apple.com, which is running 4.4-stable, with one parameter (the filename) exactly as I pasted in the usage instructions before. Perhaps all this time spent living next to the Macintosh in my office has induced that copy of FreeBSD to be more friendly and mask simple math errors. :-) In any case, -c 1 appears to work just fine. That gives a close/open between each operation. Better is to fix the fsx.c source by inserting an if in main()... diff -u -d -b -w -r1.21 fsx.c --- fsx.c 2001/12/11 23:27:20 1.21 +++ fsx.c 2001/12/15 15:31:19 @@ -701,6 +701,7 @@ testcalls++; + if (closeprob) closeopen = (rv 3) (1 28) / closeprob; if (debugstart 0 testcalls = debugstart) -- Conrad Minshall, [EMAIL PROTECTED], 408 974-2749 Apple Computer, Mac OS X Core Operating Systems To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NFS: How to make FreeBSD fall on its face in one easy step
At 8:19 PM -0800 12/12/01, Jordan Hubbard wrote: To be clear, what exactly are you doing? It sounds like you're exporting something from freebsd, mounting it on OSX and running this tool on OSX against the filesystem exported from freebsd ? If so, What mount options? NFSv2 or v3? That is correct. As to the NFS options used, I honestly couldn't say since I'm getting at the filesystem through Netinfo and that's handled by OS X's automount daemon, that having no relation whatsoever to AMD and hence no amd.conf file or anything else I can easily look at to determine how it's being mounted. Maybe Mike knows more about how to find this out - he's not in management. :) In the absence of mount-options the OS X automount tries v3 first, followed by v2 if v3 appears not supported by the server. -- Conrad Minshall, [EMAIL PROTECTED], 408 974-2749 Apple Computer, Mac OS X Core Operating Systems To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Found NFS data corruption bug... (was Re: NFS: How to makeFreeBSD fall on its face in one easy step )
At 10:08 PM -0800 12/12/01, Matthew Dillon wrote: Ok, here is the latest patch for -stable. Note that Kirk comitted a slightly modified version of the softupdates fix to -current already (the VOP_FSYNC stuff), which I will be MFCing in 3 days. This still doesn't fix all the problems the nfstest program that Jordan posted finds, but it sure runs a hellofalot longer now before reporting an error. 10,000+ tests now before failing (NFSv2 and NFSv3). Once it runs aok for a few million operations, try concurrently running: #! /bin/sh while : do sync sleep 1 done In OS X I used that to flush :) out a couple more bugs. -- Conrad Minshall, [EMAIL PROTECTED], 408 974-2749 Apple Computer, Mac OS X Core Operating Systems To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
NETBIOS Browsing?
Does anyone know of any code which would help in browsing a Windows Network Neighbourhood? Something which would make broadcasts to find all the netbios name servers, and then query them to discover more. Code from Samba's nmblookup would be fine but it is GPL. -- Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749 Alternative email addresses: [EMAIL PROTECTED] and [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NETBIOS Browsing?
At 2:44 PM -0700 7/20/01, Alexander Langer wrote: Does anyone know of any code which would help in browsing a Windows Network Neighbourhood? Something which would make broadcasts to find all the netbios name servers, and then query them to discover more. Code from Samba's nmblookup would be fine but it is GPL. xsmbrowser is a GREAT tools, which is even better than Microsofts Network Neighbourhood. I use it to browser our LAN with 200+ PCs and it's very comfortable (and has less bugs than M$' crap) Thank you. I should have mentionedxsmbrowser. Unfortunately it is GPL and uses Samba (also GPL). ...bcc to the author of xsmbrowser -- Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749 Alternative email addresses: [EMAIL PROTECTED] and [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NETBIOS Browsing?
At 2:45 PM -0700 7/20/01, Alexander Langer wrote: Ouch, I should actually read more carefully what you were asking, sorry. I guess smbfs doesn't help you here (don't know if it actually browses, but at least it's SMB stuff) grin Extending smbfs with browsing is exactly what I wish to do. -- Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749 Alternative email addresses: [EMAIL PROTECTED] and [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UDF
At 1:20 AM -0800 1/15/00, Soren Schmidt wrote: It seems Harold Gutch wrote: On Fri, Jan 14, 2000 at 09:29:58AM +0100, Soren Schmidt wrote: I have it on my TODO list, but I'm not started yet, and probably wont for some time to come. The reason I've put it on the backburner for now, is that DVD's can be read using the cd9660 filesystem, and that is sufficient for my needs for the time being. I was under the impression that this was only possible as long as the DVDs actually had an ISO9660 filesystem as well - which all of my DVDs have, but which still doesn't mean that there are no DVDs with only UDF, but no ISO9660 filesystem. I'm pretty sure all DVD's produced to date have an iso9660 file sys on them, but they might change that in the future, so having UDF support would be a win for us in the long run. DVD Forum's DVD-Video spec requires the UDF Bridge format, which gives you both UDF and 9660 metadata without duplicating file data. Commercial DVD videos are currently using this format. Bridge format is intended for read-only usage - as far as I know all DVD-RAM use is and will be restricted to "mono-metadata". -- Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749 Apple Computer ... Mac OS X Core Operating Systems ... NFS/UDF/etc Alternative email address: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
At 1:36 PM -0800 11/25/99, C. Stephen Gunn wrote: On Mon, Nov 22, 1999 at 02:07:58PM -0800, Alfred Perlstein wrote: Does NetBSD have a working rpc.lockd... that would make this much easier. at a glance at http://cvsweb.netbsd.org/... no. I'm fairly certain that rpc.lockd is included with Darwin from Apple, I've not closely compared it to what we have in -STABLE or -CURRENT to see if it actually works. It doesn't, sorry... if someone gets a *BSD version of NFS locking operating I'd help see it into Darwin. BTW, is anyone working on NFS Version 4 for BSD? Rick? -- Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749 Apple Computer ... Mac OS X Core Operating Systems ... NFS/UDF/etc Alternative email address: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Serious locking problem over NFS
At 4:39 PM -0800 11/11/99, Alfred Perlstein wrote:
On Thu, 11 Nov 1999, Doug Barton wrote:
The following small program illustrates an obscure problem with
file locking with freebsd as an NFS client. I'm aware of the problems with
We currently don't support client or server locking.
work is in progress, but the dolt that took the job is extremely busy
right now. (me)
Yup, byte range locking fcntl APIs are present but over NFS they don't work.
So shouldn't one be able to get entire-file locking with the old-fashioned:
open("foo.lockfile", O_CREAT | O_EXCL, 0644)
You would think so, but my experience is that reliably protects critical
sections only when using NFS Version 3. Not V2. Read about EXCLUSIVE in
the CREATE procedure in RFC 1813 for another level of detail.
--
Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749
Apple Computer ... Mac OS X Core Operating Systems ... NFS/UDF/etc
Alternative email address: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: read/write atomic?
It would be great if someone could ram such a change through the standards committees. The changes nowadays are coming via "The Austin Group". See http://www.opengroup.org/austin/ and associated mailing list. Alternatively Linux could become enough of a defacto standard that we could ignore the standards committee. Barring that, the only solution available to us to increase performance is to implement temporary byte-ranged locks within the kernel to allow the I/O to be parallelized. It isn't necessarily as bad as you think... support for such locks already exists in order to deal with POSIX locks, but it would certainly be easier if we didn't have to mess with it at all. Adding more reliance on the POSIX locks works fine if that implementation is extended to include the common filesystems... in particular NFS file locking seems needed. A footnote is ensuring the deadlock detection code finds deadlocks which span multiple filesystem types. BTW the NFS version 4 protocol includes byte range locking. Version 2 and 3 use a seperate (out-of-band) locking protocol. Matthew Dillon [EMAIL PROTECTED] -- Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749 Apple Computer ... Mac OS X Core Operating Systems ... NFS/UDF/etc Alternative email address: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
At 4:20 AM -0700 10/6/99, Daniel C. Sobral wrote: It is no worse than uid/gid problems with NFS. Umm, what is this, FreeBSD-Humor? Thanks for the laugh, and remember, it's just a nasty old rumor that NFS stands for "No File Security" :-/ -- Conrad Minshall ... [EMAIL PROTECTED] ... 408 974-2749 Apple Computer ... Mac OS X Core Operating Systems ... NFS/UDF/etc Alternative email address: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -STABLE, panic #15
So far my conclusions have led me to a race in unlink and NFS somewhere (still have no clue where). And it is only from Sun clients to date. Also, this started happening in ernest arround when we put the latest patches on our Suns (this hadn't been mentioned before.) seeing how I can reliably reproduce this panic (I am trying today's STABLE now to see if I still can), does anyone have anything they would like me to try. OK, my NFS internals expertise is on another BSD derivative, but... If you haven't already done so, I suggest you test with all your clients mounting from the server using NFS version 2 rather than 3. Note the Solaris clients probably try V3 first and fallback to V2 so you might be able to disable V3 on your server somehow, saving the admin hassle of changing a large number of clients. Of course if you're using an automounter you already have a central point for the change. -- Conrad Minshall ... con...@apple.com ... 408 974-2749 Apple Computer ... Mac OS X Core Operating Systems ... Filesystems Kernel Alternative email address: r...@acm.org. Bother said Pooh as he uninstalled MS Windows. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
