From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 27 Sep 2018 10:27:38 -0400 From: "Theodore Y. Ts'o" To: Jeff Layton Cc: Alan Cox , =?utf-8?B?54Sm5pmT5Yas?= , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Rogier Wolff , Matthew Wilcox Subject: Re: POSIX violation by writeback error Message-ID: <20180927142738.GA27040@thunk.org> References: <486f6105fd4076c1af67dae7fdfe6826019f7ff4.camel@redhat.com> <20180925003044.239531c7@alans-desktop> <0662a4c5d2e164d651a6a116d06da380f317100f.camel@redhat.com> <20180925154627.GC2933@thunk.org> <23cd68a665d27216415dc79367ffc3bee1b60b86.camel@redhat.com> <20180925223054.GH2933@thunk.org> <51b401b82356c2d8e124bb8701f310afd98e0838.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51b401b82356c2d8e124bb8701f310afd98e0838.camel@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: On Thu, Sep 27, 2018 at 08:43:10AM -0400, Jeff Layton wrote: > > Basically, the problem (as I see it) is that we can end up evicting > uncleanable data from the cache before you have a chance to call fsync, > and that means that the results of a read after a write are not > completely reliable. Part of the problem is that people don't agree on what the problem is. :-) The original posting was from someone who claimed it was a "POSIX violation" if a subsequent read returns *successfully*, but then the writeback succeeds. Other people are worried about this problem; yet others are worried about the system wedging and OOM-killing itself, etc. The problem is that in the face of I/O errors, it's impossible to keep everyone happy. (You could make the local storage device completely reliable, with a multi-million dollar storage array with remote replication, but then the CFO won't be happy; and other people were talking about making things work with cheap USB thumb drives and laptops. This is the very definition of an over-constained problem.) - Ted