Bug#280213: Strange Exim Problem on Alpha

[Steve Langasek]

--8NvZYKFJsRX2Djef
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 08, 2004 at 08:34:40PM -0600, John Goerzen wrote:
> On Mon, Nov 08, 2004 at 02:37:48PM -0800, Steve Langasek wrote:
> > The other factor at work here is probably that df is using the statfs()
> > function from glibc, whereas exim4 is using statfs64() due to the CFLAGS
> > settings -D_FILE_OFFSET_BITS=3D64 -D_LARGEFILE_SOURCE.  We may be looki=
ng at a
> > broken implementation of the statfs64() libc call on alpha, or a broken
> > statfs64() syscall (either when pointing at reiserfs, or in
> > general).

> OK, I'm going to try to weed out this.

> Here is my test program:

FWIW, my reading of the exim4 sources shows that it calls statfs() on Linux,
not statvfs(), because the OS include file only defines HAVE_SYS_VFS_H and
not HAVE_SYS_STATVFS_H (in spite of this header's existence on Debian
systems).

> $ cat test.c
> #include <stdio.h>
> #include <sys/statvfs.h>

> void main(void) {
>   struct statvfs buf;

>   if (statvfs("/var/spool/exim4", &buf) =3D=3D -1) {
>     perror("statvfs");
>     exit(1);
>   }
>   printf("f_bsize =3D %lu\n", buf.f_bsize);
>   printf("f_rsize =3D %lu\n", buf.f_frsize);
>   printf("f_blocks =3D %ld\n", (long) buf.f_blocks);
>   printf("f_bfree =3D %ld\n", (long) buf.f_bfree);
>   printf("f_bavail =3D %ld\n", (long) buf.f_bavail);
>   printf("f_files =3D %lu\n", (unsigned long) buf.f_files);
>   printf("f_ffree =3D %lu\n", (unsigned long) buf.f_ffree);
>   printf("f_favail =3D %lu\n", (unsigned long) buf.f_favail);
>   printf("f_fsid =3D %lu\n", buf.f_fsid);
>   printf("f_flag =3D %lu\n", buf.f_flag);
>   printf("f_namemax =3D %lu\n", buf.f_namemax);
> }

> So it looks like the kernel and libc are OK in this instance.

> Thanks for the suggestions.  Keep them coming :-)

I'm interested to know if you get the same results with statfs() instead.
FWIW, I just built an LFS version of coreutils on my alpha, and this is what
I get from df -h:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             636P  282P   80M 100% /
/dev/hda4             1.3E  -64Z   13P 101% /usr
/dev/sda5             121P -128Z   65P 101% /var
/usr/home             1.3E  -64Z   13P 101% /home
/dev/sda4             1.2E -128Z   65P 101% /mnt
/dev/sda2             545T  -16Z  3.9M 101% /realboot
tmpfs                 751P     0  188M   0% /dev/shm

Needless to say, I do not have a 751PB tmpfs. ;)  This may point to a gener=
al
problem with coreutils itself not being 64-bit clean, however, rather than
to a glibc problem.

It might be instructive to take a look at the preprocessed source from
receive.c, as well, to confirm that the various defines floating around all
end up pointing at statfs64, instead of ending up out of order and resulting
in broken struct casts.

--=20
Steve Langasek
postmodern programmer

--8NvZYKFJsRX2Djef
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBkD0oKN6ufymYLloRApyZAJ9EJjVIm8iWMKOyxHhZNCRucd9+HgCfWy4U
vzHO3D1FUJuBiEn4U+WEFb0=
=H6jb
-----END PGP SIGNATURE-----

--8NvZYKFJsRX2Djef--