All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Matthias Schniedermeyer <ms@citd.de>
Cc: xfs@oss.sgi.com
Subject: Re: inode64 and 64bit kernel with 32bit userspace
Date: Mon, 18 Feb 2013 09:12:14 -0600	[thread overview]
Message-ID: <512244CE.5030008@sandeen.net> (raw)
In-Reply-To: <20130218094320.GA24644@citd.de>

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

  reply	other threads:[~2013-02-18 15:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-18  9:43 inode64 and 64bit kernel with 32bit userspace Matthias Schniedermeyer
2013-02-18 15:12 ` Eric Sandeen [this message]
2013-02-18 16:20   ` Matthias Schniedermeyer
2013-02-18 16:39     ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=512244CE.5030008@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=ms@citd.de \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.