Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2256172imm; Tue, 4 Sep 2018 00:55:43 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaUXLb+Zn9T3NB8wq61PLr0bmo6mN7bkCrIn9neP9rICiok2+jKNft3Eqb8hT8QiXJ5WCrP X-Received: by 2002:a62:435c:: with SMTP id q89-v6mr34032045pfa.135.1536047743927; Tue, 04 Sep 2018 00:55:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536047743; cv=none; d=google.com; s=arc-20160816; b=U7620+WxxFpwUCGoJcAF9nHdXAeB21VwpyjbExUpWJ4lyyOxwO1MlL8OKBpFXES3Bv d/XOIukvqZ45PorXkjG/nfxhd+LEOE1pGLoiN2Cc0Jlcd5Vmm7MCq2H3bCBI5CHHEXTN WB8OQKZNpCWsk/bHlxGQmZGhTvakFPjugFInF2Frr4ituTWeqU/WH1tsN3NErkLynDQc mDqAgsYZQ9lEc3HZg/C+YRNfmh0HF2uWXZusjEztaLKJsali//rgLQI6tjcbuIVydQgm 5jLTGboUDYLJDoIABgvLSoMNMGDaF1XcKWVFCco0rS/ipEEAwMNCBsSWZtgS35FVrfTE 447A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=phPuITByU0walkoomb1XEQsSnJxhh/0FxRjyj3CVC2o=; b=JNLZ7NNjrSmVPybOWAAYqaI3/+QmgIo6H+iG9C7Qg1fOv2oyTStnsTUxyMDszA6knX JRxV9YWBdHRCDrYSEAxsQau4Q3VOJQicIT63PtqYA4swoG4o+3rnaCXTD5wNvhfKvmV8 W2HNuTEJEJbm5UyGol8CJuoi4Es8s8rqcUH0HNVS1UWOgEUHNJG2su7OCxmdRAPFtJXo tSPJqunsSCPLe54x5zypP5xDh0X1WO9koYEIfVOhr6EZxqhILWZjLsOR5MJ/ZQuuhDak VD+CZZPL214Dp8tqIKBvXDq+pbIwlzNPSwsc/za1eNMgHp9z9ZPpzsn5e+XtmAcINaTl RznA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c126-v6si22170643pfa.130.2018.09.04.00.55.28; Tue, 04 Sep 2018 00:55:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726222AbeIDMRo (ORCPT + 99 others); Tue, 4 Sep 2018 08:17:44 -0400 Received: from cust-95-128-94-82.breedbanddelft.nl ([95.128.94.82]:41882 "EHLO cust-95-128-94-82.breedbanddelft.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725992AbeIDMRo (ORCPT ); Tue, 4 Sep 2018 08:17:44 -0400 Received: by abra2.bitwizard.nl (Postfix, from userid 1000) id 2C58D13FC78; Tue, 4 Sep 2018 09:53:47 +0200 (CEST) Date: Tue, 4 Sep 2018 09:53:47 +0200 From: Rogier Wolff To: =?utf-8?B?54Sm5pmT5Yas?= Cc: jlayton@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: POSIX violation by writeback error Message-ID: <20180904075347.GH11854@BitWizard.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: BitWizard B.V. User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 04, 2018 at 02:32:28PM +0800, 焦晓冬 wrote: > Hi, > > After reading several writeback error handling articles from LWN, I > begin to be upset about writeback error handling. > > Jlayton's patch is simple but wonderful idea towards correct error > reporting. It seems one crucial thing is still here to be fixed. Does > anyone have some idea? > > The crucial thing may be that a read() after a successful > open()-write()-close() may return old data. > > That may happen where an async writeback error occurs after close() > and the inode/mapping get evicted before read(). Suppose I have 1Gb of RAM. Suppose I open a file, write 0.5Gb to it and then close it. Then I repeat this 9 times. Now, when writing those files to storage fails, there is 5Gb of data to remember and only 1Gb of RAM. I can choose any part of that 5Gb and try to read it. Please make a suggestion about where we should store that data? In the easy case, where the data easily fits in RAM, you COULD write a solution. But when the hardware fails, the SYSTEM will not be able to follow the posix rules. Roger. -- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work.