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

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

[Andrew Morton]

I've been hit with a bugzilla record alleging that statfs
is failing to initialise the statfs.f_fsid field.

This is that case in both 2.4 and 2.5.  It seems that XFS
puts something in there.

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?

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

[Stephen Lord]

On Tue, 2002-12-03 at 17:53, Andrew Morton wrote:
> I've been hit with a bugzilla record alleging that statfs
> is failing to initialise the statfs.f_fsid field.
> 
> This is that case in both 2.4 and 2.5.  It seems that XFS
> puts something in there.
> 
> 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?

Not totally sure, rpc.mountd.c copies it around. XFS actually puts a
dev_t in it, I do not off the top of my head (or cscopes head for that
matter) see any consumers of it, but I think it should at least be
unique among filesystems on a host.

Steve

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

[Andries Brouwer]

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.]

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

[Andrew Morton]

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.

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

[Bryan Henderson]

>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.

I agree that you can get away with setting it to zero in 2.5, but why not
do a lot better?  Its semantics are really pretty clear:  It uniquely
identifies a filesystem.  It's the implementation that is foggy because it
is impossible to implement 100% as defined.  So various systems have
various approximations of it.  Linux's approximation -- always zero -- is
the worst.

Device number would be a step up.  It has a big problem with
non-device-based filesystems, and even on device-based filesystems, the
device number of a device can change and the contents of a device can
change.  And of course it's never unique across systems.

UUID would also be better than zero.  Its main problem is that not all
filesystems have one.

Ideally, it would be a combination of filesystem type (maybe a hash of the
filesystem type name) plus something returned by a get_fsid VFS call.
(Said VFS call exists on many systems anyway because it is used by the NFS
server to construct a file handle, but I believe Linux's NFS direction is
based on the idea that an NFS file handle shouldn't identify a filesystem
at all, but rather an export, so Linux doesn't have it).

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

[H. Peter Anvin]

Followup to:  <20021204032511.GA7646@win.tue.nl>
By author:    Andries Brouwer <aebr@win.tue.nl>
In newsgroup: linux.dev.fs.devel
> 
> The general idea is that f_fsid contains some random stuff such that
> the pair (f_fsid,ino) uniquely determines a file.
> 

This, of course, is the exact POSIX definition of the st_dev part of
struct stat: (st_dev, st_ino) uniquely identifies the file.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

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

[Andries Brouwer]

On Mon, Dec 09, 2002 at 02:15:12PM -0800, H. Peter Anvin wrote:

> > The general idea is that f_fsid contains some random stuff such that
> > the pair (f_fsid,ino) uniquely determines a file.

> This, of course, is the exact POSIX definition of the st_dev part of
> struct stat: (st_dev, st_ino) uniquely identifies the file.

Yes, but the difference is that (st_dev, st_ino) only identifies
the file within a single machine, and may stop working when you
have NFS mounts.

The traditional implementations use st_dev and NFS filehandles
and a hash of the filesystem type.

Andries

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

[Andrew Morton]

Andries Brouwer wrote:
> 
> On Mon, Dec 09, 2002 at 02:15:12PM -0800, H. Peter Anvin wrote:
> 
> > > The general idea is that f_fsid contains some random stuff such that
> > > the pair (f_fsid,ino) uniquely determines a file.
> 
> > This, of course, is the exact POSIX definition of the st_dev part of
> > struct stat: (st_dev, st_ino) uniquely identifies the file.
> 
> Yes, but the difference is that (st_dev, st_ino) only identifies
> the file within a single machine, and may stop working when you
> have NFS mounts.
> 
> The traditional implementations use st_dev and NFS filehandles
> and a hash of the filesystem type.
> 

If this feature is to have any value, should not the fsid remain stable
as the disk gets moved around the machine?

I'm not sure I saw sufficient solidity in this discussion to be able to
generate&justify a patch.

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

[Bryan Henderson]

>If this feature is to have any value, should not the fsid remain stable
>as the disk gets moved around the machine?

To have _any_ value would be an overstatement.  Today's FSID (always zero)
has no value.  An FSID that works only in machines where the disks never
move would have more value than that.

But as long as we're talking about designs that solve the entire problem,
don't forget this aspect too:  A perfect FSID must be stable as the
filesystem is moved from one disk to another while the disks stay put.
And, more importantly, must change when you replace the contents of a disk
with a new or different filesystem.

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

[H. Peter Anvin]

Bryan Henderson wrote:
> 
> To have _any_ value would be an overstatement.  Today's FSID (always zero)
> has no value.  An FSID that works only in machines where the disks never
> move would have more value than that.
> 
> But as long as we're talking about designs that solve the entire problem,
> don't forget this aspect too:  A perfect FSID must be stable as the
> filesystem is moved from one disk to another while the disks stay put.
> And, more importantly, must change when you replace the contents of a disk
> with a new or different filesystem.
>

I.e. it's the UUID of the filesystem (if one exists.)

	-hpa