On Tue, 16 Oct 2012 19:44:38 +0800 Chen Gang <gang.c...@asianux.com> wrote:
> > 于 2012年10月16日 18:33, Jeff Layton 写道: > > In any situation where we get back attributes, we have to decide > > whether they are valid or stale. It's always possible for replies or > > their handling to be reordered such that an older set of attributes > > is processed after a newer set. > > > > Unfortunately, the v2/v3 protocols do not have great support for > > helping the client detect this situation, so we do the best we can with > > what we do have. Unfortunately when things are changing very quickly we > > can still get it wrong, especially with v2/3. [1] > > > > In any case, the logic to determine this is in > > nfs_inode_attrs_need_update(). Looking at the size is sort of the "last > > resort" after we look at the timestamps and gencount. > > > > I agree with you (what I understood originally is just like what you > said above). > > thank for your confirmation. > > > The problem with doing what you suggest is that if we get it wrong, the > > consequences are worse than the file appearing to be bigger than it is. > > It means that written data may be silently lost. > > > > 1) I understand why my suggestion is not quite suitable. I agree you. > > 2) but, are we truly no ways to solve this issue ? (I do not think so). > Not that I see, but don't let me stop you from trying to find one. ;) > 3) I think an executable way (but maybe not a good way) is : > > A) for each client, check each task id of the client its own (such as > rpc task xid), so can know the order of tasks of the client its own. > We do something like this already. That's what the gencount thing is all about. It's still possible though to fool that check if two calls are scheduled closely enough. Also note that it's not just the reordering of replies that you have to concern yourself with. The requests themselves can be reordered on the network. The server is also under no obligation to execute calls in the order received. > B) maybe also need another some synchronization code, but I think it > does not have much negative effect with performance. > Yeah, serializing things to fix this is probably a non-starter. NFSv2 and UDP transports are basically legacy code at this point, so there's not a lot of incentive to do anything drastic here. > > > ====== > > > > [1]: v4 has a change attribute so it's slightly simpler there when the > > server supports it. Unrelated Q for Trond: should we be checking the v4 > > change_attr in nfs_inode_attrs_need_update too? > > sorry for I am truly not quite familiar with nfs, I also think it is not > quite relative with current issue, so I have to skip it (although I > think these contents are valulable for Trond) > Correct. That was just an aside question for Trond or someone else who understands the attribute revalidation code better than I do. -- Jeff Layton <jlay...@redhat.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
