James Bottomley: > I realised as I was trimming down the vestigial inode properties in the > patch that actually shiftfs does use the i_ino from the underlying for > userspace. The reason why is that it comes from the getattr call in > stat and that's fully what the underlying filesystem returns (including > the inode number). Let me make sure. - shiftfs has its own inode, but it will never be visible to userspace. - the inode attr visible to users are equivalent to the underlying one, includeing dev:ino pair. right? If so, I am afraid it will make users confused. The dev:ino pair is a system-wide identity, but shiftfs creates the same dev:ino pair with different owner. Though I don't know whether the actual application or LSM exists or not who will be damaged by this situation. For git-status case which I wrote previously, it might not be a problem as long as dev:ino is unchanged from git index. But such filesystem looks weird. J. R. Okajima
