xfs
[Top] [All Lists]

Re: XFS hole punch races

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS hole punch races
From: Willy Tarreau <w@xxxxxx>
Date: Sun, 5 Jun 2016 07:16:54 +0200
Cc: Ben Hutchings <ben@xxxxxxxxxxxxxxx>, Jan Kara <jack@xxxxxxx>, stable@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160605021654.GX26977@dastard>
References: <20160322155740.GB28772@xxxxxxxxxxxxx> <1465060270.2847.149.camel@xxxxxxxxxxxxxxx> <20160604232800.GW26977@dastard> <1465089572.2847.180.camel@xxxxxxxxxxxxxxx> <20160605021654.GX26977@dastard>
User-agent: Mutt/1.6.0 (2016-04-01)
Dave,

On Sun, Jun 05, 2016 at 12:16:54PM +1000, Dave Chinner wrote:
> On Sun, Jun 05, 2016 at 02:19:32AM +0100, Ben Hutchings wrote:
> > On Sun, 2016-06-05 at 09:28 +1000, Dave Chinner wrote:
> > > You do realise that this sort of backport effectively makes the
> > > stable kernels unsupportable by the upstream XFS developers? You're
> > > taking random changes from the upstream kernel until the kernel
> > > compiles, and then mostly hoping that it works.
> > 
> > I'm applying slightly more intelligence than that, but of course I'm
> > not an XFS developer.
> 
> Sorry, Ben, I didn't mean to imply you hadn't done your due diligence
> properly. It's more a case of lots of things around these patches
> also changed, and from that perspective the changes are effective a
> random selection of changes spread across several years of
> development.
> 
> It's subtle things, like changes to how IO completion is processed
> (especially for AIO), etc that the backported code might depend on
> for correct behaviour but aren't in the older kernels. These sorts
> of subtle problems are typically only discovered by users with
> uncommon applications and/or load....

Does this mean that as a rule of thumb we'd rather avoid backporting
XFS fixes unless they seem really obvious (or at all) ?

Thanks,
Willy

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