From owner-freebsd-fs@FreeBSD.ORG Wed Feb 20 17:10:02 2008 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEBF616A405 for ; Wed, 20 Feb 2008 17:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B45E913C4CC for ; Wed, 20 Feb 2008 17:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1KHA2gW038054 for ; Wed, 20 Feb 2008 17:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1KHA2gR038053; Wed, 20 Feb 2008 17:10:02 GMT (envelope-from gnats) Date: Wed, 20 Feb 2008 17:10:02 GMT Message-Id: <200802201710.m1KHA2gR038053@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= Cc: Subject: Re: kern/120869: [procfs] 'stat' shows that all files have 0-length when they are actually not empty X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 17:10:02 -0000 The following reply was made to PR kern/120869; it has been noted by GNATS. From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Robert Watson Cc: remko@FreeBSD.org, freebsd-fs@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 Date: Wed, 20 Feb 2008 17:53:52 +0100 Robert Watson 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