Bug 136 - FSID returned from statvfs always 0
Summary: FSID returned from statvfs always 0
Status: CLOSED CODE_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: ext2 (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Andrew Morton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-12-03 14:55 UTC by Colin DuPlantis
Modified: 2006-12-10 06:47 UTC (History)
3 users (show)

See Also:
Kernel Version:
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Formt definition of UUIDs (176 bytes, text/html)
2003-05-24 12:28 UTC, Ren
Details
patch that adds fsid functionality to ext2 and ext3, simple version (1.02 KB, patch)
2003-08-06 10:07 UTC, Danny Milosavljevic
Details | Diff

Description Colin DuPlantis 2002-12-03 14:55:40 UTC
Exact Kernel version: 2.5.50
Distribution:
Hardware Environment: i386(i686 to be exact)
Software Environment: 2.5.50 running on top of mandrake 8.2 distro
Problem Description: statvfs on any device always returns fsid of 0

Steps to reproduce:
Run the following test program, passing it "/home" or whatever:

#include <stdio.h>
#include <sys/statvfs.h>

int main(int argv,
         const char* argc[])
{
  const char *path1 = argc[1];
  struct statvfs buf1;
  if(statvfs(path1,
             &buf1) < 0) {
    return 1;
  }
  printf("FSID of %s is %d\n",
         path1,
         buf1.f_fsid);

  return 0;
}

I marked this bug for ext2, but the same problem exists in ext3 as well.  I was
able to get it to work by adding the following line to super.c:975 in ext2:

memcpy(&buf->f_fsid, &sb->u.ext2_sb.s_es->s_uuid, sizeof(buf->f_fsid));

for ext3, I added at 1892 in super.c:

memcpy(&buf->f_fsid, es->s_uuid, sizeof(buf->f_fsid));

I was not able to test this in a big-endian or a 64-bit environment.  I tested
it only on an i386 32-bit chip.

I apologize if this bug is redundant or otherwise inappropriate.  I searched the
archives and the bug queue, but could find no relevant discussion of this
problem.  Thanks!
Comment 1 Andrew Morton 2003-04-29 16:16:48 UTC
I think we agree that returning some number based on the
filesystem's UUID is appropriate.  But nobody has
ponied up to do the work.

I'll leave it open, for a while.
Comment 2 Ren 2003-05-24 12:28:02 UTC
Created attachment 373 [details]
Formt definition of UUIDs

Colin, your proposed solution to just copy the first 8 bytes of the UUID is
suboptimal, because you'd hit the "version" and "variant" fields of the UUID.
That makes 7 bits which are not really random. :)

Maybe just copying the last 8 bytes would do? Or computing a 64bit hash of the
UUID?
Comment 3 Colin DuPlantis 2003-05-27 07:51:17 UTC
I'm not surprised to learn my suggestion is suboptimal.  Regretfully, its
origins are steeped in ignorance.  I encountered the problem while porting my
employer's app to Linux.  We use the UUID to uniquely identify the devices
attached to a single machine.  That's likely why I didn't notice the shortcomings.

For my purposes, I'm sure the last 8 would do fine.  Thanks :-)
Comment 4 Danny Milosavljevic 2003-07-18 16:25:49 UTC
That bug exists for nfs mounted directories aswell.

Breaks remote fam-oss monitoring.

argh...
Comment 5 Danny Milosavljevic 2003-08-06 10:07:11 UTC
Created attachment 616 [details]
patch that adds fsid functionality to ext2 and ext3, simple version  

this does not take into account accidentially equal fsids, but this is better
than nothing ;)
Comment 6 Nishanth Aravamudan 2006-05-09 14:52:06 UTC
Where do we stand on this bug? No comments in almost 3 years :(

Thanks,
Nish
Comment 7 Danny Milosavljevic 2006-08-12 09:07:44 UTC
I just hit this bug again, when trying to implement a "find_nearest_mountpoint" 
function by statvfs()ing path tails until the fsid changes.

Please, it's more or less a one line fix. Pretty pleeease :)
Comment 8 Danny Milosavljevic 2006-08-12 10:32:25 UTC
btw is there another way to get the ID of a removable media? (like label and 
UUID) 

If not, identification/memorizing a medium would be next to impossible in a 
sane way anyway.
Comment 9 Andreas Dilger 2006-10-11 15:45:07 UTC
You can use "blkid" and "libblkid" to identify devices with (most)
filesystems/swap/RAID on them.  This has been part of e2fsprogs for a long time
already.
Comment 10 Danny Milosavljevic 2006-10-17 11:14:08 UTC
Good to know. 

While this is nice, it's too convoluted. statvfs() is there for things like 
that. 

Plus, blkid does that via some direct device file access magic, which is 
undesireable to say the least (normal users don't have block device file access 
- but should still be able to identify what medium they are writing on).

strace blkid -c /dev/null /dev/hda1
[...]
open("/dev/hda1", O_RDONLY)             = -1 EACCES (Permission denied)

So no go.
Comment 11 Pekka Enberg 2006-12-08 00:32:09 UTC
Fixed for ext2, ext3, and ext4 by commits
e4fca01ea2b41c41a82f4ca3537f6ebc237adde5,
50ee0a32b192902e32a2b596df7ec3496c4bf485, and
960cc398a7a2acfe455b2ec33c64dc6018c83aab respectively.

Note You need to log in before you can comment on or make changes to this bug.