All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andi Kleen <andi@firstfloor.org>,
	David Miller <davem@davemloft.net>,
	byron.bbradley@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: XFS Fails Quality Assurance Tests on ARM
Date: Tue, 2 Oct 2007 17:38:09 +1000	[thread overview]
Message-ID: <20071002073809.GA995458@sgi.com> (raw)
In-Reply-To: <200709280740.48723.nickpiggin@yahoo.com.au>

On Fri, Sep 28, 2007 at 07:40:48AM +1000, Nick Piggin wrote:
> On Sunday 02 September 2007 08:14, Andi Kleen wrote:
> > David Miller <davem@davemloft.net> writes:
> > > From: Byron Bradley <byron.bbradley@gmail.com>
> > > Date: Fri, 31 Aug 2007 03:12:46 +0000 (UTC)
> > > > Anybody got any ideas of how we fix this?
> > >
> > > I don't know how much testing XFS gets on ARM, but one thing that some
> > > ARM chips have is D-cache aliasing problems and one thing XFS uses a
> > > lot is virtual remapping of various data structures via vmap().
> > >
> > > This might be what is causing the problems.
> >
> > AFAIK XFS uses vmap() mainly during log replay. If David's theory
> > was true then the failures must be seen during tests that do
> > this.
> 
> I think it can also do vmap for directory lookups, and it crashed
> in some directory lookup AFAIKS.
> 
> One way to verify would be to create the XFS filesystem with PAGE_SIZE
> directory blocks (mkfs.xfs -nsize=PAGE_SIZE) I believe. Dave will correct
> me if I'm wrong.

By default the directory block size is the same as the filesystem
block size which means it will be <= PAGE_SIZE unless some
special mkfs.xfs goo was used. What is the output of 'xfs_info <mntpt>'
on the machine in question?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

  reply	other threads:[~2007-10-02  7:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-31  3:12 XFS Fails Quality Assurance Tests on ARM Byron Bradley
2007-08-31  4:39 ` David Miller
2007-09-01 22:14   ` Andi Kleen
2007-09-27 21:40     ` Nick Piggin
2007-10-02  7:38       ` David Chinner [this message]
2007-10-30  5:47     ` Eric Sandeen
2007-10-30 17:54       ` Christoph Hellwig
2007-10-30 18:14         ` Eric Sandeen
2007-10-30 21:38         ` David Miller
2008-03-18  3:41           ` Eric Sandeen
  -- strict thread matches above, loose matches on Subject: below --
2007-08-31 10:58 Byron Bradley
2007-08-31 14:36 ` 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=20071002073809.GA995458@sgi.com \
    --to=dgc@sgi.com \
    --cc=andi@firstfloor.org \
    --cc=byron.bbradley@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /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.