Name
statfs, fstatfs — get file system statistics
Synopsis
#include <sys/vfs.h> /* or <sys/statfs.h> */
int
statfs( |
const char * |
path, |
| |
struct statfs * |
buf); |
int
fstatfs( |
int |
fd, |
| |
struct statfs * |
buf); |
DESCRIPTION
The function statfs()
returns information about a mounted file system. path is the pathname of any
file within the mounted filesystem. buf is a pointer to a
statfs structure defined
approximately as follows:
Nobody knows what f_fsid is supposed to contain
(but see below).
Fields that are undefined for a particular file system are
set to 0. fstatfs() returns the
same information about an open file referenced by descriptor
fd.
RETURN VALUE
On success, zero is returned. On error, −1 is
returned, and errno is set
appropriately.
ERRORS
- EACCES
-
(statfs()) Search
permission is denied for a component of the path prefix
of path. (See
also path_resolution(7).)
- EBADF
-
(fstatfs()) fd is not a valid open
file descriptor.
- EFAULT
-
buf or
path points to
an invalid address.
- EINTR
-
This call was interrupted by a signal.
- EIO
-
An I/O error occurred while reading from the file
system.
- ELOOP
-
(statfs()) Too many
symbolic links were encountered in translating
path.
- ENAMETOOLONG
-
(statfs()) path is too long.
- ENOENT
-
(statfs()) The file
referred to by path does not exist.
- ENOMEM
-
Insufficient kernel memory was available.
- ENOSYS
-
The file system does not support this call.
- ENOTDIR
-
(statfs()) A component
of the path prefix of path is not a
directory.
- EOVERFLOW
-
Some values were too large to be represented in the
returned struct.
CONFORMING TO
Linux specific. The Linux statfs() was inspired by the 4.4BSD one
(but they do not use the same structure).
NOTES
The kernel has system calls statfs(), fstatfs(), statfs64(), and fstatfs64() to support this library
call.
Some systems only have <sys/vfs.h>, other systems
also have <sys/statfs.h>, where the former includes the
latter. So it seems including the former is the best
choice.
LSB has deprecated the library calls statfs() and fstatfs() and tells us to use statvfs(2) and fstatvfs(2) instead.
The f_fsid field
Solaris, Irix and POSIX have a system call statvfs(2) that returns a
struct statvfs
(defined in <sys/statvfs.h>)
containing an unsigned
long f_fsid. Linux, SunOS,
HP-UX, 4.4BSD have a system call statfs() that returns a struct statfs (defined in
<sys/vfs.h>)
containing a fsid_t f_fsid, where fsid_t is defined as
struct { int val[2];
}. The same holds for FreeBSD, except that it
uses the include file <sys/mount.h>.
The general idea is that f_fsid contains some random
stuff such that the pair (f_fsid,ino) uniquely determines a
file. Some OSes use (a variation on) the device number, or
the device number combined with the filesystem type.
Several OSes restrict giving out the f_fsid field to the
superuser only (and zero it for unprivileged users),
because this field is used in the filehandle of the
filesystem when NFS-exported, and giving it out is a
security concern.
Under some OSes the fsid can be used as second
parameter to the sysfs()
system call.
SEE ALSO
stat(2), statvfs(2), path_resolution(7)
Copyright (C) 2003 Andries Brouwer (aeb@cwi.nl)
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.
Since the Linux kernel and libraries are constantly changing, this
manual page may be incorrect or out-of-date. The author(s) assume no
responsibility for errors or omissions, or for damages resulting from
the use of the information contained herein. The author(s) may not
have taken the same level of care in the production of this manual,
which is licensed free of charge, as they might when working
professionally.
Formatted or processed versions of this manual, if unaccompanied by
the source, must acknowledge the copyright and authors of this work.
Modified 2003-08-17 by Walter Harms
Modified 2004-06-23 by Michael Kerrisk <mtk-manpages@gmx.net>
|