From owner-freebsd-current Mon Jan 26 23:21:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA28877 for current-outgoing; Mon, 26 Jan 1998 23:21:49 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from thunderdome.plutotech.com (root@thunderdome.plutotech.com [206.168.67.122]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA28869; Mon, 26 Jan 1998 23:21:43 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by thunderdome.plutotech.com (8.8.7/8.8.5) with ESMTP id AAA05609; Tue, 27 Jan 1998 00:21:42 -0700 (MST) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id AAA02087; Tue, 27 Jan 1998 00:21:36 -0700 (MST) Message-Id: <199801270721.AAA02087@panzer.plutotech.com> Subject: Re: Another observation on -current and NFS In-Reply-To: <199801270626.BAA27440@dyson.iquest.net> from "John S. Dyson" at "Jan 27, 98 01:26:45 am" To: dyson@FreeBSD.ORG Date: Tue, 27 Jan 1998 00:21:36 -0700 (MST) Cc: wpaul@skynet.ctr.columbia.edu, grog@lemis.com, current@FreeBSD.ORG, dyson@FreeBSD.ORG From: Kenneth Merry X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk John S. Dyson wrote... > Bill Paul said: > > > > John Dyson made a couple of commits this weekend which I _thought_ would > > fix this thing; I gave him a sample program that triggers the bug to help > > him track it down. Assuming that he got my sample program to work, I'm > > guessing there's more than one way to trigger the condition. > > > The fixes explicitly fixed the problem with the test code. There indeed > must be more problems. I will look at it while it is still in my brain-cache. Well, FWIW, I'll share my experiences with -current's NFS today. I have noticed the 'strip' problem happening as well for the past couple of months at least. In my experience, the client machine (i.e. the one doing the strip) wouldn't hang, but the kernel it generated wouldn't boot. I tried stripping a kernel today over NFS (between a client and server that are both current as of today) and the kernel booted just fine. I have also been having link troubles when compiling/linking programs over NFS. (the linker wouldn't find functions that were indeed in the libraries..) Those problems are gone as of today. There is one interesting NFS problem I can report, though. Apparantly there is a problem with access(2) and files on NFS mounted filesystems. (one of my co-workers discovered it) Here is a program to test permissions: (I didn't write it, I just made a minor modification...) ======================================================================== #include #include void usage ( void ) { fprintf(stderr, "usage: testAccess \n"); fprintf(stderr, "Where the inclusive or of some of\n"); fprintf(stderr, "F_OK, R_OK, W_OK, or X_OK\n"); exit(1); } main ( int argc, char *argv[] ) { int indx; int mode = 0; char *tmpPtr; if (3 != argc) { usage(); } for (tmpPtr = argv[1]; 0 != *tmpPtr; tmpPtr++) { int digit; if (!isdigit(*tmpPtr)) { usage(); } digit = *tmpPtr - '0'; if (7 < digit) { usage(); } mode = (mode << 3) + digit; } printf("Access returns %d for file %s and mode %o\n", access(argv[2], mode), argv[2], mode); } ======================================================================== And here is what happens: On a local filesystem, the program behaves as expected: ==================================================== {roadwarrior:/usr/home/ken/src/yates:162:0} ls -la foo ---------- 1 ken wheel 0 Jan 26 18:35 foo {roadwarrior:/usr/home/ken/src/yates:163:0} ./testAccess 777 foo Access returns -1 for file foo and mode 777 ==================================================== The file foo has no permissions, so access(2) should return -1. When the same filesystem is NFS mounted, the program does not behave as expected: ==================================================== {bladerunner:/usr2/home/ken/src/yates:34:0} ls -la foo ---------- 1 ken wheel 0 Jan 26 18:35 foo {bladerunner:/usr2/home/ken/src/yates:35:0} ./testAccess 777 foo Access returns 0 for file foo and mode 777 ==================================================== In any case, this looks like a bug to me, but if it's just operator error, please let me know. As far as I can tell, though, the major (and in some cases show stopping) NFS bugs in -current have been fixed. Thanks John! Ken -- Kenneth Merry ken@plutotech.com