Bug 114875

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.