[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ale] SLES 11 SP4 df
- Subject: [ale] SLES 11 SP4 df
- From: nbornstein at gmail.com (Niel Bornstein)
- Date: Fri, 26 Aug 2016 12:49:35 -0400
- In-reply-to: <CAFc0yP1Q=iLq2gNnCvudWUJk-7YvDxEdRQpozvpnbkk9CR96bg@mail.gmail.com>
- References: <CAFc0yP1Q=iLq2gNnCvudWUJk-7YvDxEdRQpozvpnbkk9CR96bg@mail.gmail.com>
>From browsing the source code and talking with engineering, it looks
like df calls read_file_system_list() to get the list of mounted
filesystems and calls getmntent() on each one, and then df itself
converts the mount_entry struct into something human-readable. df itself
doesn't go through the filesystems one at a time. So like any other
process, if read_file_system_list() attempts i/o to a filesystem, it
will go into uninterruptible sleep until the i/o completes.
There is a -l option to just show local filesystems, if that helps.
Niel
On 08/25/2016 07:23 PM, Brian Stanaland wrote:
> Has anyone run across this situation?
>
> It seems the df command in sles 11 sp4 stats all the filesystems before
> displaying anything. This means that when it gets stuck on a network
> file system it just stops doing anything. It's waiting for a reply from
> the file system that will never come. The user knows something is wrong
> but if it displayed results as it went along, they'd know which file
> system isn't responding.
>
> --Brian
>
> --
> "Anyone who has never made a mistake has never tried anything new."
> -Albert Einstein
>
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>