Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1501188ybn; Wed, 2 Oct 2019 17:35:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqxwS3wA/V7FV1G4tw0n8UtDS69aRgOyw+Ty/Xbw46hPZRUyIyqBQJ2VKoDajZTNxq+OM6O0 X-Received: by 2002:a05:6402:1212:: with SMTP id c18mr6806122edw.259.1570062949919; Wed, 02 Oct 2019 17:35:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570062949; cv=none; d=google.com; s=arc-20160816; b=YK8ylsvkeByGnbRwqrNyrDezc9XnGJnZVzMlWf0ha6X8P8Qu0Wi6wiHsQwBvZxwikP GdknGPvGj+fihRm+RaoltQbHf37EnV5S0Ij7Wk+KrnJ1RLGRe5CtfVB+06o+GRi7Azm4 gmnza+5ClGZz+4we7eEuo/sakuMI8JNTHlG3M+h/o4BTRMTrI4arcs9aGLZlHPTDebJb aKBS8UgzRF1mT4O9dFac1XkFP4ytJzXKewxf1+5hARelzrPWJX4QnvdE6nr02FdZiPDI jsFHhMsyDTgLT2CUfWJeA5hoUW2EPYat/46folpyHOFVKRinAI0FkirCTr1hRc/5F2ei gw1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:references :in-reply-to:subject:cc:date:to:from; bh=OudZmo2CVVpPMdaJf4csA8aWri7mLkkilBY2ULj9MOE=; b=kHt2AkoOTK5CLUMqqyWNQr+EMlbu1YHfXFdoVnwNEfWctiBLxSsqcBBJXCj45k7Yw9 q3XYsk83YrKEJvbRs5DpWLbpWMuzWpKQUGMscQ/mZQrjCIirqi/OiUI2UAAamoiypKrX Plx4YPGt/cNKzTWcvp3wz5++TqryFgrnpPR9+PAsPnJEvuhkJBytktsVfGMuTqUIReYx rkiqYujU6TpTjZ1o9U1+ZfE/6FHs5HOPoUkeoU0O69WSpuIppOaSFlA+9Ad+9qfL6g/A Fq5tz23Cb0S1f2Wk9wD02avXQ8d4MRlypoem4Y4fPYp0BASk5dUIG4n7DUYIJHzfSgJ9 s9kA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v26si394161ejw.276.2019.10.02.17.35.25; Wed, 02 Oct 2019 17:35:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729880AbfJCA1a (ORCPT + 99 others); Wed, 2 Oct 2019 20:27:30 -0400 Received: from mx2.suse.de ([195.135.220.15]:50150 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1729866AbfJCA1a (ORCPT ); Wed, 2 Oct 2019 20:27:30 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 1046CAF22; Thu, 3 Oct 2019 00:27:28 +0000 (UTC) From: NeilBrown To: Chuck Lever , Trond Myklebust Date: Thu, 03 Oct 2019 10:27:21 +1000 Cc: Neil F Brown , Linux NFS Mailing List Subject: Re: remounting hard -> soft In-Reply-To: <489FAE7A-F9CC-46A9-84FC-127487ADC0B3@oracle.com> References: <489FAE7A-F9CC-46A9-84FC-127487ADC0B3@oracle.com> Message-ID: <87y2y265cm.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, Oct 02 2019, Chuck Lever wrote: > Hi Trond- > > We (Oracle) had another (fairly rare) instance of a weekend maintenance > window where an NFS server's IP address changed while there were mounted > clients. It brought up the issue again of how we (the Linux NFS community) > would like to deal with cases where a client administrator has to deal > with a moribund mount (like that alliteration :-). What exactly is the problem that this caused? As I understand it, a moribund mount can still be unmounted with "-l" and processes accessing it can still be killed ... except.... There are some waits the VFS/MM which are not TASK_KILLABLE and probably should be. I think that "we" definitely want "someone" to track them down and fix them. > > Does remounting with "soft" work today? That seems like the most direct > way to deal with this particular situation. I don't think this does work, and it would be non-trivial (but maybe not impossible) to mark all the outstanding RPCs as also "soft". If we wanted to follow a path like this (and I suspect we don't), I would hope that we could expose the server connection (shared among multiple mounts) in sysfs somewhere, and could then set "soft" (or "dead") on that connection, rather than having to do it on every mount from the particular server. NeilBrown > > > -- > Chuck Lever --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAl2VQGkACgkQOeye3VZi gbmTBhAAo+iXH6JqhgxPY5kpn+3XfeSy3pYC47KNU9EW27UZt6iNFrxrDNSTdzms ZuA2xpo5RuTwa/HyVgjYcOTv4qOd6NC/xCuByfQenD/Sw6gakU19+fElwmGf8oVA Zpd4h1EUAmrxXIYPrjd4LNrHTcIDaFghm3CklESS72S90E29uh1VrK3HA1haA7Yp re3LHLTWzhcbwbToHG2bEk679DaET26LNwolCh2FM8wGaVXdqDj4UECUEkdfAnV6 42TeVifI7D/VQ+YmAk5eTSuK96sf+Ps5mztlxtKvMHYJl2d9Q24UNoN/TmDStAHZ yqdl/ogRVS0ihkWIb7lJ2ZJwE9vmCegLdD2Fi8ieqQGCf/T66ns255mTNpSNIWk5 O59cDMsPtBs7KRDpxzE46XiEAIu8qfkucurJxsLuD0PV4Ics+gjsmvFlPMNe08SU hDfYYumJVIBYI/BwL4lMmvjCSfX6/6NWq71qZQgT+oLW2JULE3sTeAY0J7origB3 63bofO5wJcqqa71tzavuEunuIwYh7yLr0Brii6gQ5biq3BzG+GSzskHNTZDO1GK/ 8FCMMC09BksPm7A0KGJCNo31bQ3KumzLEATxKxTNeqfjeiaBoazwv6CpbQydQ7qO M2HwQamfyiDfssD1PwKrGO6vz0t/Lrbc74U8jvcYDj2W6A+FGZU= =w+um -----END PGP SIGNATURE----- --=-=-=--