From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: Sender: linux-kernel-owner@vger.kernel.org List-ID: 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.