Date: Fri, 17 May 2002 13:09:05 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Ian <freebsd@damnhippie.dyndns.org> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: df Message-ID: <3CE56361.67EB4549@mindspring.com> References: <B90A9CA0.D159%freebsd@damnhippie.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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".
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CE56361.67EB4549>