[Dovecot] fallocate and glibc 2.10
In glibc 2.10 (32 bit) fallocate() exists but fallocate64() doesn't. When _FILE_OFFSET_BITS==64, fallocate() is a redirect to fallocate64() and the program can't be linked (fails to find symbol fallocate64). See http://bugzilla.redhat.com/500487
Attached patch detects fallocate() more robustly to guard against this problem.
Cheers, Paul.
On 22.10.2010, at 19.22, Paul Howarth wrote:
In glibc 2.10 (32 bit) fallocate() exists but fallocate64() doesn't. When _FILE_OFFSET_BITS==64, fallocate() is a redirect to fallocate64() and the program can't be linked (fails to find symbol fallocate64). See http://bugzilla.redhat.com/500487
Yeah, I knew about it happening also on Ubuntu 9.10.
Attached patch detects fallocate() more robustly to guard against this problem.
A lot of code just to work around a bug that apparently only exists in Ubuntu 9.10 and Fedora 11. Is there a reason for anyone to be actually using either of them? I was thinking about just ignoring this problem.
On Sun, 24 Oct 2010 15:10:08 +0100 Timo Sirainen tss@iki.fi articulated:
On 22.10.2010, at 19.22, Paul Howarth wrote:
In glibc 2.10 (32 bit) fallocate() exists but fallocate64() doesn't. When _FILE_OFFSET_BITS==64, fallocate() is a redirect to fallocate64() and the program can't be linked (fails to find symbol fallocate64). See http://bugzilla.redhat.com/500487
Yeah, I knew about it happening also on Ubuntu 9.10.
Attached patch detects fallocate() more robustly to guard against this problem.
A lot of code just to work around a bug that apparently only exists in Ubuntu 9.10 and Fedora 11. Is there a reason for anyone to be actually using either of them? I was thinking about just ignoring this problem.
Assuming that this is truly an isolated issue; it is my belief that creating a specific patch to address this issue might lead to a regression error at some point down the line. I would suggest that you simply ignore the issue and let the end user properly update his system to eliminate the problem. Perhaps placing something in the Dovecot documentation to this effect would be advisable. If the end user wishes to patch their system to do an end run around this issue, they are free to do so. However, they should be forewarned that they are doing so at their own peril and sans any support from you if a problem(s) occur.
Just my 2¢.
-- Jerry ✌ Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
On 24/10/2010 15:10, Timo Sirainen wrote:
A lot of code just to work around a bug that apparently only exists in Ubuntu 9.10 and Fedora 11. Is there a reason for anyone to be actually using either of them? I was thinking about just ignoring this problem.
I thought you were fixing bugs coming out of running Dovecot over BSDI in order to make Dovecot *generally* more robust. (Well that was the only explanation I could think of for adding support for a dead OS...)
I would imaging Ubuntu 9.10 and Fedora 11 to be, "much less dead" than BSDI.
You may find that hosting providers only have support for certain spot versions of distros, and besides people may have reasons to stick with the distro they are on.
So it may be worth just doing it, especially if the reporter has supplied a patch!
Bill
On Sun, 24 Oct 2010 15:10:08 +0100 Timo Sirainen tss@iki.fi wrote:
On 22.10.2010, at 19.22, Paul Howarth wrote:
In glibc 2.10 (32 bit) fallocate() exists but fallocate64() doesn't. When _FILE_OFFSET_BITS==64, fallocate() is a redirect to fallocate64() and the program can't be linked (fails to find symbol fallocate64). See http://bugzilla.redhat.com/500487
Yeah, I knew about it happening also on Ubuntu 9.10.
Attached patch detects fallocate() more robustly to guard against this problem.
A lot of code just to work around a bug that apparently only exists in Ubuntu 9.10 and Fedora 11. Is there a reason for anyone to be actually using either of them? I was thinking about just ignoring this problem.
Don't know about Ubuntu but Fedora 11 is already EOL'ed so there's no need to fix it for that. Didn't realise that glibc 2.10 was that rare.
Paul.
On 24.10.2010, at 20.16, Paul Howarth wrote:
A lot of code just to work around a bug that apparently only exists in Ubuntu 9.10 and Fedora 11. Is there a reason for anyone to be actually using either of them? I was thinking about just ignoring this problem.
Don't know about Ubuntu but Fedora 11 is already EOL'ed so there's no need to fix it for that. Didn't realise that glibc 2.10 was that rare.
So how did you notice this problem then, and do you really care if I fix it? :)
On Sun, 24 Oct 2010 20:26:51 +0100 Timo Sirainen tss@iki.fi wrote:
On 24.10.2010, at 20.16, Paul Howarth wrote:
A lot of code just to work around a bug that apparently only exists in Ubuntu 9.10 and Fedora 11. Is there a reason for anyone to be actually using either of them? I was thinking about just ignoring this problem.
Don't know about Ubuntu but Fedora 11 is already EOL'ed so there's no need to fix it for that. Didn't realise that glibc 2.10 was that rare.
So how did you notice this problem then, and do you really care if I fix it? :)
I noticed it because I build dovecot packages for lots of Fedora and Red Hat releases, including some EOL ones (http://mirror.city-fan.org/ftp/contrib/mail/) and the 32-bit Fedora 11 build fell over due to this problem.
I'm not too bothered if it doesn't get fixed as clearly I'm able to work around the issue. Currently I'm using the patch I posted earlier as that was an "upstreamable" fix but I'll probably end up with a quick, simpler hack specific to Fedora 11 32-bit if you decide not to fix it.
Paul.
Paul Howarth put forth on 10/24/2010 2:16 PM:
Don't know about Ubuntu but Fedora 11 is already EOL'ed so there's no need to fix it for that. Didn't realise that glibc 2.10 was that rare.
How old is glibc 2.10?
I thought Debian Lenny (which I use) was old. It's approaching two years since release. It currently has glibc 2.7, which was apparently released in 2007, 3 years ago. This would lead me to belive that glibc 2.10 is _very_ old. I'm not very familiar with glibc. Maybe age doesn't matter?
-- Stan
On Sun, 2010-10-24 at 18:02 -0500, Stan Hoeppner wrote:
Don't know about Ubuntu but Fedora 11 is already EOL'ed so there's no need to fix it for that. Didn't realise that glibc 2.10 was that rare.
How old is glibc 2.10?
I thought Debian Lenny (which I use) was old. It's approaching two years since release. It currently has glibc 2.7, which was apparently released in 2007, 3 years ago. This would lead me to belive that glibc 2.10 is _very_ old. I'm not very familiar with glibc. Maybe age doesn't matter?
It's a version number, generally major.minor.micro. It's not a floating point number.
7 < 10, and thus 2.7 is older than 2.10.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i
Karsten Bräckelmann put forth on 10/24/2010 6:34 PM:
On Sun, 2010-10-24 at 18:02 -0500, Stan Hoeppner wrote:
Don't know about Ubuntu but Fedora 11 is already EOL'ed so there's no need to fix it for that. Didn't realise that glibc 2.10 was that rare.
How old is glibc 2.10?
I thought Debian Lenny (which I use) was old. It's approaching two years since release. It currently has glibc 2.7, which was apparently released in 2007, 3 years ago. This would lead me to belive that glibc 2.10 is _very_ old. I'm not very familiar with glibc. Maybe age doesn't matter?
It's a version number, generally major.minor.micro. It's not a floating point number.
7 < 10, and thus 2.7 is older than 2.10.
Ahh, thanks for pointing out my error. I was thinking "2.1" not "2.10". So I'm on a much older version of glibc. I guess since I stick with distro packages I'm safe from this particular problem, since such packages are compiled against the glibc 2.7 of the distro.
-- Stan
participants (6)
-
Jerry
-
Karsten Bräckelmann
-
Paul Howarth
-
Stan Hoeppner
-
Timo Sirainen
-
William Blunn