On Sat, Jun 21, 2008 at 11:15:00AM -0500, Steve French (smfrench@xxxxxxxxx) wrote: > 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 switch to blocking with 30 seconds timeout of course. > 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) Depending on how deep you want to dig into socket code :) The simplest way is just to provide MSG_DONTWAIT flag and set socket buffer small enough (either via sysctl or socket option). Trick with small socket buffer will help to get egain (note that it is only returned for nonblocking socket, otherwise it will sleep upto sock->sk_sndtimeo/sk_rcvtimeo jiffies and then return number of bytes transferred) quite soon (well, you can set it to really miserable value, but that rule will not be followed strickly :) under ay kind of load. You can also hack into socket code like tcp_sendmsg()/tcp_sendpage() (the latter is not used in CIFS though) and unconditionally return errors like ENOMEM and EAGAIN there (or bind it to some socket option, time of the day or random value). Those were the simplest imho, but you can also setup network scheduler (netem is the best for this kind of tests) to drop/reorder/corrupt dataflow, which will also result in protocol troubles, which will lead to delays in sending and possibility to delay writing. In POHMELFS I emulated similar behaviour simply by injecting error into sending socket codepath and setting non-blocking socket and killed server. -- Evgeniy Polyakov -- 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
