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 shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 811A8C43458 for ; Sun, 5 Jul 2026 05:04:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kernelnewbies.org; s=mail; h=Content-Transfer-Encoding:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Cc: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=N5ssZcByGzvE+ni2TXImMhtZbq1/xjbO3jb27HimXNM=; b=FwDoeaHx+GvktvrYuumh/yFte1 IrWHXLuTVBviEZAl7qObguB4u+Uvai49CDr+cq/KRqAQkf3Vsaw9xeAo+XVCGMThY+ZxWZ6NRZs9b W33l9N/32zHGAy5U98J+S+qUkcceVbk5jcwuNM5tV+fWG6AzDr8FQH0KXmDzk7HVpGJ0o0XOw4L+j p540NmZP7k4fbTgANgg9CHjT4N8+Nj6wK3DOyFvkjv3QQ8ci8f6R+s9gG20HLiL8BICTtbilWUFAQ 044rgeM2cAMhgDvvV47Yjl35NdRNeiUdgVhRXEmyxrYEZEJ/+hjlpr0itQRNi3jp25+Uwx1b4SlFx rHiHNBOQ==; Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.97.1) (envelope-from ) id 1wgF1g-000000004tO-3za3; Sun, 05 Jul 2026 01:04:20 -0400 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.97.1) (envelope-from ) id 1wgF1e-000000004tH-3rbl for kernelnewbies@kernelnewbies.org; Sun, 05 Jul 2026 01:04:18 -0400 Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-c96c92c0980so945912a12.3 for ; Sat, 04 Jul 2026 22:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783227855; x=1783832655; darn=kernelnewbies.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=AD61KIiMGldvRFOrBkYBN9Orqqv0DI0rzQzL6EQ0gDg=; b=SrGxfPrUgLy8WnjJaK+vhKtggDyp6zgfa3iMlp9VyGnZvIY4bNY7TnroTUsuz1+tfn bKEDbYZ7W7Tl+4pmGSn1bwLlNgcMwEZzM9SZEzI4GN5Pzlz+hsNkE8Vka/12JdG8RDj3 AfMz+ZVHk3xW3sVFkCMElZ3iMXrjwsrMzC/6kdXr+Wy3Be4p6B+bPDN2G/n/3jKg6UVP mp343PmL8zsy3GwVVLN8j6636DxF9OhmIEycveidY/H5oK9/qiydbhxFRQGT3zTVO/zj oJyzeeX29vM+38E6FTS+Prs7BbRGsg6UNUx0aVoJ1sv7eCNzYE2STKCoBeKNymmxBnHH g0uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783227855; x=1783832655; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=AD61KIiMGldvRFOrBkYBN9Orqqv0DI0rzQzL6EQ0gDg=; b=kVe2xemIj/vPtPBYc5b8ZfYYetWDe/UieP89Zo6uBA9qkpUKTkTHgszECwwI/f5k8G fj4jJkbk1A84JNy5tN/VPdNu9sBZOSFsk5gP4o+8oPr4W8g4pkRySkUfP1kum45zXsQk hnT8Dfu+9tvrulROAyNlax3TZMx5EfGTKBkjJdzuX2J3eAUdVzjb5X8ke1TJrcAollvU o5Kc+Sycf5GvL5KFyS7c6HKOHcnZlQs8HB6o3AnG1UcAK9uxumu2ZaihW+oFS9o8Az+Q zikaJuuZ/yM7H3RTirf8Yoruim4Rk1h+MmsfMo1y7BFi9WT6drseFVG098DwuBasTYI5 O+Fg== X-Forwarded-Encrypted: i=1; AFNElJ80w6smorQoTfmJ9bb113521INbb1EnEzIO6Ytdv62r9xeW7abvBJEDu1tLyuKj6DlY9eC6YtGZfBHQe61j@kernelnewbies.org X-Gm-Message-State: AOJu0YyxDAR1xD7z2ZP2qXAdUuUKlWp5HJORO3res8BYjV7yQX//kMZO dkbajiZMgObglwNztR8ZShFHepZ1i2QjBTfRIy1PfU726n0MshGEf4KqJeMeRoGZgdE= X-Gm-Gg: AfdE7cksX6b1oI3qWtkTGh0dAhy2ulhTsF3ULB8t8WDzuiNT4hz8hc8W1mC/e8iTwbp 5y7REUM/MM68VAxAPNGygHMmHzXUhGkNYZtja8AmKazggnfIYlis8S/XRx1pd40ElVZEGfR/rzj REgxDmJNInMafPuu3fGODdlh81yP3MTM17+VcOINRBEzOP0gOtetbjpmnZ0Wfkd7ExjXoKEBoAA YgTGphdwKcEoT42t5kaTcUH7mkQ6+Hj5sy6XoveJUuKcWYhgiw603p2WvVkQEqV/SPA2NzWCxG6 ofuj/ZN7nZeb+vp8B7W2W7U18+yVhWvPeNjosWxxCv9qrB268qQqSyCCxqQPIMp2rQn7HPDt2UZ lLhaz+yiS8Rir4YsIK19yXHH/Uujg5Nw0mcMb+VP4OVSrTNKVRgObjIl3QcvMwwpHRl6RU7iVJ5 Ee/jyivyGCIAGM0M8= X-Received: by 2002:a05:6a21:3990:b0:3bf:6c08:2b2f with SMTP id adf61e73a8af0-3c03e5f84ebmr5940864637.55.1783227854614; Sat, 04 Jul 2026 22:04:14 -0700 (PDT) Received: from localhost ([77.237.185.175]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-30f0bbd221bsm39267521eec.22.2026.07.04.22.04.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jul 2026 22:04:14 -0700 (PDT) Date: Sun, 5 Jul 2026 08:34:06 +0330 From: Ali Nasrolahi To: Raka Gunarto Subject: Re: Seeking guidance on detecting mount point inactivity Message-ID: References: <2ece89da-c38e-4a4e-bf94-f395286e3117@systemli.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Cc: Richard , kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org Thank you for the suggestions. On 26/07/03 10:54AM, Raka Gunarto wrote: > Is moving the mount to another path or lazy unmount not an option? > > After moving the mount, you can wait until there are no more open > handles (since all subsequent open calls would be blocked). Then you > can do your operations and then restore the mount at the original > location. > > Lazy unmounting would work the same way, wait until it properly > unmounts, and then you remount at your maintenance location. Lazy unmounting, moving the mount to another location, or even techniques such as `chmod 000` (for non-root users) would all eventually drain the mount of references. My concern is slightly different. I don't want to start draining the mount immediately after observing that it has no references at a particular instant, because that alone is not strong evidence that the workload is actually inactive or ,more accurately, likely to be inactive. For example, a workload may repeatedly open a file, perform a small amount of work, close it, sleep for a short time, and then repeat. If I immediately started draining the mount every time the reference count reached zero, the system would constantly interrupt some workload. That is the whole reason behind the grace period. Rather than treating "reference count reached zero" as sufficient, I only consider the mount a possible maintenance candidate if it has remained without active references for some time. The goal is not to prove inactivity, but to make it much more likely that the workload has genuinely gone idle. > If you don't want to disrupt currently running operations, you could > use the fanotify API and keep track of events and determine an > activity threshold to move the mount / lazy unmount. Or perhaps an > eBPF program that hooks into the FS tracepoints? Well, this is actually my direction. I even wrote a small PoC eBPF program that attaches to LSM hooks to account for opens and reject new ones during maintenance. However, it has its own challenges, specifically, some nasty races. For example, if monitoring begins after some file objects are already open, the accounting is immediately off. As a result, the design becomes closer to a best-effort mechanism than one that can guarantee a successful `umount()`. These kind of challenges are exactly the points I hope to discuss. Regards, Ali _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies