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 68A17C433EF for ; Wed, 12 Jan 2022 05:59:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8ACAA6B0120; Wed, 12 Jan 2022 00:59:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 85C0C6B0121; Wed, 12 Jan 2022 00:59:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74C006B0122; Wed, 12 Jan 2022 00:59:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0164.hostedemail.com [216.40.44.164]) by kanga.kvack.org (Postfix) with ESMTP id 6668F6B0120 for ; Wed, 12 Jan 2022 00:59:13 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2384B9526C for ; Wed, 12 Jan 2022 05:59:13 +0000 (UTC) X-FDA: 79020582186.27.E63DBF1 Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) by imf21.hostedemail.com (Postfix) with ESMTP id B499C1C0007 for ; Wed, 12 Jan 2022 05:59:12 +0000 (UTC) Received: by mail-il1-f175.google.com with SMTP id d14so1359394ila.1 for ; Tue, 11 Jan 2022 21:59:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ACMpWSrFwAdDKF+3r9MKatrSc/6Gehgs1ic1U6k8wsY=; b=qZrVWTrxjfCoQu9MS1OYKdefkTOJjrG8gbYpC7V0hqYETG+j2NXJotJxL86ra364db Jym4fmymkIXR1lV6AvSTTH84TL/ahsApZCSdC1bWufyTFJJu5Zv486fYIbRBPOJBDAKp EioBd/3SqZYJOVBy1nYqrg6F2DCfhcDc1yEAni+qvvR1hlsBX4vaDSScHpILqm0OkgBB KKGiAhaKtamT0T4jOBvvhcb7udydVYrQRmtMTurRBPRCPdnWPRYsRis4DLjPUdt5Sj80 q+dHWyH/49ZB+J74IPkFskNDEGJv2OLjRfR0Z1HWZlRRyIlgcxtVzjc2f93i3OyURbYm jH0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ACMpWSrFwAdDKF+3r9MKatrSc/6Gehgs1ic1U6k8wsY=; b=eajl33QuL70ljGzEKIl18DLQBmDwKznMTOj2FgLQtFKnOfXfUoUu2BaQH+dXjr/7fF Ggui+kbVFcFCWD54464jSHRoP1bfn2XfP8OMP8YxBBsu/XaSPpE6j03CccO4uaNlok8y rQRNXL39Ag+BTAPvCBaSQ0sGTvCic8kgOxkNvGVWRchv13z/dt4w5IvwPXMBZf4l+d1Y BrQd5r4scNtOruImmgwCMIU2TduRGmd5VX29iaQLvvjH1AWh4wQrbOPq48D0SAhmMTz5 aLN6CxpzjyL3H7R4cBDI/8bHJXBhj6cX9X9IOTyqJ4WtIJtxPdUbq8z0ooP0lN8n6faE qxcQ== X-Gm-Message-State: AOAM533rGQUL5v0WtVjlALj4O6PR7SF0G5KS8STDfxxn6n3IYs1RqYy0 LIGe4DSktOBo2SFsISJ1yt5790SE0JvmuiX3dDs= X-Google-Smtp-Source: ABdhPJzETOtymjRkDI8IZ8pX/RXyE9VcI1atwv0+/iTfVfE1LA1UNkU7traqhH9XpXRExx5dOHa9b2j4pNib7RyVAlk= X-Received: by 2002:a05:6e02:b21:: with SMTP id e1mr4361819ilu.254.1641967152032; Tue, 11 Jan 2022 21:59:12 -0800 (PST) MIME-Version: 1.0 References: <20211116220742.584975-1-krisman@collabora.com> <87fspv9gr2.fsf@collabora.com> <875yqp1w04.fsf@collabora.com> In-Reply-To: <875yqp1w04.fsf@collabora.com> From: Amir Goldstein Date: Wed, 12 Jan 2022 07:59:01 +0200 Message-ID: Subject: Re: [PATCH 0/2] shmem: Notify user space when file system is full To: Gabriel Krisman Bertazi Cc: Hugh Dickins , Andrew Morton , Linux MM , Jan Kara , Matthew Bobrowski , Khazhismel Kumykov , kernel@collabora.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: B499C1C0007 X-Stat-Signature: 9ycaoma8ysqd914y3ccpny34z4yt81f3 Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=qZrVWTrx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of amir73il@gmail.com designates 209.85.166.175 as permitted sender) smtp.mailfrom=amir73il@gmail.com X-HE-Tag: 1641967152-693715 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: > > 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. > In the real world, ENOSPC can often be anticipated way ahead of time and sysadmins are practically required to take action when storage space is low. Getting near 90% full filesystem is not healthy on many traditional disk filesystems and causes suboptimal performance and in many cases (especially cow filesystems) may lead to filesystem corruption. All that said, yes, *sometimes* ENOSPC cannot be anticipated, but EIO can never be anticipated, so why are we talking about ENOSPC? Focusing on ENOSPC seems too specific for the purpose of adding fsnotify monitoring for filesystem ephemeral errors. The problem with fsnotify events for ephemeral filesystem errors and that there can be a *lot* of them compared to filesystem corruption errors that would usually put the filesystem in an "emergency" state and stop the events from flooding. For that reason I still think that a polling API for fs ephemeral errors is a better idea. w.r.t to ephemeral errors on writeback we already have syncfs() as a means to provide publish/subscribe API for monitoring applications, to check if there was any error since last check, but we do not have an API that provides this information without the added costs of performing syncfs(). IMO, a proper solution would look something like this: /* per-sb errseq_t for reporting writeback errors via syncfs */ errseq_t s_wb_err; + /* per-sb errseq_t for reporting vfs errors via fstatfs */ + errseq_t s_vfs_err; fstatfs() is just an example that may be a good fit for fs monitoring applications we can add the error state in f_spare space, but we can also create a dedicated API for polling for errors. Same API can be used to poll for wb errors without issuing syncfs(). Thanks, Amir.