From owner-freebsd-current Fri May 17 16:40:34 2002 Delivered-To: freebsd-current@freebsd.org Received: from damnhippie.dyndns.org (12-253-177-2.client.attbi.com [12.253.177.2]) by hub.freebsd.org (Postfix) with ESMTP id 8567037B400 for ; Fri, 17 May 2002 16:40:30 -0700 (PDT) Received: from [172.22.42.2] (peace.hippie.lan [172.22.42.2]) by damnhippie.dyndns.org (8.12.3/8.12.3) with ESMTP id g4HNeT6r012165; Fri, 17 May 2002 17:40:30 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630) Date: Fri, 17 May 2002 17:40:30 -0600 Subject: Re: df From: Ian To: Terry Lambert Cc: freebsd-current Message-ID: In-Reply-To: <3CE56361.67EB4549@mindspring.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 05/17/02 14:09, Terry Lambert wrote: > Ian wrote: >> On 05/17/02 10:27, Riccardo Torrini wrote: >>> I manually mount nfs fs after a reboot (current -> stable) and >>> if I do a "df" I got two different output. First time it get >>> garbled, all other times it is aligned. I'm alone? >> >> I looked at the df code because I was intensely curious how this could >> happen. It obtains the list of mounts using a NOWAIT flag, and NFS mount >> info may not be available immediately so it doesn't get included in the >> field width calculations. Then later it re-gets the list of mounts using a >> WAIT flag (unless you used -n on the command line) so this time it has the >> info from NFS filesystems, but it doesn't recalculate the field widths. The >> following patch should fix it without breaking other behaviors, I belive. > > I guess the real question is why the NOWAIT flag results in the > NFS FS's not being included, since the purpose of NOWAIT is to > keep it from hanging indefinitely, not to keep high latency FS's > out of consideration. I leave troublesome questions like that to people who like mucking around in kernel and filesystem internals. I was just looking for something that could cause apparently-stateful behavior across runs of the program and decided I'd found a candidate cause. > Also, one would expect that the FS's that failed "NOWAIT" would > have their details left out, and be marked as "could cause hang > if examined". > >> - if (vfslist != NULL) { >> + if (!nflag) { > > > Uh, think this wants to be: > >> + if (!nflag || vfslist != NULL) { > > The reason is that an explicit list of FS's on the command line > still means "look these up, come hell or high water, and hang, if > you have to". vfslist != NULL means the stats array could have had some entries filtered out of it. Only if nflag is false could the array have grown to have new entries. Still, if the array got filtered, then potentially some fields could be displayed narrower than the first-cut calcs set up, so your suggestion is more-correct. (Naming filesystems on the command line leads to a completely different path thru the code where this change doesn't come into play.) Actually, I now think a more-correct fix would be to have no if statement at all, and just always recalculate the field widths after calling the routine to re-get the stats. The if statement strikes me as a troublesome micro-optimization that smears info about the internal state of the re-get routine's behavior to another outside routine. All to save a couple microseconds. (Consider that this whole problem happened because already the code was assuming the re-get routine wouldn't have changed the stats array if vfslist was NULL, which incorrectly reflects the behavior of the re-get routine.) If it's really important to save these cycles, the recalc of the field widths should move closer to the point at which the raw data is (re-)obtained. But then you start asking yourself questions like "why does it bother to get the list with a NOWAIT then later get the list again with a WAIT instead of just getting it once using the method 'nflag' implies?" and before you know it you're rewriting half the code. :-) -- Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message