From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from minas.ics.muni.cz ([147.251.4.40]:51411 "EHLO minas.ics.muni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758522Ab0EYOCh (ORCPT ); Tue, 25 May 2010 10:02:37 -0400 Date: Tue, 25 May 2010 16:02:40 +0200 From: Lukas Hejtmanek To: "William A. (Andy) Adamson" Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, salvet@ics.muni.cz Subject: Re: Deadlock in NFSv4 in all kernels Message-ID: <20100525140240.GG9731@ics.muni.cz> References: <20100507153920.GP28167@ics.muni.cz> Content-Type: text/plain; charset=iso-8859-2 In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: MIME-Version: 1.0 On Tue, May 25, 2010 at 09:45:32AM -0400, William A. (Andy) Adamson wrote: > Not get into the problem in the first place: this means > > 1) determine a 'lead time' where the NFS client declares a context > expired even though it really as 'lead time' until it actually > expires. > > 2) flush all writes on any contex that will expire within the lead > time which needs to be long enough for flushes to take place. I think you cannot give any guarantees that the flush happens on time. There can be server overload, network overload, anything and you are out of luck. -- Lukáš Hejtmánek From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukas Hejtmanek Subject: Re: Deadlock in NFSv4 in all kernels Date: Tue, 25 May 2010 16:02:40 +0200 Message-ID: <20100525140240.GG9731@ics.muni.cz> References: <20100507153920.GP28167@ics.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, salvet-8qz54MUs51PtwjQa/ONI9g@public.gmane.org To: "William A. (Andy) Adamson" Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On Tue, May 25, 2010 at 09:45:32AM -0400, William A. (Andy) Adamson wro= te: > Not get into the problem in the first place: this means >=20 > 1) determine a 'lead time' where the NFS client declares a context > expired even though it really as 'lead time' until it actually > expires. >=20 > 2) flush all writes on any contex that will expire within the lead > time which needs to be long enough for flushes to take place. I think you cannot give any guarantees that the flush happens on time. = There can be server overload, network overload, anything and you are out of l= uck.=20 --=20 Luk=E1=B9 Hejtm=E1nek -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html