xfs
[Top] [All Lists]

Re: [PATCH 1/6] xfs: don't try to mark uncached buffers stale on error.

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 1/6] xfs: don't try to mark uncached buffers stale on error.
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 13 Dec 2013 09:24:38 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131212163629.GA2894@xxxxxxxxxxxxx>
References: <1386826478-13846-1-git-send-email-david@xxxxxxxxxxxxx> <1386826478-13846-2-git-send-email-david@xxxxxxxxxxxxx> <20131212163629.GA2894@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Dec 12, 2013 at 08:36:29AM -0800, Christoph Hellwig wrote:
> I really don't like how this makes even more of a mess out of the
> already convoluted xfs_bioerror/xfs_bioerror_else maze.  Can we
> maybe first merge them and document the difference before adding
> even more special case branches?
> 
> Also most uses of uncached buffers use xfsbdstrat, where we can do
> error handling straight in the caller instead of playing with all
> the flags manipulation mess.  In all these cases no one but the
> caller can find these buffers anyway, so doing all this on an
> I/O error is pointless.
> 
> The only buffer where any of this matters is the superblock one,
> and given that we re-read it on mount anyway I wonder if we should
> just make it a regular buffer again and let all this mess just
> disappear.

Ok, I agree it is a bit messy, but that code is already pretty ugly.
I'd like to get this fix in first, because it's causing oopses in
roughly 30% of my local xfstests runs on a couple of VMs, so I'd
prefer to get the fix out there now and do the cleanup as a separate
patch series. Would that be an acceptible approach to take here from
your perspective?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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