Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754969AbdCIPG4 (ORCPT ); Thu, 9 Mar 2017 10:06:56 -0500 Received: from imap.thunk.org ([74.207.234.97]:34700 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754746AbdCIPGx (ORCPT ); Thu, 9 Mar 2017 10:06:53 -0500 Date: Thu, 9 Mar 2017 09:21:37 -0500 From: "Theodore Ts'o" To: Jeff Layton Cc: Jan Kara , Ross Zwisler , viro@zeniv.linux.org.uk, konishi.ryusuke@lab.ntt.co.jp, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-nilfs@vger.kernel.org, NeilBrown Subject: Re: [PATCH 0/3] mm/fs: get PG_error out of the writeback reporting business Message-ID: <20170309142137.lz7cba4was3jfyyt@thunk.org> Mail-Followup-To: Theodore Ts'o , Jeff Layton , Jan Kara , Ross Zwisler , viro@zeniv.linux.org.uk, konishi.ryusuke@lab.ntt.co.jp, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-nilfs@vger.kernel.org, NeilBrown References: <20170305133535.6516-1-jlayton@redhat.com> <1488724854.2925.6.camel@redhat.com> <20170306230801.GA28111@linux.intel.com> <20170307102622.GB2578@quack2.suse.cz> <20170309025725.5wrszri462zipiix@thunk.org> <20170309090449.GD15874@quack2.suse.cz> <1489056471.2791.2.camel@redhat.com> <20170309110225.GF15874@quack2.suse.cz> <1489063392.2791.8.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1489063392.2791.8.camel@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 614 Lines: 14 On Thu, Mar 09, 2017 at 07:43:12AM -0500, Jeff Layton wrote: > > Maybe we need a systemwide (or fs-level) tunable that makes ENOSPC a > transient error? Just have it hang until we get enough space when that > tunable is enabled? Or maybe we need a new kernel-internal errno (ala ERESTARSYS) which means it's a "soft ENOSPC"? It would get translated to ENOSPC if it gets propagated to userspace, but that way for devices like dm-thin or other storage array with thin volumes, it could send back a soft ENOSPC, while for file systems where "ENOSPC means ENOSPC", we can treat those as a hard ENOSPC. - Ted