* inode64 and 64bit kernel with 32bit userspace
@ 2013-02-18 9:43 Matthias Schniedermeyer
2013-02-18 15:12 ` Eric Sandeen
0 siblings, 1 reply; 4+ messages in thread
From: Matthias Schniedermeyer @ 2013-02-18 9:43 UTC (permalink / raw)
To: xfs
Hi
The more or less simple question is:
Is the requirement for 32bit programs to support 64bit inodes the same
as LFS(Large File Support)?
IOW if a programs was compiled with FILE_OFFSET_BITS=64 (if i remember
that name correctly) should it work?
So that all programs compiled in the last several years in a halfway
recent distribution should be able to cope with 64bit inodes?
The program i care about most is rsync and it appears to work correctly
when i tested it with 2 hard-linked files (with an inode >2^32) and the
option to preserve hard links. And "find" and "stat" also worked,
otherwise i couldn't have found the file to test it with. ;-)
--
Matthias
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: inode64 and 64bit kernel with 32bit userspace
2013-02-18 9:43 inode64 and 64bit kernel with 32bit userspace Matthias Schniedermeyer
@ 2013-02-18 15:12 ` Eric Sandeen
2013-02-18 16:20 ` Matthias Schniedermeyer
0 siblings, 1 reply; 4+ messages in thread
From: Eric Sandeen @ 2013-02-18 15:12 UTC (permalink / raw)
To: Matthias Schniedermeyer; +Cc: xfs
On 2/18/13 3:43 AM, Matthias Schniedermeyer wrote:
> Hi
>
>
> The more or less simple question is:
> Is the requirement for 32bit programs to support 64bit inodes the same
> as LFS(Large File Support)?
>
> IOW if a programs was compiled with FILE_OFFSET_BITS=64 (if i remember
> that name correctly) should it work?
I think so (I don't know where the formal documentation is,
http://users.suse.com/~aj/linux_lfs.html is an old but still good
over view I think). From open(2):
EOVERFLOW
(stat()) path refers to a file whose size cannot be represented
in the type off_t. This can occur when an application
compiled on a 32-bit platform without -D_FILE_OFFSET_BITS=64
calls stat() on a file whose size exceeds (2<<31)-1 bits.
EOVERFLOW can happen if the inode nubmer doesn't fit in a (32-bit)
stat struct as well.
> So that all programs compiled in the last several years in a halfway
> recent distribution should be able to cope with 64bit inodes?
The syscalls it makes should be able to, at least. What it does after
that is up to the program.
(i.e. you might do a nice stat64 and then try to stuff the size or the
inode number into a 32-bit variable; the -D_FILE_OFFSET_BITS won't help
in that case.)
I did a test long ago at :
http://sandeen.net/wordpress/computers/the-world-wants-32-bit-inodes/
and the results weren't too encouraging; I should try it again on a
more recent distro, and see how things look.
-Eric
> The program i care about most is rsync and it appears to work correctly
> when i tested it with 2 hard-linked files (with an inode >2^32) and the
> option to preserve hard links. And "find" and "stat" also worked,
> otherwise i couldn't have found the file to test it with. ;-)
>
>
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: inode64 and 64bit kernel with 32bit userspace
2013-02-18 15:12 ` Eric Sandeen
@ 2013-02-18 16:20 ` Matthias Schniedermeyer
2013-02-18 16:39 ` Eric Sandeen
0 siblings, 1 reply; 4+ messages in thread
From: Matthias Schniedermeyer @ 2013-02-18 16:20 UTC (permalink / raw)
To: Eric Sandeen; +Cc: xfs
On 18.02.2013 09:12, Eric Sandeen wrote:
> On 2/18/13 3:43 AM, Matthias Schniedermeyer wrote:
> > Hi
> >
> >
> > The more or less simple question is:
> > Is the requirement for 32bit programs to support 64bit inodes the same
> > as LFS(Large File Support)?
> >
> > IOW if a programs was compiled with FILE_OFFSET_BITS=64 (if i remember
> > that name correctly) should it work?
>
> I think so (I don't know where the formal documentation is,
> http://users.suse.com/~aj/linux_lfs.html is an old but still good
> over view I think). From open(2):
>
> EOVERFLOW
> (stat()) path refers to a file whose size cannot be represented
> in the type off_t. This can occur when an application
> compiled on a 32-bit platform without -D_FILE_OFFSET_BITS=64
> calls stat() on a file whose size exceeds (2<<31)-1 bits.
>
> EOVERFLOW can happen if the inode nubmer doesn't fit in a (32-bit)
> stat struct as well.
I've looked into /usr/include/sys/stat.h
And i see this:
# ifndef __ino_t_defined
# ifndef __USE_FILE_OFFSET64
typedef __ino_t ino_t;
# else
typedef __ino64_t ino_t;
# endif
# define __ino_t_defined
# endif
So ino_t really is __ino64_t when compiled with the LFS option, which
answers my original question. :-)
Besides i don't have that many programs that (should) care about inodes.
Of the top of my head i care about rsync/perl/find/ln/ls, which
apparently work correctly.
--
Matthias
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: inode64 and 64bit kernel with 32bit userspace
2013-02-18 16:20 ` Matthias Schniedermeyer
@ 2013-02-18 16:39 ` Eric Sandeen
0 siblings, 0 replies; 4+ messages in thread
From: Eric Sandeen @ 2013-02-18 16:39 UTC (permalink / raw)
To: Matthias Schniedermeyer; +Cc: xfs
On 2/18/13 10:20 AM, Matthias Schniedermeyer wrote:
> On 18.02.2013 09:12, Eric Sandeen wrote:
>> On 2/18/13 3:43 AM, Matthias Schniedermeyer wrote:
>>> Hi
>>>
>>>
>>> The more or less simple question is:
>>> Is the requirement for 32bit programs to support 64bit inodes the same
>>> as LFS(Large File Support)?
>>>
>>> IOW if a programs was compiled with FILE_OFFSET_BITS=64 (if i remember
>>> that name correctly) should it work?
>>
>> I think so (I don't know where the formal documentation is,
>> http://users.suse.com/~aj/linux_lfs.html is an old but still good
>> over view I think). From open(2):
>>
>> EOVERFLOW
>> (stat()) path refers to a file whose size cannot be represented
>> in the type off_t. This can occur when an application
>> compiled on a 32-bit platform without -D_FILE_OFFSET_BITS=64
>> calls stat() on a file whose size exceeds (2<<31)-1 bits.
>>
>> EOVERFLOW can happen if the inode nubmer doesn't fit in a (32-bit)
>> stat struct as well.
>
> I've looked into /usr/include/sys/stat.h
>
> And i see this:
> # ifndef __ino_t_defined
> # ifndef __USE_FILE_OFFSET64
> typedef __ino_t ino_t;
> # else
> typedef __ino64_t ino_t;
> # endif
> # define __ino_t_defined
> # endif
>
> So ino_t really is __ino64_t when compiled with the LFS option, which
> answers my original question. :-)
>
> Besides i don't have that many programs that (should) care about inodes.
> Of the top of my head i care about rsync/perl/find/ln/ls, which
> apparently work correctly.
find cares, ls cares . . . but I would assume that they get it right :)
I'm getting a box set up w/ 32-bit F18, I want to re-run my test over it
and see if things have improved at all in 5 years. :)
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-02-18 16:39 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-18 9:43 inode64 and 64bit kernel with 32bit userspace Matthias Schniedermeyer
2013-02-18 15:12 ` Eric Sandeen
2013-02-18 16:20 ` Matthias Schniedermeyer
2013-02-18 16:39 ` Eric Sandeen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.