From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: [PATCH] clear PageError bit in msync & fsync Date: Tue, 09 Nov 2010 14:33:29 -0500 Message-ID: <4CD9A209.6070807@redhat.com> References: <20101109114422.3918e7f6@annuminas.surriel.com> <20101109142109.224267d0@corrin.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org, esandeen@redhat.com, jmoyer@redhat.com, linux-fsdevel@vger.kernel.org To: Jeff Layton Return-path: Received: from mx1.redhat.com ([209.132.183.28]:49435 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753671Ab0KITdj (ORCPT ); Tue, 9 Nov 2010 14:33:39 -0500 In-Reply-To: <20101109142109.224267d0@corrin.poochiereds.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 11/09/2010 02:21 PM, Jeff Layton wrote: > This does leave the page in sort of a funky state. The uptodate bit > will still probably be set, but the dirty bit won't be. The page will > be effectively "disconnected" from the backing store until someone > writes to it. > > I suppose though that this is the best that can reasonably be done in > this situation however... I spent a few days looking for alternatives, and indeed I found nothing better... There are essentially two possibilities: 1) the VM can potentially be filled up with uncleanable dirty pages, or 2) pages that hit an IO error are left in a clean state, so they can be reclaimed under memory pressure Alternative 1 could cause the entire system to deadlock, while option 2 puts the onus on userland apps to rewrite the data from a failed msync/fsync. Currently the VM has behaviour #2 which is preserved with my patch. The only difference with my patch is, we won't keep returning -EIO on subsequent, error free, msync or fsync calls to files that had an IO error at some previous point in the past. -- All rights reversed