Re: [RFC] server's statd and lockd will not sync after its nfslock restart

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Dec 17, 2009, at 3:14 PM, J. Bruce Fields wrote:
On Thu, Dec 17, 2009 at 11:18:53AM -0500, Chuck Lever wrote:
run_sm_notify() simply forks and execs the sm-notify program.  This
program checks for the existence of a pid file. If the pid file exists, then sm-notify exits. If it does not, then sm-notify retires the records
in /var/lib/nfs/statd/sm and posts reboot notifications.

Jeff Layton pointed out to me yesterday that Red Hat's nfslock script
unconditionally deletes sm-notify's pid file every time "service nfslock start" is done, which effectively defeats sm-notify's reboot detection.

sm-notify was written by a developer at SuSE. SuSE Linux uses a tmpfs
for /var/run, but Red Hat uses permanent storage for this directory.
Thus on SuSE, the pid file gets deleted automatically by a reboot, but
on Red Hat, the pid file must be deleted "by hand" or reboot
notification never occurs.

So the root cause of this problem is that the current mechanism sm-
notify uses to detect a reboot is not portable across distributions.

My new-statd prototype used a semaphor instead of a pid file to detect
reboots.  A semaphor is shared (visible to other processes) and will
continue to exist until it is deleted or the system reboots.  It is a
resource that is not destroyed automatically when the sm-notify process exits. If creating the semaphor fails, sm-notify exits. If creating it
succeeds, it runs.

Would anyone strongly object to using a semaphor instead of a pid file here? Is support for semaphors always built into kernels? Would there be any problems with the small size of the semaphor name space? Is there
another similar facility that might be better?

I don't know much about those (except that I think there's an e at the
end); looks like sem_overview(7) is the place to start?

It says:

	" Prior to kernel 2.6, Linux only supported unnamed,
	thread-shared  sema‐ phores.   On a system with Linux 2.6 and a
	glibc that provides the NPTL threading implementation, a
	complete implementation of POSIX semaphores is provided."

So would it mean dropping support for 2.4?

No, it would mean using them only on systems that supported shared semaphores.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com




--
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

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux