On Sat, Jun 21, 2008 at 9:42 AM, Evgeniy Polyakov <johnpol@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
