[Dovecot] AIX and posix_fallocate
Hi, AIX's implementation of posix_fallocate is a little bit, let me say, peculiar. Attached is a patch to "fix" (=work around) this. Without you'll see this in the logs: Jul 28 01:17:41 trevi mail:err|error dovecot: IMAP(beckerr): posix_fallocate() failed: File exists Jul 28 01:17:41 trevi mail:err|error dovecot: IMAP(beckerr): file_set_size() failed with mbox file /u/f0/rzuser/beckerr/Mail/Ham: File exists Funny, isn't it? This is what it should be: Jul 28 01:17:41 trevi mail:err|error dovecot: IMAP(beckerr): posix_fallocate() failed: Operation not supported on socket Jul 28 01:17:41 trevi mail:err|error dovecot: IMAP(beckerr): file_set_size() failed with mbox file /u/f0/rzuser/beckerr/Mail/Ham: Operation not supported on socket The problem is, that errno is not correcly set, when posix_fallocate returns EOPNOTSUPP (="Operation not supported on socket"). In this case the return code has to be checked rather than errno. When patched dovecot handles err==EOPNOTSUPP the same way like errno==EINVAL on Solaris. A note for all AIX Admins: Without APAR IZ48778: POSIX_FALLOCATE() FAILS WITH ERROR-25(ENOTTY) resp. IZ46961: POSIX_FALLOCATE() FAILS WITH ERROR-25(ENOTTY) APPLIES TO AIX 5300-06 you don't even get EOPNOTSUPP: posix_fallocate fails with NOTTY. So you have to install one of this fixes to make the patch work. Ralf -- ______________________________________________________________________ Dipl.-Inform. (FH) Ralf Becker Rechenzentrum (r/ft) der FH Trier (Network|Mail|Web|Firewall) University of applied sciences Administrator Schneidershof, D-54293 Trier Mail: beckerr@fh-trier.de Fon: +49 651 8103 499 Web: http://www.fh-trier.de/~beckerr Fax: +49 651 8103 214 PubKey: http://www.fh-trier.de/~beckerr Crypto: GnuPG, S/MIME ______________________________________________________________________ Wenn Gott gewollt haette, dass E-Mail in HTML geschrieben wuerden, endeten Gebete traditionell mit </amen>. (Tom Listen) --- ./lib/file-set-size.c.org 2009-07-06 12:56:17.000000000 +0200 +++ ./lib/file-set-size.c 2009-07-06 12:54:40.000000000 +0200 @@ -43,9 +43,15 @@ #ifdef HAVE_POSIX_FALLOCATE if (posix_fallocate_supported) { - if (posix_fallocate(fd, st.st_size, size - st.st_size) == 0) + int err; + if ((err = posix_fallocate(fd, st.st_size, size - st.st_size)) == 0) return 0; + if (err == EOPNOTSUPP /* AIX */ ) { + /* Ignore this error silently. + You have to test err, because errno is not + correcly set on some versions of AIX */ + } else if (errno != EINVAL /* Solaris */) { if (!ENOSPACE(errno)) i_error("posix_fallocate() failed: %m");
I bumped into this a while back, and having IBM support for both AIX and the C for AIX V9 compiler, went to the mat on it. What a pointless waste of time; the new IBM increasingly doesn't care about making things right. While IBM has been proclaiming its POSIX compliance, it turned out that AIX and the compiler development have been tasked with its implementation, such as it maybe, only on the JFS2 filesystem. Now they haven't discontinued JFS FS support, but it's a disinterested, neglectful support. Now in the old IBM, everything, but everything, would be tested in n! ways, and everything would work. In the posix_fallocate development, for both AIX and the IBM compiler, apparently nobody did nuffin' with it for the old JFS FS...so until I raised Hell, the call returned a random value error code. Which means that the design team didn't consider JFS at all; not even to the point of documenting non-suppport in JFS. Their charge was JFS2. So they figured out a fix: a patch to return a generic something-wrong errcode. I screamed some more. Their final fix was to return a function not supported errcode. There. Done. It only took 3-4 months.
FWIW, the patch will be in the mainline Technical level as follows: "This APAR will be available 53V (AIX 53 TL11 ) and 61H (AIX 61 TL4 )."
Their POSIX compliance position:
we would like to clarify you on below points on posix compliant details in AIX.
Your comment:
Obviously, if you don't support both of AIX's file systems, you are not totally compliant.
Response: Unix standards for posix_fallocate( ) function does not state what all filesystems the implementation need to support. Having said that AIX implementation of posix_fallocate() only supports JFS2. Hence not supporting JFS does not mean that AIX implementation of posix_fallocate() is not posix compliant. However as stated earlier you can open a Design change request for AIX to implement the support of JFS.
Regarding the list of non-posix compliant APIs we do not maintain any separate list nor we have any known issues. Developers can get information about APIs from IBM documentation http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp and also looking through Open Group standards specification http://www.opengroup.org/onlinepubs/009695399/toc.htm
Working with the Indian IBM support was intriguing: they were always courteous, but they were only interested in fulfilling checklists, not in making the product right or necessarily making it work. They didn't, as I have seen elsewhere, declare victory by closing out the trouble ticket (PMR in IBMese) without informing you or getting your consent....but they would continue talking and doing not much of anything until you gave up.
What I now do is to:
- run configure
- edit config.h and put // in front of the HAVE_POSIX_FALLOCATE define, like this:
//#define HAVE_POSIX_FALLOCATE
- then run make as usual
I'm sorry; I should have posted this before, but the whole thing left such a bad taste in my mouth all I wanted to do was move on.
S.
Ralf Becker wrote:
Hi,
AIX's implementation of posix_fallocate is a little bit, let me say, peculiar. Attached is a patch to "fix" (=work around) this.
Without you'll see this in the logs:
Jul 28 01:17:41 trevi mail:err|error dovecot: IMAP(beckerr): posix_fallocate() failed: File exists Jul 28 01:17:41 trevi mail:err|error dovecot: IMAP(beckerr): file_set_size() failed with mbox file /u/f0/rzuser/beckerr/Mail/Ham: File exists
Funny, isn't it?
This is what it should be:
Jul 28 01:17:41 trevi mail:err|error dovecot: IMAP(beckerr): posix_fallocate() failed: Operation not supported on socket Jul 28 01:17:41 trevi mail:err|error dovecot: IMAP(beckerr): file_set_size() failed with mbox file /u/f0/rzuser/beckerr/Mail/Ham: Operation not supported on socket
The problem is, that errno is not correcly set, when posix_fallocate returns EOPNOTSUPP (="Operation not supported on socket"). In this case the return code has to be checked rather than errno.
When patched dovecot handles err==EOPNOTSUPP the same way like errno==EINVAL on Solaris.
A note for all AIX Admins: Without APAR IZ48778: POSIX_FALLOCATE() FAILS WITH ERROR-25(ENOTTY) resp. IZ46961: POSIX_FALLOCATE() FAILS WITH ERROR-25(ENOTTY) APPLIES TO AIX 5300-06 you don't even get EOPNOTSUPP: posix_fallocate fails with NOTTY. So you have to install one of this fixes to make the patch work.
Ralf
-- ==== Once upon a time, the Internet was a friendly, neighbors-helping-neighbors small town, and no one locked their doors. Now it's like an apartment in Bed-Stuy: you need three heavy duty pick-proof locks, one of those braces that goes from the lock to the floor, and bars on the windows.... ==== Stewart Dean, Unix System Admin, Bard College, New York 12504 sdean@bard.edu voice: 845-758-7475, fax: 845-758-7035
On Thu, 2009-07-30 at 11:24 +0200, Ralf Becker wrote:
if ((err = posix_fallocate(fd, st.st_size, size - st.st_size)) == 0) return 0;if (err == EOPNOTSUPP /* AIX */ ) {} else
First I thought: Why didn't IBM even fix this properly by setting errno? Then I read posix_fallocate man page:
RETURN VALUE posix_fallocate() returns zero on success, or an error number on fail‐ ure. Note that errno is not set.
What the hell were POSIX people thinking?? This is the first syscall I've seen that behaves like this, and apparently without any good reason! Wonder how many other new system calls there are like this, that I haven't noticed yet..
On Thu, 2009-07-30 at 13:44 -0400, Timo Sirainen wrote:
RETURN VALUE posix_fallocate() returns zero on success, or an error number on fail‐ ure. Note that errno is not set.
What the hell were POSIX people thinking?? This is the first syscall I've seen that behaves like this, and apparently without any good reason! Wonder how many other new system calls there are like this, that I haven't noticed yet..
Looks like all posix_*() syscalls do that. Wonder if there are more.
Le jeudi 30 juillet 2009, Timo Sirainen a écrit :
What the hell were POSIX people thinking?? This is the first syscall I've seen that behaves like this, and apparently without any good reason! Wonder how many other new system calls there are like this, that I haven't noticed yet..
Looks like all posix_*() syscalls do that. Wonder if there are more.
Looks like too many people were incorrectly using errno, especially in multi- threaded context.
From http://www.unix.org/whitepapers/reentrant.html :
"In addition, all POSIX.1c functions avoid using errno and, instead, return the error number directly as the function return value, with a return value of zero indicating that no error was detected. This strategy is, in fact, being followed on a POSIX-wide basis for all new functions. "
participants (4)
-
Ralf Becker
-
Remi Gacogne
-
Stewart Dean
-
Timo Sirainen