All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Peter Kimball <peterakimball@yahoo.com>
Cc: xfs@oss.sgi.com
Subject: Re: inode64 readiness testing
Date: Mon, 21 Nov 2011 22:38:13 -0600	[thread overview]
Message-ID: <4ECB2735.3040500@sandeen.net> (raw)
In-Reply-To: <501A7AEB-6708-4181-AAE2-D145DC23B938@yahoo.com>

On 11/18/11 11:33 AM, Peter Kimball wrote:
> Hi folks,
> 
> We've got some large XFS volumes that should probably be using the
> inode64 mount option, but aren't yet.  Before I go making irrevocable
> changes, I wanted to run my testing procedure by you to make sure
> I've actually tested what I think I tested.  These volumes will be
> shared via NFS, which is not your problem but seems to be a
> troublemaker.
> 
> 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.
> 
> I then unmounted the filesystem and re-mounted it using the inode64
> flag, just like it would be mounted in production.
> 
> I then verified that the programs I cared about (mostly NFS clients)
> could read all of the data I had written.  I also made sure they
> could write to the filesystem.
> 
> Since I haven't seen any read/write failures at this point, I feel
> I'm ready to sign off that we're ready to start using the inode64
> flag.  Did I properly create files using 64-bit inodes?  Did I read
> from the filesystem in such a way that I would know if my readers
> were unable to handle 64-bit inodes?  Is there anything I should test
> that I haven't?

You might also take a look at the script at http://sandeen.net/wordpress/?p=9,
which can look at binaries and check them for 32-bit stat() syscalls.

-Eric

> Thanks for all your hard work on this most useful project! Peter
> 
> 
> 
> ps: not sure it makes a difference, this is on Centos 5.3
> (2.6.18-128.el5), so I'm not entirely certain which XFS bugs/features
> have been folded in by the maintainers...
> 
> _______________________________________________ xfs mailing list 
> xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
> 

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

      parent reply	other threads:[~2011-11-22  4:38 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
2011-11-22  4:38 ` Eric Sandeen [this message]

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=4ECB2735.3040500@sandeen.net \
    --to=sandeen@sandeen.net \
    --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 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.