Messages in this thread | | | Date | Thu, 11 Jun 2015 11:49:46 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH v6] procfs: Always expose /proc/<pid>/map_files/ and make it readable |
| |
On Thu, 11 Jun 2015 14:10:45 +0300 Alexey Dobriyan <adobriyan@gmail.com> wrote:
> On Wed, Jun 10, 2015 at 11:58 PM, Andrew Morton > <akpm@linux-foundation.org> wrote: > > On Tue, 9 Jun 2015 18:39:02 -0700 Calvin Owens <calvinowens@fb.com> wrote: > > > >> On Tuesday 06/09 at 14:13 -0700, Andrew Morton wrote: > >> > On Mon, 8 Jun 2015 20:39:33 -0700 Calvin Owens <calvinowens@fb.com> wrote: > >> > > >> > > Currently, /proc/<pid>/map_files/ is restricted to CAP_SYS_ADMIN, and > >> > > is only exposed if CONFIG_CHECKPOINT_RESTORE is set. > >> > > > >> > > This interface very useful because it allows userspace to stat() > >> > > deleted files that are still mapped by some process, which enables a > >> > > much quicker and more accurate answer to the question "How much disk > >> > > space is being consumed by files that are deleted but still mapped?" > >> > > than is currently possible. > >> > > >> > Why is that information useful? > >> > > >> > I could perhaps think of some use for "How much disk space is being > >> > consumed by files that are deleted but still open", but to count the > >> > mmapped-then-unlinked files while excluding the opened-then-unlinked > >> > files seems damned peculiar. > >> > >> Let's phrase the question a bit more generically: > >> > >> "How much disk space is being consumed by files that have been > >> unlinked, but are still referenced by some process?" > >> > >> There are two pieces to this problem: > >> 1) Unlinked files that are still open (whether mapped or not) > >> 2) Unlinked files that are not open, but are still mapped > >> > >> You can track down everything in (1) using /proc/<pid>/fd/*, and you > >> can use stat() to figure out how much space they're using. > > > > This doesn't work if the mapped file has been unlinked? What does the > > /proc/pid/map_files listing look like for these? > > It says "(deleted)" like /proc/*/exe or any other symlink.
Actually the symlink directs at "/home/akpm/foo (deleted)".
And lo, if you do `stat -L' on the symlink, you get the info for the unlinked-but-still-mmapped inode. I never knew that. And I wouldn't have learned it from the documentation, which is careful to keep all this a secret.
| |