GNU bug report logs -
#64123
"stat -f -c '%T' ." on alpha fails with EOVERFLOW with NFS
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64123 in the body.
You can then email your comments to 64123 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#64123
; Package
coreutils
.
(Sat, 17 Jun 2023 08:23:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
matoro <matoro_mailinglist_bug-coreutils <at> matoro.tk>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Sat, 17 Jun 2023 08:23:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi, when running the command "stat -f -c '%T' ." on an alpha while being
on an NFS filesystem, the command fails with EOVERFLOW.
$ stat -f -c "%T" .
stat: cannot read file system information for '.': Value too large for
defined data type
The command does NOT fail when targeting any other filesystem type.
$ stat -f -c "%T" /
ext2/ext3
I am aware that EOVERFLOW is typically associated with 32-bit systems
failing to hold 64-bit inodes and such. However, alpha is a pure 64-bit
system; there does not even exist a 32-bit version.
This is the only platform on which I have observed this behavior. I
also checked on all other platforms, including x86, arm, ppc, riscv,
mips, sparc, hppa, and ia64. No other platform exhibited this error.
I am using kernel 6.3, glibc 2.37, and coreutils 9.3. If anybody would
mind taking a look at this bug, I can provide direct shell access to the
machine in question, with strace etc installed. Thank you!
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#64123
; Package
coreutils
.
(Sat, 17 Jun 2023 17:31:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 64123 <at> debbugs.gnu.org (full text, mbox):
On 17/06/2023 00:55, matoro via GNU coreutils Bug Reports wrote:
> Hi, when running the command "stat -f -c '%T' ." on an alpha while being
> on an NFS filesystem, the command fails with EOVERFLOW.
>
> $ stat -f -c "%T" .
> stat: cannot read file system information for '.': Value too large for
> defined data type
>
> The command does NOT fail when targeting any other filesystem type.
>
> $ stat -f -c "%T" /
> ext2/ext3
>
> I am aware that EOVERFLOW is typically associated with 32-bit systems
> failing to hold 64-bit inodes and such. However, alpha is a pure 64-bit
> system; there does not even exist a 32-bit version.
>
> This is the only platform on which I have observed this behavior. I
> also checked on all other platforms, including x86, arm, ppc, riscv,
> mips, sparc, hppa, and ia64. No other platform exhibited this error.
>
> I am using kernel 6.3, glibc 2.37, and coreutils 9.3. If anybody would
> mind taking a look at this bug, I can provide direct shell access to the
> machine in question, with strace etc installed. Thank you!
Output from strace would be helpful,
though I suspect the issue is in glibc or the kernel.
I see that s390 and alpha are the only 64 bit architectures
that have a 32-bit ino_t for example, which may cause issues within glibc?
If you're compiling coreutils yourself, a copy of lib/config.h
would also be helpful.
cheers,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#64123
; Package
coreutils
.
(Sat, 17 Jun 2023 19:25:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 64123 <at> debbugs.gnu.org (full text, mbox):
On 2023-06-17 10:30, Pádraig Brady wrote:
> I see that s390 and alpha are the only 64 bit architectures
> that have a 32-bit ino_t for example, which may cause issues within glibc?
Weird.
What happens if you compile with -D_FILE_OFFSET_BITS=64? Does this cause
alpha to have a 64-bit ino_t? (How does that work, exactly?) If so, then
AC_SYS_LARGEFILE should check for this and should arrange for "#define
_FILE_OFFSET_BITS 64".
Matoro, what happens if you compile the following C program?
#include <sys/stat.h>
#include <stdio.h>
int
main (void)
{
int n = sizeof (ino_t);
printf ("%d\n", n);
}
Compile and run it like this:
gcc ino.c
./a.out
gcc -D_FILE_OFFSET_BITS=64 ino.c
./a.out
If the former prints "4" and the latter "8" then we can fix Autoconf and
Gnulib AC_SYS_LARGEFILE to do the right thing.
Also, as Pádraig suggests, the output of the following shell command
would be useful:
strace stat -f -c '%T' .
Also please see
<https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1899582>. Although
it's about s390x I expect there are similar issues on alpha, which may
not be fixed and if so it's not a coreutils issue per se.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#64123
; Package
coreutils
.
(Sat, 17 Jun 2023 22:20:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 64123 <at> debbugs.gnu.org (full text, mbox):
On 17/06/2023 20:53, matoro wrote:
> On 2023-06-17 15:23, Paul Eggert wrote:
>> On 2023-06-17 10:30, Pádraig Brady wrote:
>>> I see that s390 and alpha are the only 64 bit architectures
>>> that have a 32-bit ino_t for example, which may cause issues within
>>> glibc?
>>
>> Weird.
>>
>> What happens if you compile with -D_FILE_OFFSET_BITS=64? Does this
>> cause alpha to have a 64-bit ino_t? (How does that work, exactly?) If
>> so, then AC_SYS_LARGEFILE should check for this and should arrange for
>> "#define _FILE_OFFSET_BITS 64".
>>
>> Matoro, what happens if you compile the following C program?
>>
>>
>> #include <sys/stat.h>
>> #include <stdio.h>
>>
>> int
>> main (void)
>> {
>> int n = sizeof (ino_t);
>> printf ("%d\n", n);
>> }
>>
>>
>> Compile and run it like this:
>>
>> gcc ino.c
>> ./a.out
>> gcc -D_FILE_OFFSET_BITS=64 ino.c
>> ./a.out
>>
>> If the former prints "4" and the latter "8" then we can fix Autoconf
>> and Gnulib AC_SYS_LARGEFILE to do the right thing.
>>
>> Also, as Pádraig suggests, the output of the following shell command
>> would be useful:
>>
>> strace stat -f -c '%T' .
>>
>> Also please see
>> <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1899582>.
>> Although it's about s390x I expect there are similar issues on alpha,
>> which may not be fixed and if so it's not a coreutils issue per se.
>
> This indeed seems to be the issue, thank you. Compiling with
> -D_FILE_OFFSET_BITS=64 fixes the problem.
>
> For reference, here is the additional requested information.
>
> strace: https://paste.matoro.tk/o1te2ek
> config.h: https://paste.matoro.tk/93xerfg
>
> Thank you for your help!
In case it's useful, I noticed this thread from 2014 about ino_t
and consequences of using -D_FILE_OFFSET_BITS=64
https://sourceware.org/pipermail/libc-alpha/2014-March/thread.html#49675
cheers,
Pádraig
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#64123
; Package
coreutils
.
(Sun, 18 Jun 2023 01:27:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 64123 <at> debbugs.gnu.org (full text, mbox):
On 2023-06-17 15:19, Pádraig Brady wrote:
> In case it's useful, I noticed this thread from 2014 about ino_t
> and consequences of using -D_FILE_OFFSET_BITS=64
> https://sourceware.org/pipermail/libc-alpha/2014-March/thread.html#49675
Yes, that was about glibc. For Autoconf and Gnulib it's long been
decided that _FILE_OFFSET_BITS=64 was the way to go, if it made any
difference for off_t. Since ino_t is used much less often than off_t,
the argument is even stronger that _FILE_OFFSET_BITS=64 is the way to go
for alpha and s390x on glibc - changing the width of ino_t is a much
smaller deal than changing the width of off_t.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#64123
; Package
coreutils
.
(Sun, 18 Jun 2023 07:05:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 64123 <at> debbugs.gnu.org (full text, mbox):
On 2023-06-17 15:23, Paul Eggert wrote:
> On 2023-06-17 10:30, Pádraig Brady wrote:
>> I see that s390 and alpha are the only 64 bit architectures
>> that have a 32-bit ino_t for example, which may cause issues within
>> glibc?
>
> Weird.
>
> What happens if you compile with -D_FILE_OFFSET_BITS=64? Does this
> cause alpha to have a 64-bit ino_t? (How does that work, exactly?) If
> so, then AC_SYS_LARGEFILE should check for this and should arrange for
> "#define _FILE_OFFSET_BITS 64".
>
> Matoro, what happens if you compile the following C program?
>
>
> #include <sys/stat.h>
> #include <stdio.h>
>
> int
> main (void)
> {
> int n = sizeof (ino_t);
> printf ("%d\n", n);
> }
>
>
> Compile and run it like this:
>
> gcc ino.c
> ./a.out
> gcc -D_FILE_OFFSET_BITS=64 ino.c
> ./a.out
>
> If the former prints "4" and the latter "8" then we can fix Autoconf
> and Gnulib AC_SYS_LARGEFILE to do the right thing.
>
> Also, as Pádraig suggests, the output of the following shell command
> would be useful:
>
> strace stat -f -c '%T' .
>
> Also please see
> <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1899582>.
> Although it's about s390x I expect there are similar issues on alpha,
> which may not be fixed and if so it's not a coreutils issue per se.
This indeed seems to be the issue, thank you. Compiling with
-D_FILE_OFFSET_BITS=64 fixes the problem.
For reference, here is the additional requested information.
strace: https://paste.matoro.tk/o1te2ek
config.h: https://paste.matoro.tk/93xerfg
Thank you for your help!
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
You have taken responsibility.
(Tue, 20 Jun 2023 06:30:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
matoro <matoro_mailinglist_bug-coreutils <at> matoro.tk>
:
bug acknowledged by developer.
(Tue, 20 Jun 2023 06:30:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 64123-done <at> debbugs.gnu.org (full text, mbox):
On 2023-06-17 12:53, matoro via GNU coreutils Bug Reports wrote:
> Compiling with -D_FILE_OFFSET_BITS=64 fixes the problem.
Thanks for checking. I installed the following fix to coreutils:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=5ac7f2d281ef70500fc70211dc1f146c8666e8c1
This incorporates the following Gnulib fix:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f4919b224dd1545190f35eb481f78694f2337cb1
which is derived from the following Autoconf fix:
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=103514e40da5f20aebf83a3446452ccebe5172bb
which should cause 'configure' to #define _FILE_OFFSET_BITS to 64 on
GNU/Linux s390x and alpha.
Closing the coreutils bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 18 Jul 2023 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 130 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.