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 X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9550C433FE for ; Thu, 3 Dec 2020 22:46:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7C00B222F9 for ; Thu, 3 Dec 2020 22:46:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727927AbgLCWqC (ORCPT ); Thu, 3 Dec 2020 17:46:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727664AbgLCWqB (ORCPT ); Thu, 3 Dec 2020 17:46:01 -0500 Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90BD3C061A51 for ; Thu, 3 Dec 2020 14:45:21 -0800 (PST) Received: by fieldses.org (Postfix, from userid 2815) id EFBFC6F4C; Thu, 3 Dec 2020 17:45:20 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org EFBFC6F4C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1607035520; bh=Wgp5iLi7J60c/nEBHuQcrbKwvhRwc9Cl/uyZlZdjNHY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=asSzefJdpgM0fovV+xt3OYtnZ9Is1TPetqAcbKWmkpzbvSCmop1uWqgyxI3P0NYda lTDOTh/JSmQBaMcng4Pf4FBzpmZKen4ZB7Md6XbBc8+4BXkKl1RIzH7LeRtR7nesp6 m4Y4EpJ8groDrP2lPIVi6D5AguJW7foHMm1TAkH4= Date: Thu, 3 Dec 2020 17:45:20 -0500 From: "bfields@fieldses.org" To: Trond Myklebust Cc: "linux-cachefs@redhat.com" , "linux-nfs@vger.kernel.org" , "daire@dneg.com" Subject: Re: Adventures in NFS re-exporting Message-ID: <20201203224520.GG27931@fieldses.org> References: <20201109160256.GB11144@fieldses.org> <1744768451.86186596.1605186084252.JavaMail.zimbra@dneg.com> <1055884313.92996091.1606250106656.JavaMail.zimbra@dneg.com> <20201124211522.GC7173@fieldses.org> <932244432.93596532.1606324491501.JavaMail.zimbra@dneg.com> <1403656117.98163597.1606998035261.JavaMail.zimbra@dneg.com> <20201203185109.GB27931@fieldses.org> <4903965f2beb742e0eca089b5db8aa3a4cabb7f0.camel@hammerspace.com> <20201203211328.GC27931@fieldses.org> <9df8556bf825bd0d565f057b115e35c1b507cf46.camel@hammerspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9df8556bf825bd0d565f057b115e35c1b507cf46.camel@hammerspace.com> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, Dec 03, 2020 at 09:34:26PM +0000, Trond Myklebust wrote: > I've been wanting such a function for quite a while anyway in order to > allow the client to detect state leaks (either due to soft timeouts, or > due to reordered close/open operations). One sure way to fix any state leaks is to reboot the server. The server throws everything away, the clients reclaim, all that's left is stuff they still actually care about. It's very disruptive. But you could do a limited version of that: the server throws away the state from one client (keeping the underlying locks on the exported filesystem), lets the client go through its normal reclaim process, at the end of that throws away anything that wasn't reclaimed. The only delay is to anyone trying to acquire new locks that conflict with that set of locks, and only for as long as it takes for the one client to reclaim. ? --b.