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 D3331C433F5 for ; Wed, 12 Jan 2022 03:19:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 236216B0114; Tue, 11 Jan 2022 22:19:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E59D6B0115; Tue, 11 Jan 2022 22:19:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AD816B0116; Tue, 11 Jan 2022 22:19:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0071.hostedemail.com [216.40.44.71]) by kanga.kvack.org (Postfix) with ESMTP id F10F66B0114 for ; Tue, 11 Jan 2022 22:19:29 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A1AF5181951FF for ; Wed, 12 Jan 2022 03:19:29 +0000 (UTC) X-FDA: 79020179658.10.0215011 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by imf10.hostedemail.com (Postfix) with ESMTP id 15436C0008 for ; Wed, 12 Jan 2022 03:19:28 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: krisman) with ESMTPSA id 4C4341F44886 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1641957567; bh=di5IEoEpnKDEzNLyXIGFWoj1e5RU6o2juy0Yihvn1Wo=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=JSI01Y6FZ1P1Ey4wlz9pYuq1ACkIc3VJO4X0tS8B6qs2rL7dWWs63JOnSzZDW0ZC3 4wCgZaYLdOpc21sUuccv8xHr+XR2oFHRO13ZJcbKU0VhqgBA2nbQGCsB5NGdjWQ/RT rtmfQzQISQFblRABRhHYJbJZeNh0Z2SBjEHAMcUOfNtvlY6OrXI/2X16R8Q90VyM15 NmKue00kZUDiBFbY2vjpAI0B1TZEHdjpVGGKuXveuJwSqUrUC907bo+RjjidmquBae 0f8J4VkkQ9EkHRZhrVYoMKpjaXCidsmNCcQUIUcWLhJmAxNRE6/X5OaQeAQe1r3vpQ plpFv285ujrpQ== From: Gabriel Krisman Bertazi To: Amir Goldstein Cc: Hugh Dickins , Andrew Morton , Linux MM , Jan Kara , Matthew Bobrowski , Khazhismel Kumykov , kernel@collabora.com Subject: Re: [PATCH 0/2] shmem: Notify user space when file system is full Organization: Collabora References: <20211116220742.584975-1-krisman@collabora.com> <87fspv9gr2.fsf@collabora.com> Date: Tue, 11 Jan 2022 22:19:23 -0500 In-Reply-To: (Amir Goldstein's message of "Tue, 11 Jan 2022 09:50:42 +0200") Message-ID: <875yqp1w04.fsf@collabora.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 15436C0008 X-Stat-Signature: zbimjds4wy67yed4yqdijmcw31qs8jze Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=collabora.com header.s=mail header.b=JSI01Y6F; spf=pass (imf10.hostedemail.com: domain of krisman@collabora.com designates 46.235.227.227 as permitted sender) smtp.mailfrom=krisman@collabora.com; dmarc=pass (policy=none) header.from=collabora.com X-HE-Tag: 1641957568-935158 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Amir Goldstein writes: > On Tue, Jan 11, 2022 at 3:57 AM Gabriel Krisman Bertazi > wrote: >> >> Amir Goldstein writes: >> >> > Two things bother me about this proposal. >> > One is that it makes more sense IMO to report ENOSPC events >> > from vfs code. >> >> Hi Amir, >> >> I reimplemented this with FS_WB_ERROR in the branch below. It reports >> writeback errors on mapping_set_error, as suggested. >> >> https://gitlab.collabora.com/krisman/linux/-/tree/wb-error >> >> It is a WIP, and I'm not proposing it yet, cause I'm thinking about the >> ENOSPC case a bit more... >> >> > Why should the requirement to monitor ENOSPC conditions be specific to tmpfs? >> > Especially, as I mentioned, there are already wrappers in place to report >> > writeback errors on an inode (mapping_set_error), where the fsnotify hook >> > can fit nicely. >> >> mapping_set_error would trigger the ENOSPC event only when it happens on >> an actual writeback error (i.e. BLK_STS_NOSPC), which is not the main >> case I'm solving here. In fact, most of the time, -ENOSPC will happen >> before any IO is submitted, for instance, if an inode could not be >> allocated during .create() or a block can't be allocated in >> .write_begin(). In this case, it isn't really a writeback error >> (semantically), and it is not registered as such by any file system. >> > > I see. > But the question remains, what is so special about shmem that > your use case requires fsnotify events to handle ENOSPC? > > Many systems are deployed on thin provisioned storage these days > and monitoring the state of the storage to alert administrator before > storage gets full (be it filesystem inodes or blocks or thinp space) > is crucial to many systems. > > Since the ENOSPC event that you are proposing is asynchronous > anyway, what is the problem with polling statfs() and meminfo? Amir, I spoke a bit with Khazhy (in CC) about the problems with polling the existing APIs, like statfs. He has been using a previous version of this code in production to monitor machines for a while now. Khazhy, feel free to pitch in with more details. Firstly, I don't want to treat shmem as a special case. The original patch implemented support only for tmpfs, because it was a fs specific solution, but I think this would be useful for any other (non-pseudo) file system in the kernel. The use case is similar to the use case I brought up for FAN_FS_ERROR. A sysadmin monitoring a fleet of machines wants to be notified when a service failed because of lack of space, without having to trust the failed application to properly report the error. Polling statfs is prone to missing the ENOSPC occurrence if the error is ephemeral from a monitoring tool point of view. Say the application is writing a large file, hits ENOSPC and, as a recovery mechanism, removes the partial file. If that happens, a daemon might miss the chance to observe the lack of space in statfs. Doing it through fsnotify, on the other hand, always catches the condition and allows a monitoring tool/sysadmin to take corrective action. > I guess one difference is that it is harder to predict page allocation failure > that causes ENOSPC in shmem, but IIUC, your patch does not report > an fsevent in that case only in inode/block accounting error. > Or maybe I did not understand it correctly? Correct. But we cannot predict the enospc, unless we know the application. I'm looking for a way for a sysadmin to not have to rely on the application caring about the file system size. -- Gabriel Krisman Bertazi