From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E09F5C43334 for ; Tue, 4 Sep 2018 09:29:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8C26520867 for ; Tue, 4 Sep 2018 09:29:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C26520867 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=BitWizard.nl Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727406AbeIDNxz (ORCPT ); Tue, 4 Sep 2018 09:53:55 -0400 Received: from cust-95-128-94-82.breedbanddelft.nl ([95.128.94.82]:43930 "EHLO cust-95-128-94-82.breedbanddelft.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727201AbeIDNxz (ORCPT ); Tue, 4 Sep 2018 09:53:55 -0400 Received: by abra2.bitwizard.nl (Postfix, from userid 1000) id 99C8C13FC8F; Tue, 4 Sep 2018 11:29:38 +0200 (CEST) Date: Tue, 4 Sep 2018 11:29:38 +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: <20180904092938.GJ11854@BitWizard.nl> References: <20180904075347.GH11854@BitWizard.nl> 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 04:58:59PM +0800, 焦晓冬 wrote: > As for suggestion, maybe the error flag of inode/mapping, or the entire inode > should not be evicted if there was an error. That hopefully won't take much > memory. On extreme conditions, where too much error inode requires staying > in memory, maybe we should panic rather then spread the error. Again you are hoping it will fit in memory. In an extreme case it won't fit in memory. Tyring to come up with heuristics about when to remember and when to forget such things from the past is very difficult. Think of my comments as: "it's harder than you think", not as "can't be done". 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.