Re: XFS realtime O_DIRECT failures

From: Dave Chinner <david@fromorbit.com>
To: Alan Cook <acook@visionpointsystems.com>
Cc: Christoph Hellwig <hch@infradead.org>, linux-xfs@oss.sgi.com
Subject: Re: XFS realtime O_DIRECT failures
Date: Thu, 10 Nov 2011 09:33:14 +1100	[thread overview]
Message-ID: <20111109223314.GQ5534@dastard> (raw)
In-Reply-To: <CAGedfzmcmfLXhBEzm9yhpRQTf-7dnMenXqe0FABAzJgP0rxSUA@mail.gmail.com>

On Wed, Nov 09, 2011 at 08:25:02AM -0600, Alan Cook wrote:
> On Wed, Nov 9, 2011 at 2:01 AM, Christoph Hellwig <hch@infradead.org> wrote:
> > It might sounda a bit harsh, but the problem is that use the realtime
> > subvolume.  It hasn't really been maintained or been part of the tested
> > setup, and most distros in the know ship with it disabled.  I went
> > through and fixed it when we got bug reports once in a while, and I'm
> > happy to look into your issues once I get a bit spare time, but in
> > general use is highly discouraged.   Is there any specific reason why
> > you want to use the RT subvolume?
> 
> I am streaming high-resolution images to be compressed through
> hardware and need to separate the data from the meta data for
> compression purposes.  XFS gave that for free if I used a realtime
> subvolume.

I'm not sure from that description just why the realtime volume adds
any benefit to your workflow. Separation of data and metadata is
does not provide you with data compression, so you must be doing
something different with the real time device to acheive
compression. Any details on that aspect of your setup?

I'm really only trying to understand why you need such a setup - it
helps to understand the full use case you have before trying to
determine if there is a better way of acheiving your end goal....

> I originally started on kernel 2.6.27 (CentOS 5.5) which had no issues
> with the RT subvolume and direct writes.  I was then moved to kernel
> 2.6.32 (SUSE 11) which does have the issue.
> 
> I appreciate your willingness to help.  Are there any alternatives or
> suggestions for splitting the data and meta data?  Any direction you
> can give on where to start looking or what I could do to track down
> the exact cause of the bug?

I have long term plans for metadata/data separation involving a
separate metadata device (i.e. so metadata space can be placed on
different media, grown separately from data space, we don't give up
any of the inherent parallelism in allocation like we do for the RT
device, etc), but that's a long way off yet so not a solution to
your problem.

As to your current problem, it's got a NULL pointer dereference
trying to lock the per-ag structure. That means the per-ag lookup
failed, which implies that the RT freespace bitmap may be corrupt
and it's tried to read a bitmap block that is apparently beyond the
end of the filesystem.  What does xfs_check/xfs_repair -n tell you
about the filesystem state?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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