From: Eric Sandeen <sandeen@sandeen.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: Andy Poling <andy@realbig.com>, Ofer Heifetz <oferh@marvell.com>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: XFS support for ARMv5
Date: Wed, 25 Nov 2009 16:10:36 -0600 [thread overview]
Message-ID: <4B0DAB5C.2080607@sandeen.net> (raw)
In-Reply-To: <20091125210611.GA12150@infradead.org>
Christoph Hellwig wrote:
> On Wed, Nov 25, 2009 at 10:30:09AM -0600, Andy Poling wrote:
>> On Mon, 23 Nov 2009, Ofer Heifetz wrote:
>>> Here is the dmesg I got for mount /dev/sda3 /mnt/usb:
>>> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
>>> XFS mounting filesystem sda3
>>> Starting XFS recovery on filesystem: sda3 (logdev: internal)
>>> XFS: xlog_recover_process_data: bad clientid
>>> XFS: log mount/recovery failed: error 5
>>> XFS: log mount failed
>> See this thread in the archives for a patch that may fix this:
>>
>> http://oss.sgi.com/pipermail/xfs/2009-October/042805.html
>
> I don't think it's the case you found, although the symptoms are the
> same. I'd rather guess this is a case of an architecture with virtually
> indexed caches (can anyone confirm the cache architecture?) which
> doesn't cope too well with the way we use vmap to write into a buffer
> through virtually mapped linear addresses, but then do block I/O using
> the physical addresses of the individual pages. James Bottomley has a
> patchset to fix this issue by introducing APIs that allow the
> architecture specific memory management to cope with it. He're a
> version I could quickly find, although newer ones have been posted
> since:
>
> http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364
>
> The patchset is planned to get merged into Linux 2.6.33.
I'll do some ARM testing w/ that stuff next week.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-11-25 22:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-18 12:21 XFS support for ARMv5 oferh
2009-11-18 16:03 ` Eric Sandeen
2009-11-22 16:20 ` Ofer Heifetz
2009-11-22 16:45 ` Richard Sharpe
2009-11-22 20:07 ` Ofer Heifetz
2009-11-22 20:16 ` Richard Sharpe
2009-11-23 15:56 ` Ofer Heifetz
2009-11-22 16:53 ` Eric Sandeen
2009-11-23 14:46 ` Ofer Heifetz
2009-11-25 16:30 ` Andy Poling
2009-11-25 21:06 ` Christoph Hellwig
2009-11-25 22:10 ` Eric Sandeen [this message]
2009-11-25 22:29 ` Richard Sharpe
2009-11-26 14:19 ` Ofer Heifetz
2009-11-26 14:24 ` Christoph Hellwig
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=4B0DAB5C.2080607@sandeen.net \
--to=sandeen@sandeen.net \
--cc=andy@realbig.com \
--cc=hch@infradead.org \
--cc=oferh@marvell.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.