Bug 136
| Summary: | FSID returned from statvfs always 0 | ||
|---|---|---|---|
| Product: | File System | Reporter: | Colin DuPlantis (kernel) |
| Component: | ext2 | Assignee: | Andrew Morton (akpm) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | bunk, danny_milo, nacc |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
Formt definition of UUIDs
patch that adds fsid functionality to ext2 and ext3, simple version |
||
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. 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?
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 :-) That bug exists for nfs mounted directories aswell. Breaks remote fam-oss monitoring. argh... 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 ;)
Where do we stand on this bug? No comments in almost 3 years :( Thanks, Nish 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 :) 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. 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. 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.
Fixed for ext2, ext3, and ext4 by commits e4fca01ea2b41c41a82f4ca3537f6ebc237adde5, 50ee0a32b192902e32a2b596df7ec3496c4bf485, and 960cc398a7a2acfe455b2ec33c64dc6018c83aab respectively. |
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!