It may need to lstat the actual mount point on its the file system where it is mounted. I.e., that's going to be an inode on that file system. That could also be why you get hangs at times. The lstat can hold the call if the file system is unavailable.
But it will still get the information from the Superblock IIRC. The free block and inode counts are in the Superblock. It is regularly updated, although possibly delayed in some implementations (e.g., multi-master lock/distributed). ________________________________ From: John Haxby <john.ha...@gmail.com> Sent: Wednesday, November 16, 2011 3:18 PM On 16 November 2011 14:54, Bryan J Smith <b.j.sm...@ieee.org> wrote: I thought "df" just reads superblock information, as inode file systems store free blocks and inode counts (and FAT file systems have similar structures)? This came up on LinkedIn last week IIRC, and after the same comment, I verified with strace that df was calling statfs64 with "[MAGIC_]SUPER" constants. > >Did you mean "du" with regards to dentry/lstat? > > >-- Bryan > >P.S. As far as scripting, the strace (or the source code of df for that >matter) will also give you many of the calls "df" actually makes to get this >information from the superblock. I wondered how df found the mount point for "df <dir>" and I found it called lstat() several times, presumably to find a match against the entry in /etc/mtab. I didn't dig into the code to find out exactly what it was doing. The call for the actual disk space is still statfs(). I've had a few goes at getting disk space for various things over the years: df itself does hang sometimes, statfs() can do, but is sometimes less problematic and quicker. df -P <dir> is probably the simplest start, if it gives problems you can always try something else. _______________________________________________ rhelv5-list mailing list rhelv5-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv5-list
