"J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: > On Thu, Feb 24, 2011 at 05:48:58PM +0100, Ferenc Wagner wrote: > >> "J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: >> One client removed the file, and another could still access it by name >> (although not present in the directory listing). So it could have been >> a client-client conflict, even though we couldn't prove that the removed >> file was actually in use on the client. Is there a way to list the >> delegations being hold by a client? > > Not really. They'll show up as LEASE entries in /proc/locks, with the > pid of an nfsd process, but no way to associate them with a client. Well, thanks, this is something. I'll check when it happens again. There are lots of such lines, so chances are that will be it. > Some way to dump lock (and other state) information might be a nice > thing to have some day for debugging and tuning. Yes, very much! I guess the info is more or less readily available in the kernel, just isn't exported to userspace. Looks like a job for debugfs. >>> You can turn off delegations completely with >>> echo 0 >/proc/sys/fs/leases-enable >>> before starting the nfs server. >> >> Wouldn't I lose most of the efficiency advantages of NFSv4 with that >> move? > > Probably so. It would at least be a way to verify whether delegations > are the source of your problem, if you have a reproduceable test case. Not yet, unfortunately. But we're trying to work one out. It's pretty rare, so only mildly disturbing, but when it hits, it hits hard... -- Thanks, Feri. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
