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. 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. > >> After unexporting a directory there are some time (around 1 minute) > >> when the kernel still holds open files on the underlying fs. > >> > > So if it's the NFSDs that are holding files open, the Filesystem RA should > > have killed these within about 6 seconds. If they have all been killed, > > it's not NFSD keeping the filesystem busy, it's something else. Mabye > > there's a whole lot of dirty pages that need to be flushed to the disk? > > In which case, "fuser" should show some other kernel process active on > > the filesystem... > > If there are dirty pages to be flushed, this will be done in > "umount" command, so it will take some time. I am prety sure > thet it is the nfsd that keeps open files on the FS. It happens > only if there is nfs client that hold open files. I think you really need to determine with certainty exactly what it is that's holding what file(s) open. Unfortunately, aside from the "fuser" command to see what processes are accessing a given filesystem, I'm not sure what else to suggest at this point (especially as you ran "fuser -vm /mountpoint" and got no output at all - this says to me that there are no files being held open, but of course I could be missing something). Regards, Tim -- Tim Serong <[email protected]> Senior Clustering Engineer, OPS Engineering, Novell Inc. _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
