From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Steve French" Subject: Re: flush and EIO errors when writepages fails Date: Sat, 21 Jun 2008 11:15:00 -0500 Message-ID: <524f69650806210915j2f62a2e9o3a03c381970a5bce@mail.gmail.com> References: <524f69650806201534g67704841u9f942a71b6d9caa3@mail.gmail.com> <20080621070556.GA1155@2ka.mipt.ru> <20080621082742.4b311132@tleilax.poochiereds.net> <20080621131919.GA22509@2ka.mipt.ru> <485D0E76.3020205@austin.rr.com> <20080621144213.GA7971@2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Jeff Layton" , linux-fsdevel , "Shirish Pargaonkar" , "Dave Kleikamp" To: "Evgeniy Polyakov" Return-path: Received: from fk-out-0910.google.com ([209.85.128.184]:51455 "EHLO fk-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753201AbYFUQPF (ORCPT ); Sat, 21 Jun 2008 12:15:05 -0400 Received: by fk-out-0910.google.com with SMTP id 18so1675920fkq.5 for ; Sat, 21 Jun 2008 09:15:01 -0700 (PDT) In-Reply-To: <20080621144213.GA7971@2ka.mipt.ru> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sat, Jun 21, 2008 at 9:42 AM, Evgeniy Polyakov wrote: > If you do not unlock and release the page, nothing can currupt it, but > I'm not sure that if you had 15 seconds timeout writepage+flush will > have enough time interval to exceed it. In the flush you can switch to > nonblocking mode and set socket timeout to 30 seconds for example and if > even that failed, then discard data. EGAIN likely means problem on > server, which I referred as non serious, and likely it will resume in a > few moments, so your trick with write+flush can work, but only with long > enouf timeout. > > Actually you can always perform similar trick with socket timeout, but > bevare of problems with umount or sync, when they can take toooo long to > complete, so there should be some flag to show when you want and do not > want it. Similar scheme was implemented in POHMELFS. > > Returning error I think is the last thing to do and whatever retry > mechanism you will decide to implement it worth the efforts. Any thoughts on how to simulate this (ie repeated EAGAINs on the socket) so we can reproduce this kind of scenario without lots of stress (including a large local file copy to increase memory pressure, while the remote file is being written out) -- Thanks, Steve