From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andries Brouwer Subject: Re: [Fwd: [Bug 136] New: FSID returned from statvfs always 0] Date: Wed, 4 Dec 2002 04:25:11 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20021204032511.GA7646@win.tue.nl> References: <3DED43F7.AD396584@digeo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "linux-fsdevel@vger.kernel.org" , kernel@whiskerfish.com Return-path: To: Andrew Morton Content-Disposition: inline In-Reply-To: <3DED43F7.AD396584@digeo.com> List-Id: linux-fsdevel.vger.kernel.org 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 .) For statfs the type is fsid_t with typedef struct { int val[2]; } fsid_t; (In struct defined in , but FreeBSD uses .) 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.]