[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-btrfs
Subject:    [RFC][PATCH 0/2] btrfs/vfs: Return same device in stat(2) and /proc/pid/maps
From:       Mark Fasheh <mfasheh () suse ! com>
Date:       2011-05-13 23:18:47
Message-ID: 1305328729-9995-1-git-send-email-mfasheh () suse ! com
[Download RAW message or body]

I originally posted about this issue some weeks ago but unfortunately didn't
get a response:

http://comments.gmane.org/gmane.comp.file-systems.btrfs/9682


To recap:

btrfs_getattr() is filling stat->dev with an anonymous device
(for per-snapshot root?):

stat->dev = BTRFS_I(inode)->root->anon_super.s_dev;

but /proc/pid/maps uses the "real" block device:

dev = inode->i_sb->s_dev;


This results in some unfortunate behavior for lsof as it reports some
duplicate paths (except on different block devices). The easiest way to see
this (if your root partition is btrfs):

$ lsof | grep lsof
<snip>
lsof       9238            root  txt       REG               0,19   139736 14478 /usr/bin/lsof
lsof       9238            root  mem       REG               0,17   14478 /usr/bin/lsof (path dev=0,19)


As was noted in my original mail, this winds up breaking userspace software
(zypper in my case).

The following patch series fixes this issue by allowing a file
system to supply a custom method for the device reported in /proc/pid/maps.
It fixes the issue for me, but I'm not 100% sold on the approach taken -
it's an admittedly brute-force solution hence the RFC tag. Any comments are
appreciated and welcome.

Thanks,
	--Mark

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]