3

In an environment with automounted home directories, such that the same filesystem exported by a fileserver may be mounted multiple times on the client, I would like to authoritatively be able to identify whether two mountpoints are in fact the same filesystem. That is, if the remote server exports:

/home

And the local client has:

# mount
fileserver:/home/l/lars on /home/lars type nfs (rw...)
fileserver:/home/b/bob on /home/bob type nfs (rw...)

I am looking for a way to identify that both /home/lars and /home/bob are in fact the same filesystem. In theory this is what the fsid result of the statvfs structure is for, but in all cases, for both local and remote filesystems, I am finding that the value of this structure member is 0.

Is this some sort of client-side issue? Or do most modern NFS servers simply decline to provide a useful fsid?

The end goal of all of this is to robustly interpret the output from the quota command for NFS filesystems. For example, given the example above, running quota as myself may return something like:

Disk quotas for user lars (uid 6580): 
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
otherserver:/vol/home0/a/alice
                     12  52428800 52428800               4  4294967295 4294967295        
fileserver:/home/l/lars
                9353032  9728000 10240000          124018       0       0        

...the problem here being that there exists a quota for me on otherserver which is visible in the results of the quota command, even though my home directory is actually on a different device. My plan was to look up the fsid for each mountpoint listed in the quota output and check to see if it matched the fsid associated with my home directory.

It looks like this won't work, so...any suggestions?

larsks
  • 43,623
  • 14
  • 121
  • 180

1 Answers1

4

You can use the mountpoint command. The -d switch prints the major/minor device number of the mount point to stdout.

In your case, compare the output of mountpoint -d /home/lars to mountpoint -d /home/bob.

[root@Fruity ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2             9.9G  2.5G  7.0G  26% /
/dev/sda1              97M   43M   50M  47% /boot
/dev/sda7             2.0G   68M  1.9G   4% /tmp
/dev/sda3             9.9G  2.8G  6.6G  30% /usr
/dev/sda6             6.0G  1.1G  4.6G  19% /var
/dev/sdb1             400G  263G  138G  66% /data
/dev/sdc1             150G  122G   29G  82% /images
nfs001:/data/chain    36G  1.2G   35G   4% /data/chain
nfs001:/data/src      36G  1.2G   35G   4% /data/src


[root@Fruity ~]# mountpoint -d /data/chain/
0:19

[root@Fruity ~]# mountpoint -d /data/src/
0:19

[root@Fruity ~]# mountpoint -d /data/
8:17
ewwhite
  • 197,159
  • 92
  • 443
  • 809
  • That's exactly what I'm looking for. More importantly, looking at the `strace` output for `mountpoint`, it reminds me that I can just call `stat()` on a filesystem and get use the `st_dev` member, which is exactly what `mountpoint` is doing. Thanks! – larsks Mar 20 '12 at 03:14
  • Excellent. Good to know that works. – ewwhite Mar 20 '12 at 17:22
  • 1
    `st_dev` customarily uniquely identifies a device but is not *required* to do so. For example some POSIX-like implementations set `st_dev=-1` for all NFS filesystems. To be certain you need to use the combination of `st_dev` and the `st_ino` value of the top directory in the filesystem. And that is just what `mountpoint` is doing. Also bear in mind that these techniques do not work for AFS. – James Youngman Mar 22 '12 at 00:50