public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Peter Kimball <peterakimball@yahoo.com>
Cc: xfs@oss.sgi.com
Subject: Re: inode64 readiness testing
Date: Tue, 22 Nov 2011 11:19:40 +1100	[thread overview]
Message-ID: <20111122001940.GH2386@dastard> (raw)
In-Reply-To: <C5842F44-178B-403C-9C07-BA475B16DE75@yahoo.com>

On Mon, Nov 21, 2011 at 03:46:04PM -0500, Peter Kimball wrote:
> 
> On Nov 20, 2011, at 2:10 PM, Christoph Hellwig wrote:
> 
> > On Fri, Nov 18, 2011 at 12:33:16PM -0500, Peter Kimball wrote:
> >> I created a blank 1GB disk image, created an XFS filesystem on
> >> that image, and mounted it on a loopback device using the ino64
> >> flag.  
> >> 
> >> I wrote a bunch of data to the filesystem (lots of small
> >> files), approximately 600MB.
> >> 
> >> At this point, I think I have a filesystem in which inodes use
> >> 64-bit addresses, even if the actual address value would fit in
> >> 32 bits.  I would expect any program that can't handle 64-bit
> >> addresses to barf when trying to access any data on the
> >> filesystem.
> > 
> > You will never not see 64-bit inodes on a filesystem that small
> > ever.  Try to create a (sparse) 10TB loop image, and create some
> > deep directories in it.  This should create some larger inodes
> > number for you if you had it mounted with the inode64 flag.  You
> > can verify that by checking that the inode number returned from
> > the stat systsem call or from ls -i is larger than 32 bits.
> > 
> 
> Thank you for that guide, Christoph.  I followed your directions
> and the directory tree I created included some >32-bit inode
> numbers so I was able to successfully test all of our NFS clients.
> 
> From what I'd read, I thought that the ino64 mount option would do
> the work for me (bring 32-bit inode numbers into 64-bit range),
> apparently that is not the case.  This method worked great,
> hopefully the next person to search can find this happy thread.

The ino64 mount option does not exist any more - it got removed
quite some time ago as it was debug-only code that nobody ever
tested or verified did the right thing...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-11-22  0:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-18 17:33 inode64 readiness testing Peter Kimball
2011-11-20 19:10 ` Christoph Hellwig
2011-11-21 20:46   ` Peter Kimball
2011-11-22  0:19     ` Dave Chinner [this message]
2011-11-22  4:38 ` 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=20111122001940.GH2386@dastard \
    --to=david@fromorbit.com \
    --cc=peterakimball@yahoo.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox