Date: Mon, 25 Aug 2003 21:39:11 -0700 From: David Schultz <das@freebsd.org> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: freebsd-current@freebsd.org Subject: Re: 64 bit quantities in statfs ? Message-ID: <20030826043911.GA3361@HAL9000.homeunix.com> In-Reply-To: <200308251542.h7PFgXIV093334@khavrinen.lcs.mit.edu> References: <200308181854.h7IIshJg098625@apollo.backplane.com> <20030824230439.GA4954@HAL9000.homeunix.com> <200308251542.h7PFgXIV093334@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 25, 2003, Garrett Wollman wrote: > <<On Sun, 24 Aug 2003 16:04:40 -0700, David Schultz <das@freebsd.org> said: > > > Yep, looks broken. In the POSIX standard, the functionality of > > statfs() is provided by statvfs(), so implementing the latter may > > be a way out that doesn't involve breaking any ABIs. > > statfs() is a lot more useful interface than statvfs(). I'd like to > keep statvfs() as the ``standard'' interface, rather than extending it > to cover all of the information that statfs() has. > > In order to grow statfs() we need to rev libc. It might be > appropriate to do that in the 5.2 time frame, if we are still > anticipating that 5.2 will be the -stable crossover point. RE team? We can't fix statfs() until 6.0. statvfs() is potentially just as useful, and it doesn't suffer from the same problems. Despite being underspecified by the standard, many systems, e.g. Solaris, make it convey at least as much information as statfs().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030826043911.GA3361>