On 2017-02-08 17:08, Bernhard Voelker wrote: > On 02/08/2017 04:49 PM, Dale R. Worley wrote: >> Bernhard Voelker <[email protected]> writes: >>>> /proc/self/mountinfo for "/" has 0:18, but stat shows 0:20 >> >>>> /proc/self/mountinfo for "/boot" has 0:18, but stat shows 0:43 >> >>> Okay, so for btrfs, the cache function obviously doesn't work based on >>> st_dev. >>> I have to think about how to work around that - it's a pity we have to >>> single out special file system types ... >> >> I'm no expert, but that sounds like an outright error in btrfs (or >> something). Should we hack find to compensate for that? > > I also consider this issue in btrfs clearly as a design bug
For sure it is a btrfs bug (see the link which I posted in my other reply). However this is not a "design bug". There is a rationale behind this choice. Because btrfs is capable to writable snapshot, it is possible that in the same filesystem two files have the same inode-number even tough these are/became different. So btrfs has to give to every subvolume a different device-id, to differentiate files from the original one to the snapshot one. Unfortunately this is quite simple at "stat(2)" level; it is more difficult to obtain at vfs level. This leads to some idiosyncrasies between /proc/self/mountinfo and stat(2) - along > others, e.g. you can search for "df not working for btrfs" - but maybe > we can weaken the problems for find. The idea is to build the cache > based on the magic FS number instead of the major/minor. I'll need > some quiet minutes on the weekend to think about it. > > Have a nice day, > Berny > > -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 _______________________________________________ Findutils-patches mailing list [email protected] https://lists.gnu.org/mailman/listinfo/findutils-patches
