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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9541C433F5 for ; Tue, 19 Apr 2022 03:42:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1DC088D002F; Mon, 18 Apr 2022 23:42:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 189A28D0026; Mon, 18 Apr 2022 23:42:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 079FD8D002F; Mon, 18 Apr 2022 23:42:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id EC58B8D0026 for ; Mon, 18 Apr 2022 23:42:07 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id AF4F680530 for ; Tue, 19 Apr 2022 03:42:07 +0000 (UTC) X-FDA: 79372230294.19.998C2BA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf09.hostedemail.com (Postfix) with ESMTP id 84E2A140005 for ; Tue, 19 Apr 2022 03:42:06 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5314160FC6; Tue, 19 Apr 2022 03:42:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7281DC385A1; Tue, 19 Apr 2022 03:42:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1650339725; bh=Col+AuMuVCxgczTCBn+vOlTtSikyZMVqXjSHcD/QGsc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TyU5vl0JDmVQsivRL11MJ6DW2ONKqOvANTg1zGc5zvY4rZlV7JSuq2+3jBKMPGwwV zq/It8qZOZ+DZVjS9a8UbUzgbOiSK6XckuaCfJXq1jciaBhNX+RHBYIoG7O+Q52CFL zE6BaGe6Yj1ctjHwpg74A2WIiZrb4kpS9i2N1l4s= Date: Mon, 18 Apr 2022 20:42:04 -0700 From: Andrew Morton To: Gabriel Krisman Bertazi Cc: hughd@google.com, amir73il@gmail.com, viro@zeniv.linux.org.uk, kernel@collabora.com, Khazhismel Kumykov , Linux MM , linux-fsdevel Subject: Re: [PATCH v3 0/3] shmem: Allow userspace monitoring of tmpfs for lack of space. Message-Id: <20220418204204.0405eda0c506fd29e857e1e4@linux-foundation.org> In-Reply-To: <20220418213713.273050-1-krisman@collabora.com> References: <20220418213713.273050-1-krisman@collabora.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 84E2A140005 X-Stat-Signature: us4e7iiog1pyxzdkptn6rdpriz6xcpwj Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=TyU5vl0J; spf=pass (imf09.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam01 X-HE-Tag: 1650339726-334850 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000013, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 18 Apr 2022 17:37:10 -0400 Gabriel Krisman Bertazi wrote: > When provisioning containerized applications, multiple very small tmpfs "files"? > are used, for which one cannot always predict the proper file system > size ahead of time. We want to be able to reliably monitor filesystems > for ENOSPC errors, without depending on the application being executed > reporting the ENOSPC after a failure. Well that sucks. We need a kernel-side workaround for applications that fail to check and report storage errors? We could do this for every syscall in the kernel. What's special about tmpfs in this regard? Please provide additional justification and usage examples for such an extraordinary thing. > It is also not enough to watch > statfs since that information might be ephemeral (say the application > recovers by deleting data, the issue can get lost). We could fix the apps? Heck, you could patch libc's write() to the same effect. > For this use case, > it is also interesting to differentiate IO errors caused by lack of > virtual memory from lack of FS space. More details, please. Why interesting? What actions can the system operator take based upon this information? Whatever that action is, I see no user-facing documentation which guides the user info how to take advantage of this?