Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756554Ab0FANko (ORCPT ); Tue, 1 Jun 2010 09:40:44 -0400 Received: from cantor.suse.de ([195.135.220.2]:55446 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754623Ab0FANkm (ORCPT ); Tue, 1 Jun 2010 09:40:42 -0400 Subject: Re: Wrong DIF guard tag on ext2 write From: James Bottomley To: Chris Mason Cc: Christof Schmitt , Boaz Harrosh , "Martin K. Petersen" , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org In-Reply-To: <20100601133341.GK8980@think> References: <20100531112817.GA16260@schmichrtp.mainz.de.ibm.com> <1275318102.2823.47.camel@mulgrave.site> <4C03D5FD.3000202@panasas.com> <20100601103041.GA15922@schmichrtp.mainz.de.ibm.com> <1275398876.21962.6.camel@mulgrave.site> <20100601133341.GK8980@think> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Jun 2010 08:40:37 -0500 Message-ID: <1275399637.21962.11.camel@mulgrave.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1650 Lines: 39 On Tue, 2010-06-01 at 09:33 -0400, Chris Mason wrote: > On Tue, Jun 01, 2010 at 01:27:56PM +0000, James Bottomley wrote: > > On Tue, 2010-06-01 at 12:30 +0200, Christof Schmitt wrote: > > > What is the best strategy to continue with the invalid guard tags on > > > write requests? Should this be fixed in the filesystems? > > > > For write requests, as long as the page dirty bit is still set, it's > > safe to drop the request, since it's already going to be repeated. What > > we probably want is an error code we can return that the layer that sees > > both the request and the page flags can make the call. > > I'm afraid this isn't entirely true. The FS tends to do this: > > change the page > <---------> truck sized race right here where the page is clean > mark the page dirty Would it be too much work in the fs to mark the page dirty before you begin altering it (and again after you finish, just in case some cleaner noticed and initiated a write)? Or some other flag that indicates page under modification? All the process controlling the writeout (which is pretty high up in the stack) needs to know is if we triggered the check error by altering the page while it was in flight. I agree that a block based retry would close all the holes ... it just doesn't look elegant to me that the fs will already be repeating the I/O if it changed the page and so will block. James James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/