Re: [Fwd: [Bug 136] New: FSID returned from statvfs always 0]

[Andrew Morton <akpm@digeo.com>]

Andries Brouwer wrote:
> 
> On Tue, Dec 03, 2002 at 03:53:27PM -0800, Andrew Morton wrote:
> 
> > I've been hit with a bugzilla record alleging that statfs
> > is failing to initialise the statfs.f_fsid field.
> >
> > Can anyone suggest whether we should be putting something in
> > there and if so, what?
> >
> > The submitter suggests using part of the UUID.
> >
> > What is is used for?
> 
> There are system calls statfs (Linux, FreeBSD, SunOS, HPUX, 4.4BSD, not POSIX)
> and statvfs (Solaris, POSIX) that return a struct with a f_fsid field.
> 
> For statvfs the type is unsigned long. (In struct defined in <sys/statvfs.h>.)
> For statfs the type is fsid_t with
> 
>         typedef struct { int val[2]; } fsid_t;
> 
> (In struct defined in <sys/vfs.h>, but FreeBSD uses <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 nonprivileged 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.
> 
> Andries
> 
> [P.S. This is not used anywhere in Linux, I think.]

So it should be persistent across reboots.

SuS mentions it (it's an unsigned long) but there's no word on
what it's for, what it does, etc.

Given that the 2.4 kernel sets it to zero, and that its semantics
are foggy-to-the-point-of-uselessness, I'd suggest that the 2.5
kernel should set it to zero as well.