On Tue, 2010-05-25 at 10:10 -0400, William A. (Andy) Adamson wrote: > 2010/5/25 Lukas Hejtmanek <xhejtman@xxxxxxxxxxx>: > > 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. > > True - but this will be the case no matter what scheme is in place. > The above is to handle the normal working situation. When this fails > due to network, server overload, server reboot, i.e. not-normal > situation, then use the machine credential. Use of the machine credential also requires help from the rpc.gssd daemon. It's not a solution to the deadlock Lukas is describing. Trond -- 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
