From owner-freebsd-net@freebsd.org Thu Jan 12 23:20:27 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47339CAC994 for ; Thu, 12 Jan 2017 23:20:27 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06D961C1D for ; Thu, 12 Jan 2017 23:20:27 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cRofI-000EKH-Ux; Fri, 13 Jan 2017 02:20:16 +0300 Date: Fri, 13 Jan 2017 02:20:16 +0300 From: Slawa Olhovchenkov To: Rick Macklem Cc: Eugene Grosbein , Michael Sinatra , "freebsd-net@freebsd.org" Subject: Re: NFSv4 stuck Message-ID: <20170112232016.GM30374@zxy.spb.ru> References: <20170111220818.GD30374@zxy.spb.ru> <20170111225922.GE30374@zxy.spb.ru> <20170111235020.GF30374@zxy.spb.ru> <58771EA6.1020104@grosbein.net> <20170112131504.GG30374@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 23:20:27 -0000 On Thu, Jan 12, 2017 at 11:08:18PM +0000, Rick Macklem wrote: > Slawa Olhovchenkov wrote: > > >On Thu, Jan 12, 2017 at 01:13:58PM +0700, Eugene Grosbein wrote: > > > >> 12.01.2017 6:50, Slawa Olhovchenkov пишет: > >> > On Wed, Jan 11, 2017 at 03:20:22PM -0800, Michael Sinatra wrote: > >> > > >> >> On 01/11/17 14:59, Slawa Olhovchenkov wrote: > >> >>> On Wed, Jan 11, 2017 at 10:39:42PM +0000, Rick Macklem wrote: > >> >>> > >> >>>> "umount -f" is your only chance. However, if there is already a non-forced > >> >>>> dismount stuck, it won't work because the non-forced dismount will have > >> >>>> the mounted-on vnode locked. > >> >>> > >> >>> I am use 'intr,soft' flags -- why ignored? > >> >> > >> >> intr and soft are considered dangerous with nfsv4. See the "BUGS" > >> >> section of the mount_nfs(8) man page. > >> > > >> > Currently I am see dangerous w/o intr: system need reboot, application > >> > don't killable. > >> > >> NFSv4 confiders "intr,soft" dangerous for data generated by poorly written applications, not for a OS. > > > >What data? In may case no data. > Certain NFSv4 operations (such as open and byte range locking) are strictly ordered using a > seqid#. If you fail an RPC in progress (via a soft timeout or intr via a signal) then this seqid gets > out of sync between client and server and your mount is badly broken. Mount can be droped? Automatic forced unmount? Or application can be manual killed for manual unmount? This is will be perfect for me. This is will be best that current behavior. > I do not believe this caused your hang though, since processes were sleeping on rpccon, which > means they were trying to do a new TCP connection to the server unsuccessfully. > - Which normally indicates a problem with your underlying network fabric. Network can fail always, at any time. This should not cause a blockage of the system. > stuff snipped... > > rick >