Bugzilla – Bug 114875
Subfs mount points have wrong st_dev
Last modified: 2006-03-02 22:39:25 UTC
The symptom of this bug is described in bug #114473. Basically, subfs mounts don't respect the unix convention that /media/MOUNTPOINT has the same st_dev as /media/MOUNTPOINT/somefile.txt. Some software like Midnight Commander and gnome-vfs test the st_dev to find file system boundaries. When I plug in an USB drive, it appears under /media/FOO. This happens: 1. /media has st_dev = 0x314, which is device major 3 (IDE hard disk) 2. /media/FOO has st_dev = 0x013, which is device major 0 (???) 3. /media/FOO/somefile.txt has st_dev = 0x811, which is device major 8 (SCSI, which makes sense for USB drives) Also, it seems like the st_dev of /media/FOO changes a few times right after the USB drive is plugged in. See bug #114473 for the details of this.
Now that I know that submount repeatedly tries to umount() until it succeeds, I wonder if this bug is due to that behavior. I recall that Beagle or something had a lot of trouble with CD-ROMS being unmounted at inconvenient times, but I can't find that bug - does anyone know the bug number? I guess the problem is similar there.
I've now confirmed that comment #1 is correct. If I stat() /media/FOO/somefile.txt and immediately stat() /media/FOO, their st_dev values are the same. If I stat() /media/FOO/somefile.txt, wait a second or two, and then stat /media/FOO, the st_dev values are different. With the current architecture of submount: 1. There's really no way this race condition can be avoided. One could think that a workaround is to stat() any file in the volume right before stat()ing the mount point itself, but what if the volume is totally empty, and thus we can't stat() any files inside it? 2. Even if there's a file to stat(), the process could be interrupted for a long time before it can issue the stat() for the mountpoint. What happens in bug #114473 is as follows: - One inserts a USB stick. - Nautilus gets notified that a volume was mounted (/media/FOO). But this is a submount, so it is not really mounted from the perspective of the kernel. Thus, st_dev for /media/FOO is the 0x013 device number from submount. Nautilus (well, gnome-vfs2, really) keeps this device number around. - Gnome-vfs2 uses some heuristics to determine that the trash location for the newly-mounted volume is /media/FOO/.Trash-federico. It stat()s that file. When comparing the st_dev of that with the st_dev it kept around from the previous paragraph, it fails. Seriously, software *will* assume that the device number for a mount point will stay the same for the duration of the mount, and that files inside that mount point will have the same device number.
Chris, another candidate for your team
I'll take this one. Here's the quick rundown: st_dev (0, #) is due to the use of get_sb_nodev, which sets up a superblock for filesystems without a device mapping. The # component can vary with every mount. This is normal. We can work around the back-and-forth st_dev values by caching the dev number after a successful mount and keeping it around. This means that the device number will change after the first mount, but I don't see this as an issue since it could be still considered a separate filesystem until then anyway. If the mount starts failing, we can restore the subfs dev number, since the device has gone away. I'll have a patch later tonight.
Thanks for looking into this, Jeff :)
Created attachment 48869 [details] cache the dev from the sub-filesystem
Quick point on the attachment: It will cache the device number, but nothing else. Things like link count, size, [acm]time will still change. I can cache the rest at fairly low cost, but it can end up being just as invalid as the uncached data if the user moves the usb stick to a different machine, modifies the filesystem, and brings it back to the original machine. Opinions?
If the user removes the stick the stick is complete unmounted, there is also no more subfs mount. I don't see a problem. We should cache no information in the case if the subfs mount is unmounted.
True, if the subfs mount goes away there is nothing left to cache -- there is no place to cache it. The problem is that subfs is not inherently linked to hal/hotplug. The mount point only goes away if hal/hotplug is in the picture to umount and remove the directory. The user is free to create subfs mounts manually. Unfortunately, we don't really have any way around this. We either mount the fs every time stat() requires data, which means that ls -la /media will take forever. Or, we cache stale data, which will result in the behavior this bug complains about -- but only on manually created subfs mounts. I'm not a fan of creating specialized behavior, but it's the only way we can fix this bug.
Created attachment 48974 [details] cache stat data from subfs sub-mount's root dir
Hm ... I'm not completely sure, but HAL maybe try to unmount the device also if it was not mounted by hald-subfs-mount. IMO hal always try to umount a mounted device if he get the message that the device is removed.
subfs has been killed off in CODE10. Closing WONTFIX.