© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
I think I understand what the issue is here. I just don't think that there's much we can do about it...
The stat program is doing a lstat() and that doesn't trigger a submount (LOOKUP_FOLLOW isn't set). So we end up doing a GETATTR call that returns info on the root inode of the /home mount. So the stat() syscall gets the "real" st_ino of /tmp/mnt/home, but the st_dev is still that of the parent (/tmp/mnt).
This is particularly evident here because the root of any ext3/4 filesystem has an st_ino of 2.
I think our options are:
1) fix the kernel to trigger a submount even when LOOKUP_FOLLOW isn't set (quite possibly very hard on performance)
2) fix the kernel to return a bit more info when we have a "potential mountpoint" like this. My suggestion on LKML was to coopt a new st_mode/i_mode bit and use that to indicate that a directory is potentially a new mountpoint if someone were to walk into it
So far, my suggestion hasn't received any feedback upstream.