From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 020977F51 for ; Mon, 31 Mar 2014 15:18:02 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 6D454AC003 for ; Mon, 31 Mar 2014 13:18:02 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id 5O1hkRDMKzfQdCON for ; Mon, 31 Mar 2014 13:18:00 -0700 (PDT) Date: Tue, 1 Apr 2014 07:17:57 +1100 From: Dave Chinner Subject: Re: [RFC, PATCH 0/6] xfs: delalloc, DIO and corruption.... Message-ID: <20140331201757.GC17603@dastard> References: <1395396710-3824-1-git-send-email-david@fromorbit.com> <20140331172243.GB63718@bfoster.bfoster> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140331172243.GB63718@bfoster.bfoster> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Brian Foster Cc: Al@disappointment.disaster, Viro@disappointment.disaster, viro@ZenIV.linux.org.uk, xfs@oss.sgi.com On Mon, Mar 31, 2014 at 01:22:43PM -0400, Brian Foster wrote: > On Fri, Mar 21, 2014 at 09:11:44PM +1100, Dave Chinner wrote: > > Hi folks, > > > > This patch series mostly shuts a can of worms that Al opened when he > > found the cause of the generic/263 fsx failures. The fix for that is > > patch 6 of this series, but, well, there are a bunch of other > > problems that need to be fixed before making that change. > > > > Basically, the direct Io block mapping behaviour was covering up a > > bunch of other bugs in the delayed allocation extent/page cache > > state coherency mappings. Essentially, we punch out the page cache > > in quite a few places without first cleaning up delayed allocation > > extents over that range and that exposes all sorts of nasty issues > > once the direct IO mapping changes are made. All of these are > > existing problems, most of them are very unlikely to be seen in the > > wild. > > > > This patch set passes xfstests on a 4k block size/4k page size > > config with out problems. However, there is still a fsx failure in > > generic/127 on 1k block size/4k page size configurations that I > > haven't yet tracked down. That test was failing occasionally before > > this patch set as well, so it may be a completely unrelated problem. > > > > The sad fact of this patchset is it is mostly playing whack-a-mole > > with visible symptoms of bugs. It drives home the fact that > > bufferheads and the keeping of internal filesystem state attached to > > the page cache simply isn't a verifiable architecture. After > > spending several days of doing nothing else but tracking down these > > inconsistencies i can only conclude that the code is complex, > > fragile and extremely difficult to verify that behaviour is correct. > > As such, I doubt that the fixes are entirely correct, so I'm left > > with using fsx and fsstress to tell me if I've broken anything. > > > > Eyeballs appreciated, as is test results. > > > > I had an xfstests running against this (on for-next) over the weekend > and it hit the following bug on xfs/297: > > [ 6408.168767] kernel BUG at fs/xfs/xfs_aops.c:1336! > [ 6408.169542] invalid opcode: 0000 [#1] SMP Ok, so that's found another stale delalloc range where there shouldn't be. I know there were still problems when I left because generic/127 was failing on 1k block size filesystems, but I haven't yet had a chance to get back to determine if the bug was the broken code in xfs_check_page_types() that Dan Carpenter noticed. Were you running with that fix? Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs