On Mon, Jul 08, 2013 at 11:54:46PM +0200, David Sterba wrote: > On Thu, Jul 04, 2013 at 01:51:38PM +0400, Andrew Vagin wrote: > > We are not first who suffer from this problem: > > https://bugzilla.redhat.com/show_bug.cgi?id=711881 > > http://marc.info/?l=linux-btrfs&m=130074451403261 > > https://bugzilla.openvz.org/show_bug.cgi?id=2653 > > > And about 2 years ago Mark Fasheh tried to fix this problem: > > http://thr3ads.net/btrfs-devel/2011/05/2346176-RFC-PATCH-0-2-btrfs-vfs-Return-same-device-in-stat-2-and-proc-pid-maps
And basically nobody cared :/ > > Eric Biederman sugested to not create a new method and use vfs_getattr, > > but here is a few problems: > > * fanotify doesn't have dentry, but its fdinfo contains device. > > * vfs_getattr can fail and which device should be shown in this case? > > * vfs_getattr gets much more parameters, so here is a question about > > performance degradation. > > > > So I have a question: Can two inodes from different subvolumes have > > equal inode numbers? > > Yes, subvolumes are separate inode number spaces. > > > If someone have any suggestions how to fix this problem or any > > explanation why this is not a problem at all, please write here. > > The xstat syscall instead of the potentially heavyweight vfs_getattr > could fix that, but it's not merged. For suse kernels we've taken the > hackish approach of patching fs/proc/task_mmu.c:show_map_vma() (and the > nommu variant) and use vfs_getattr only for btrfs. > > http://kernel.opensuse.org/cgit/kernel-source/tree/patches.suse/btrfs-use-correct-device-for-maps.patch?id=2434fa6ee93a83b117461eb13f24272606677fec > > Only a temporary and not upstreamable solution, but without it the core > packaging tool zypper would not work correctly. As far as I can tell we'll be carrying this patch until a better solution is possible. When that will happen, I don't know. --Mark -- Mark Fasheh -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
