SUMMARY: statfs system call

From: Larry Chin (
Date: Fri Aug 14 1992 - 12:11:28 CDT

Sorry it has take me a while to post this, I've been totally swamped of late.

------------------------------- Original Query -----------------------------

The function statfs(2) it returns the filesystem ID, which is an array of
two longs (long [2]).

Does anyone have any ideas what these two longs represent ? None of the SUN
doc including answerbook gives a clue.


First of all thanks to:
skipnyc!skipsun! (Skip Gilbrech) (Brad Walker)
Mike Raffety <> (Rod Livingood)
kevins@corn.Japan.Sun.COM (Kevin Sheehan {Consulting Poster Child})
Calum Mackay <>

Of these six replies:
Two say the first long is the device id and the second is the filesystem type.
One says the longs are major and minor device numbers.
One says they are actually unused and unmaintained.
One says major/minor number and filesystem type
One says they are handles to differentiate the virtual filesystems.

I am inclined to go with the replies that indicate device id and filesystem
type, since my own experiments point in this direction. In addition while the
replies were varied they were all along the same track. Despite this however
I am a bit leery about actually using these return parameters both because of
the reply indicating they are "unused and unmaintained" and because I cannot
find any doc on them. In the past when I have come across something that is
vaguely documented or documented only in passing, it has meant that whatever
it is, is not supported or fully supported.

I think, in this case I will simply add the knowledge gained here to my store
of things to remember and avoid using the parameters - just in case, who knows
what will happen with the next OS release.

The following is the text of all the replies. Thanks to all who took the time
to reply, your help is appreciated more than you know.

Larry Chin {} CCH Canadian Ltd.
System Administrator 6 Garamond Court
Research and Development Don Mills, Ontario.
(416) 441-4001 ext. 349 M3C 1Z5

Life is a whim of several billion cells to be you for a while.

-------------------------- Text of Replies ------------------------------------
>From skipnyc!skipsun! (Skip Gilbrech):

>The function statfs(2) it returns the filesystem ID, which is an array of two longs (long [2]).
>Does anyone have any ideas what these two longs represent ? None of the SUN
>doc including answerbook gives a clue.

I just did a little experimentation (see below) and it seems the first
long is the device id, the same as st_dev in struct stat, at least on
4.2 filesystems.

The second seems to correspond to the filesystem type as
defined in /usr/include/sys/mount.h:

#define MOUNT_UFS 1
#define MOUNT_NFS 2
#define MOUNT_PC 3
#define MOUNT_LO 4
#define MOUNT_TFS 5
#define MOUNT_TMP 6

at least on the filesystems I tried (/ = 4.2, /tmp = tmp, /skipnyc = nfs)

% statfs /
st_dev: 1816

f_fsid.val[0]: 1816
f_fsid.val[1]: 1

% statfs /tmp
st_dev: -30976

f_fsid.val[0]: 0
f_fsid.val[1]: 6

% statfs /skipnyc
st_dev: -32256

f_fsid.val[0]: 0
f_fsid.val[1]: 2

/* statfs.c: */

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/vfs.h>

main(argc, argv)
int argc;
char **argv;
    struct stat s;
    struct statfs sf;

    if (stat(argv[1], &s) == 0)
        printf("st_dev: %10d\n", s.st_dev);
/* printf("st_ino: %10d\n", s.st_ino); */
/* printf("st_mode: %10d\n", s.st_mode); */
/* printf("st_nlink: %10d\n", s.st_nlink); */
/* printf("st_uid: %10d\n", s.st_uid); */
/* printf("st_gid: %10d\n", s.st_gid); */
/* printf("st_rdev: %10d\n", s.st_rdev); */
/* printf("st_size: %10d\n", s.st_size); */
/* printf("st_atime: %10d\n", s.st_atime); */
/* printf("st_mtime: %10d\n", s.st_mtime); */
/* printf("st_ctime: %10d\n", s.st_ctime); */
/* printf("st_blksize: %10d\n", s.st_blksize); */
/* printf("st_blocks: %10d\n", s.st_blocks); */

    if (statfs(argv[1], &sf) == 0)
/* printf("f_type: %10d\n", sf.f_type); */
/* printf("f_bsize: %10d\n", sf.f_bsize); */
/* printf("f_blocks: %10d\n", sf.f_blocks); */
/* printf("f_bfree: %10d\n", sf.f_bfree); */
/* printf("f_bavail: %10d\n", sf.f_bavail); */
/* printf("f_files: %10d\n", sf.f_files); */
/* printf("f_ffree: %10d\n", sf.f_ffree); */
        printf("f_fsid.val[0]: %10d\n", sf.f_fsid.val[0]);
        printf("f_fsid.val[1]: %10d\n", sf.f_fsid.val[1]);

From: (Brad Walker)

the statfs.f_fsid.val[0] contains info about where the specific mount
is. the statfs.f_fsid.val[1] contains what type of mount this filesystem
was. The info in statfs.f_fsid.val[1] is a number that is defined in
<sys/mount.h>. It will be of the form MOUNT_<file system type>. For example,
if you were to do a statfs of a UFS file system you would see the following:

1) statfs.f_fsid.val[0] would contain the dev_t of the device for this f/s
2) statfs.f_fsid.val[1] would contain MOUNT_UFS

In every filesystem there is a mount.h. For UFS it's located in <ufs/mount.h>
In this file is a struct mount. statfs.f_fsid.val[0] == the m_dev field.
And statfs.f_fsid.val[1] equals the MOUNT_<file system type> that is
contained in <sys/mount.h>

From: Mike Raffety <>

I'm pretty sure it includes the major and minor device numbers for the
block device the filesystem resides on. Try experimenting around with
it a bit. Otherwise, try BSD source code.

From: (Rod Livingood)

  From fs.h.

/* a unique id for this filesystem (currently unused and unmaintained) */
/* In 4.3 Tahoe this space is used by fs_headswitch and fs_trkseek */
/* Neither of those fields is used in the Tahoe code right now but */
/* there could be problems if they are. */
        long fs_id[2]; /* file system id */


From: kevins@corn.Japan.Sun.COM (Kevin Sheehan {Consulting Poster Child})

A quick look at the results leads to the guesses of:

val[1] is filesystem type - 1 for UFS, 2 for NFS.
val[0] is:
        major/minor number of disk for UFS
        mounted FS number for NFS (first mount is 0, second is 1...)


From: Calum Mackay <>

I believe that this identifier is used as a handle to differentiate between
the many virtual filesystems that may be mounted on a system - ie it is used
much like a file descriptor, but at the VFS level, in calls that access the


This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:47 CDT