From: tri...@linuxcare.com (Andrew Tridgell) Subject: 64 bit support Date: 2000/09/26 Message-ID: <8qpocs$hn6$1@FreeBSD.csie.NCTU.edu.tw>#1/1 X-Deja-AN: 674214908 X-Trace: FreeBSD.csie.NCTU.edu.tw 969958620 18151 140.113.209.200 (26 Sep 2000 08:57:00 GMT) Organization: NCTU CSIE FreeBSD Server NNTP-Posting-Date: 26 Sep 2000 08:57:00 GMT Newsgroups: mailing.unix.samba-technical X-Complaints-To: usenet@FreeBSD.csie.NCTU.edu.tw I've been playing with 64 bit support on Linux i386. As usual the problems are primarily with locking, the glibc headers and code are really bad, making it just about impossible to make 64 bit off_t work. Anyway, I have got it to work with some gross hacks involving bypassing the C library for fcntl() and I'll be putting that in as a compile time option for those people who really need 64 bit support in Samba on Intel Linux. Meanwhile, I propose that we drop the explicit calls to open64() and friends in Samba and instead use the LFS way of doing things where compiler flags are used to select a 64 bit interface by default. This seems to be widely supported now and makes the application code much cleaner. Jeremy, you've dealt with this issue before, what do you think of removing the explicit 64 bit calls and instead use something like the AC_SYS_LARGEFILE autoconf macro (or something equivalent) to set the right compiler flags to get a 64 bit default interface. We would need some more extensive autoconf tests of the 64 bit interface (particularly with locking) but the advantage would be simpler and more maintainable code. oh btw, if you use the 64 bit off_t flags with the C library from RedHat 7.0 (glibc 2.1.95) and a 2.4.0test kernel then you get full support for 64 bit files except the locking is _completely_ broken. The effect is that the l_len parameter in struct flock gets seen by the kernel as 0 for all locks (it gets interpreted as a struct flock whereas glibc is giving it a struct flock64), which means all locks/unlocks apply from lock start to EOF. This completely breaks tdb and can easily cause data corruption with Samba. This is going to make for some interesting bug reports in some packages I expect. Cheers, Tridge
From: jer...@valinux.com (Jeremy Allison) Subject: Re: 64 bit support Date: 2000/09/26 Message-ID: <8qpjco$cnp$1@FreeBSD.csie.NCTU.edu.tw>#1/1 X-Deja-AN: 674222065 X-Trace: FreeBSD.csie.NCTU.edu.tw 969953496 13050 140.113.209.200 (26 Sep 2000 07:31:36 GMT) Organization: NCTU CSIE FreeBSD Server NNTP-Posting-Date: 26 Sep 2000 07:31:36 GMT Newsgroups: mailing.unix.samba-technical X-Complaints-To: usenet@FreeBSD.csie.NCTU.edu.tw On Tue, Sep 26, 2000 at 04:12:56PM +1000, Andrew Tridgell wrote: > I've been playing with 64 bit support on Linux i386. As usual the > problems are primarily with locking, the glibc headers and code are > really bad, making it just about impossible to make 64 bit off_t work. > > Anyway, I have got it to work with some gross hacks involving > bypassing the C library for fcntl() and I'll be putting that in as a > compile time option for those people who really need 64 bit support in > Samba on Intel Linux. > > Meanwhile, I propose that we drop the explicit calls to open64() and > friends in Samba and instead use the LFS way of doing things where > compiler flags are used to select a 64 bit interface by default. This > seems to be widely supported now and makes the application code much > cleaner. > > Jeremy, you've dealt with this issue before, what do you think of > removing the explicit 64 bit calls and instead use something like the > AC_SYS_LARGEFILE autoconf macro (or something equivalent) to set the > right compiler flags to get a 64 bit default interface. I hate doing this just for one broken platform, even if it is our most popular one. I'd rather leave the explicit largefile open64 style calls in place in the code for non-broken systems that need them and have an autoconf flag to turn them off that we can use on broken systems like RedHat 7.0. We can detect broken largefile calls and try and turn them off - this would mean less disruption in the code. We already wrap all the xxx64 calls behind sys_xxxx wrappers so it won't mean any disruption in the core code - just a set of ifdefs in the lib/system.c wrapper code. > We would need some more extensive autoconf tests of the 64 bit > interface (particularly with locking) but the advantage would be > simpler and more maintainable code. That's why I'm loath to change this code so close to a 2.2.0 release - this code was tested carefully on IRIX, HPUX and Solaris and is correct w.r.t several versions of these platforms. Making a quick hack just because RedHat 7.0 shipped as completely broken stands to break all the carefully tested code on all these other platforms - if we were to do this we'd have to get all the vendors to re-test on their platforms - this seems a little unfair for a linux bug. > RedHat 7.0 (glibc 2.1.95) and a 2.4.0test kernel then you get full > support for 64 bit files except the locking is _completely_ broken. > The effect is that the l_len parameter in struct flock gets seen by > the kernel as 0 for all locks (it gets interpreted as a struct flock > whereas glibc is giving it a struct flock64), which means all > locks/unlocks apply from lock start to EOF. This completely breaks tdb > and can easily cause data corruption with Samba. This is going to make > for some interesting bug reports in some packages I expect. Oh god - how did they ship this.......... Jeremy. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. --------------------------------------------------------