Date: Wed, 20 Feb 2008 17:53:52 +0100 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Robert Watson <rwatson@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, remko@FreeBSD.org, yuri@tsoft.com, bug-followup@FreeBSD.org Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty Message-ID: <86ve4jvaan.fsf@ds4.des.no> In-Reply-To: <20080220132030.S14519@fledge.watson.org> (Robert Watson's message of "Wed\, 20 Feb 2008 13\:32\:30 %2B0000 \(GMT\)") References: <200802201208.m1KC8MHi009288@freefall.freebsd.org> <20080220132030.S14519@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson <rwatson@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@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86ve4jvaan.fsf>