kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty

[Dag-Erling Smørgrav]

The following reply was made to PR kern/120869; it has been noted by GNATS.

From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des at des.no>
To: Robert Watson <rwatson at FreeBSD.org>
Cc: remko at FreeBSD.org,  freebsd-fs at FreeBSD.org,  yuri at tsoft.com,  bug-followup at FreeBSD.org
Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty
Date: Wed, 20 Feb 2008 17:53:52 +0100

 Robert Watson <rwatson at FreeBSD.org> writes:
 > Just as two data points here: Solaris attempts to provide coherent
 > file sizes in /proc (at least to the extent that tried a few for
 > objects where it is remotely possible), and the Linux 2.6.12 kernel I
 > have on a box locally basically doesn't.
 
 Correct; neither to more recent Linux kernels.  2.6.12 is ancient!  :)
 
 > My view is that it's a synthetic file system with data that varies
 > dynamically at runtime, and that while it wouldn't hurt to produce
 > file size information that's correct, it's quite a bit of work to do
 > so and that I wouldn't prioritize it above other, more critical things
 > that need to happen.
 
 Most of the time, it can't be done.
 
 Some of the files in /proc have a fixed size (/proc/$$/{,db,fp}regs for
 instance), but others have highly variable content, and there is no
 other way to figure out how large it is than to generate it.  Even then,
 it may change between the stat(2) call and the read(2) call.  A good
 example is /proc/$$/status, which among other things contains a textual
 representation of the process's user and system time in seconds and
 microseconds.  A process reading its own /proc/$$/status will get
 inconsistent results.
 
 As for /proc/$$/map, the simple act of malloc()ing a buffer for it may
 change its contents if jemalloc needs to mmap() a new chunk.
 
 Some files actually *don't* have any size, such as /proc/$$/ctl, which
 is write-only.
 
 > We should certainly evaluate any patches that come in for possible
 > inclusion, assuming they don't muck up the internals of procfs too
 > much; it's not clear to me if they necessarily do so or not.
 
 I'll be glad to review and commit patches, but procfs doesn't have any
 internals to speak of, all it does is provide content for pseudofs.
 
 DES
 --=20
 Dag-Erling Sm=C3=B8rgrav - des at des.no