GNU bug report logs - #64123
"stat -f -c '%T' ." on alpha fails with EOVERFLOW with NFS

Previous Next

Package: coreutils;

Reported by: matoro <matoro_mailinglist_bug-coreutils <at> matoro.tk>

Date: Sat, 17 Jun 2023 08:23:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: matoro <matoro_mailinglist_bug-coreutils <at> matoro.tk>
To: bug-coreutils <at> gnu.org
Subject: "stat -f -c '%T' ." on alpha fails with EOVERFLOW with NFS
Date: Fri, 16 Jun 2023 19:55:41 -0400
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):

From: Pádraig Brady <P <at> draigBrady.com>
To: matoro <matoro_mailinglist_bug-coreutils <at> matoro.tk>, 64123 <at> debbugs.gnu.org
Subject: Re: bug#64123: "stat -f -c '%T' ." on alpha fails with EOVERFLOW with
 NFS
Date: Sat, 17 Jun 2023 18:30:40 +0100
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):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: matoro <matoro_mailinglist_bug-coreutils <at> matoro.tk>, 64123 <at> debbugs.gnu.org
Subject: Re: bug#64123: "stat -f -c '%T' ." on alpha fails with EOVERFLOW with
 NFS
Date: Sat, 17 Jun 2023 12:23:50 -0700
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):

From: Pádraig Brady <P <at> draigBrady.com>
To: matoro <matoro_mailinglist_bug-coreutils <at> matoro.tk>,
 Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 64123 <at> debbugs.gnu.org
Subject: Re: bug#64123: "stat -f -c '%T' ." on alpha fails with EOVERFLOW with
 NFS
Date: Sat, 17 Jun 2023 23:19:20 +0100
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):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 matoro <matoro_mailinglist_bug-coreutils <at> matoro.tk>
Cc: 64123 <at> debbugs.gnu.org
Subject: Re: bug#64123: "stat -f -c '%T' ." on alpha fails with EOVERFLOW with
 NFS
Date: Sat, 17 Jun 2023 18:26:43 -0700
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):

From: matoro <matoro_mailinglist_bug-coreutils <at> matoro.tk>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Pádraig Brady <P <at> draigbrady.com>, 64123 <at> debbugs.gnu.org
Subject: Re: bug#64123: "stat -f -c '%T' ." on alpha fails with EOVERFLOW with
 NFS
Date: Sat, 17 Jun 2023 15:53:53 -0400
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):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: matoro <matoro_mailinglist_bug-coreutils <at> matoro.tk>
Cc: Pádraig Brady <P <at> draigbrady.com>,
 64123-done <at> debbugs.gnu.org
Subject: Re: bug#64123: "stat -f -c '%T' ." on alpha fails with EOVERFLOW with
 NFS
Date: Mon, 19 Jun 2023 23:29:06 -0700
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.