xfs
[Top] [All Lists]

Re: XFS realtime O_DIRECT failures

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS realtime O_DIRECT failures
From: Alan Cook <acook@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 10 Nov 2011 17:38:57 -0500
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <20111110222424.GB2386@dastard>
References: <loom.20111108T180925-222@xxxxxxxxxxxxxx> <20111109080133.GB20604@xxxxxxxxxxxxx> <CAGedfzmcmfLXhBEzm9yhpRQTf-7dnMenXqe0FABAzJgP0rxSUA@xxxxxxxxxxxxxx> <20111109223314.GQ5534@dastard> <CAGedfznrW4c9Bf3D-7+CEUUa-_u5iVzh+KskwFS9bom0s=C=gQ@xxxxxxxxxxxxxx> <20111110222424.GB2386@dastard>
On Thu, Nov 10, 2011 at 5:24 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> XFS metadata IO is tagged with REQ_META, so the block layer can
> easily distinguish it from data IO.  Even if the version if XFS you
> are using is not doing this, it's rather simple to add it to
> _xfs_buf_ioapply().
>
> With that, your problem at the block layer goes away, and hence the
> need to separate data from metadata at the filesystem layer goes
> away, too.

Thanks.  I'll take a look into my particular version of XFS.  That tag
may well solve my problems.

> > Unfortunately they do not tell a lot.  Running xfs_check/xfs_repair -n
> > prior to running the test reports no errors.  However, attempting to
> > run it after the test fails results in an indefinite I/O block (state
> > of D+ for the process).  In fact, if I run the test utility twice, it
> > results in a hung system.
>
> That sounds like you have a problem with your block device or
> underlying storage, not a filesystem problem....

I had the same thought at first, but I get the same behavior using
only ramdisks.  This issue only occurs when using RT subvolumes.
Using XFS without separating the data and meta data (e.g. all on one
device) has no issues.

<Prev in Thread] Current Thread [Next in Thread>