From: | Christoph Moench-Tegeder <cmt(at)burggraben(dot)net> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Monitoring disk space from within the server |
Date: | 2019-11-09 13:33:49 |
Message-ID: | 20191109133349.GA2545@elch.exwg.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
## Michael Paquier (michael(at)paquier(dot)xyz):
> Total bytes and free bytes looks like a good first cut. Have you
> looked at the portability of statfs() on other BSD flavors and
> Solaris?
"The statfs() system call first appeared in 4.4BSD." (from the statfs(2)
manpage on FreeBSD). struct statfs differs between Linux and BSD, but
is "close enough" for this, the fields from the original patch are
present in both implementations.
Solaris does not have statfs() anymore. Instead, it has a statvfs()
which is "more or less equivalent" to the Linux statvfs(). On FreeBSD,
using statvfs() (it's available) is rather not recommended, from the
man page:
The statvfs() and fstatvfs() functions fill the structure pointed
to by buf with garbage. This garbage will occasionally bear resemblance
to file system statistics, but portable applications must not depend on
this.
That's funny, as statvfs() is in our beloved POSIX.1 since at least
2001 - current specs:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fstatvfs.html
Regards,
Christoph
--
Spare Space
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2019-11-09 13:36:20 | Re: Planning counters in pg_stat_statements (using pgss_store) |
Previous Message | Andrew Dunstan | 2019-11-09 13:25:10 | Re: TestLib::command_fails_like enhancement |