Date: Wed, 7 Mar 2007 16:38:31 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-hackers@FreeBSD.ORG, freebsd-hackers@adam.gs Subject: Re: FreeBSD available disk space Message-ID: <200703071538.l27FcVBG036009@lurza.secnetix.de> In-Reply-To: <4D3F70BA-53C3-4A22-99F4-728592F2DB84@adam.gs>
next in thread | previous in thread | raw e-mail | index | archive | help
Adam Jacob Muller wrote:
> When using php's disk_free_space() function to determine the amount
> of free space on a partition that has a negative amount of free
> space, PHP returns an unreasonably large number, for example:
>
> > > [root@cube]# php -r 'var_dump(disk_free_space("/some/partition/
> > > with/negative/free/space"));'
> > > float(3.7778931863E+22)
>
> this is the comment from one of the PHP developers who has been
> helping me to debug this issue:
>
> > Well, this is actually quite interesting.
> > The problem is that according to POSIX statvfs struct's field
> > f_bavail must be <unsigned long>.
> > But FreeBSD stores negative values in this field and I don't see
> > any hint on how to detect if this is a negative value or just a
> > huge positive one.
> > I can of course cast it to signed long, but that would effectively
> > break it on other platforms, which do conform POSIX standard and do
> > not store negative values in unsigned variables.
> >
> > I guess FreeBSD developers might help here, since that should be a
> > known problem for them.
>
> as well as:
>
> > I can see that libstatgrab uses #ifdef's for all *BSD flavours and
> > casts f_bavail to (long long).
> > Not sure if this is the correct solution, my previous suspicions
> > that it may not work with really big filesystems still aply.
Well, POSIX doesn't specify at all how the values are to
interpreted. It's up to the implementation to fill them
with numbers that are useful, and the FreeBSD developers
decided that the f_bavail value could be negative, so they
reflect the numbers from the df(1) output correctly.
Therefore, FreeBSD is in conformance with the strict letter
of the POSIX standard.
One possible solution would be to look at both the f_bfree
and f_bavail numbers. If the former is less than the
latter, then f_bavail obviously needs to be interpreted as
a signed value.
But even simply interpreting it as a signed value in every
case won't break anything, even "with really big file-
systems". A signed long long will handle as much as 2^63
(minus one, to be exact) which is 8 EB (exabyte), which is
8 million TB. Yeah, sure, I know "640 KB should be enough
for everybody" and so on, but I honestly doubt that a file
system of 8 million TB will exist in the near future.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
I suggested holding a "Python Object Oriented Programming Seminar",
but the acronym was unpopular.
-- Joseph Strout
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703071538.l27FcVBG036009>