On Tue, Apr 20, 2010 at 12:25:39AM -0600, Tim Serong wrote: > On 4/20/2010 at 03:36 PM, luben karavelov <[email protected]> wrote: > > >> My understanding is > > >> that nfsd is a kernel thread. In fact this is the case here: > > >> > > >> r...@lab2:~# ps axu | grep nfs > > >> > > >> root 913 0.0 0.0 356 144 pts/2 R+ 19:01 0:00 grep > > >> nfs > > >> root 25379 0.0 0.0 0 0 ? S< Apr12 0:00 > > >> [nfsd4] > > >> root 25380 0.0 0.0 0 0 ? S Apr12 0:00 [nfsd] > > >> root 25381 0.0 0.0 0 0 ? S Apr12 0:00 [nfsd] > > >> ... > > >> > > > Sure, but they're processes, and they are killable. What happens if you > > > "kill -9 25379"? Does it die immediately and release whatever open files > > > it had? Or does it wedge up somehow (get stuck in D state or whatever)? > > > > > > > It dies, but that's not the point. If I kill all nfsd threads it will > > kill all NFS exports. The idea of exportfs is that you could move > > just one the exported directories to different server. > > Yes, understood. But, assuming it's NFSD that has files open, then the > Filesystem RA should only kill those NFSDs that are using the filesystem > that's being stopped, leaving other NFSDs unaffected.
And how should the Filesystem RA know? reference counts held by nfsd kernel threads usually do not show up in fuser. > It might be interesting to make the exportfs RA a little more verbose. > Where it runs "exportfs -u", maybe add "-v" for more verbosity, then > make it always log the output. Might give you a better idea what's going > on. Won't hurt, but I doubt it would help. > > >> After unexporting a directory there are some time (around 1 minute) > > >> when the kernel still holds open files on the underlying fs. If these references are dropped all by themselves, possibly there is some in-kernel timeout for "something"? (How) does the behaviour change if the nfs client mount this nolock? sync? both? if you export it sync? > > > So if it's the NFSDs that are holding files open, the Filesystem RA > > > should > > > have killed these within about 6 seconds. Unless it cannot see them. Which it typically cannot. > > > In which case, "fuser" should show some other kernel process active on fuser does not show kernel processes. Not on the boxes I have access to. That is becaus kernel threads /proc/$pid/fd/ is empty, usually. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
