Portage 2.1-r2 (default-linux/alpha/2006.1, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16.19 alpha) ================================================================= System uname: 2.6.16.19 alpha EV6 Gentoo Base System version 1.12.1 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r4 ACCEPT_KEYWORDS="alpha" AUTOCLEAN="yes" CBUILD="alpha-unknown-linux-gnu" CFLAGS="-mieee -pipe -O3 -mcpu=ev6" CHOST="alpha-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo" CXXFLAGS="-mieee -pipe -O3 -mcpu=ev6" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/sci" SYNC="rsync://fileserver/gentoo-portage" USE="alpha berkdb bitmap-fonts bzip2 cli crypt cups dlloader doc dri examples fortran gdbm hdf hdf5 ipv6 isdnlog kerberos ldap libg++ ncurses nls nptl nptlonly pam pcre perl ppds pppd python qt readline reflection session spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode xml xorg zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux userland_GNU video_cards_cirrus video_cards_ati video_cards_dummy video_cards_fbdev video_cards_glint video_cards_mga video_cards_nv video_cards_rendition video_cards_s3 video_cards_s3virge video_cards_savage video_cards_siliconmotion video_cards_sisusb video_cards_tdfx video_cards_tga video_cards_v4l video_cards_vga video_cards_voodoo" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS There seems to be some limitation on the maximum size of a filesystem info, this case a NFS, although I can use it without a problem: alpha-10 ~ # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 8650036 1518376 7131660 18% / udev 1034136 96 1034040 1% /dev shm 1034136 0 1034136 0% /dev/shm df: `/fileserver': Value too large for defined data type fileserver:/remote 54465880 14921368 39544512 28% /remote ---- quota -s user quota: Can't statfs() /fileserver: Value too large for defined data type ---- it should give something like (df -h): fileserver:/fileserver 4.1T 195G 4.0T 5% /fileserver and quota -s USER Disk quotas for user USER (uid XXXX): Filesystem blocks quota limit grace files quota limit grace fileserver:/fileserver 21903M 400G 500G 5873 0 0 where fileserver is a gentoo opteron system, and the fs has mount options: fileserver:/fileserver on /fileserver type nfs (rw,rsize=8192,wsize=8192,tcp,bg,addr=10.10.1.3) The fileserver:/remote is on another disk (60GB) of the same fileserver. the previous working output is from athlon and opteron client machines mounting the same NFS.
I'm pretty sure this is related to the old bug: http://sourceware.org/bugzilla/show_bug.cgi?id=1864 which was never fixed. Try to apply the following patch (/usr/include/bits/) and rebuild quota. --- typesizes.h.orig 2007-07-03 09:36:58.000000000 +0000 +++ typesizes.h 2007-07-03 09:37:34.000000000 +0000 @@ -42,9 +42,9 @@ #define __BLKCNT_T_TYPE __U32_TYPE #define __BLKCNT64_T_TYPE __U64_TYPE #define __FSBLKCNT_T_TYPE __S32_TYPE -#define __FSBLKCNT64_T_TYPE __S64_TYPE +#define __FSBLKCNT64_T_TYPE __S32_TYPE #define __FSFILCNT_T_TYPE __U32_TYPE -#define __FSFILCNT64_T_TYPE __U64_TYPE +#define __FSFILCNT64_T_TYPE __U32_TYPE #define __ID_T_TYPE __U32_TYPE #define __CLOCK_T_TYPE __SLONGWORD_TYPE #define __TIME_T_TYPE __SLONGWORD_TYPE I will attach a testcase which shows the problem.
Created attachment 123761 [details] statfs testcase Testcase Compile with gcc -D_FILE_OFFSET_BITS=64 statfs.c -o statfs give you a very high wrong number while if you use the generic: gcc statfs.c -o statfs all is correct.
trivial for me to include -- up to the alpha team though
Is this still a problem?
I too just ran into this bug using /bin/cat. Large file support is compiled into my kernel and have never really had this problem until just a few days ago! /stored/tv/ch9.1-60min-20111130-1700.mpg cat: /dev/dvb/adapter0/dvr0: Value too large for defined data type =sys-apps/coreutils-8.7 (nls unicode -acl -caps -gmp -selinux -static -vanilla -xattr) (attaching config.log)
Created attachment 294411 [details] coreutils config.log -- grep -i large The coreutils config.log was (only) 2.5M, so I grepped the relevant part: $ cat config.log |grep -i large
FYI: For those happening on this issue with '/bin/cat', it's been suggest to use ' '/bin/dd' instead. ie: $ dd if=/dev/dvb/adapter${DVB_DEVICE_NUM}/dvr${DVB_DEVICE_NUM} of=${FILE_NAME} conv=noerror ('conv=noerror' option prevents stopping on errors)
looks like the upstream bug report has included a better patch for things. changing the fundamental types like this scares me due to the implied ABI changes (which are a no no).
From upstream bug report: ------ Richard Henderson 2012-02-15 18:16:37 UTC This has been fixed since commit 7ffd2bd725c3e4d77e6bfe36b76500d20427929d Author: Richard Henderson <rth@twiddle.net> Date: Wed May 5 08:12:11 2010 -0700 alpha: Do the 32/64-bit split on statfs routines. ------
