It's not configurable, it's not even a filer-specific thing. Those .nfs files are being created because some other process out there is currently accessing the file that you asked to be deleted. That's what causes .nfs files. It's part of the NFS spec to do so. If they are still around after the client is no longer accessing the file, then the client did not delete them which again, according to the spec, it the client's responsibility. At that point, you can delete them manually.
Check out the following NTAP Knowledge Base article for more details:
http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs1105&resou...
Hope this helps.
-- Adam Fox NetApp Professional Services, NC adamfox@netapp.com
-----Original Message----- From: John Sambrook [mailto:john_sambrook@yahoo.com] Sent: Tuesday, July 24, 2001 3:57 PM To: toasters@mathworks.com Subject: .nfsXXXX files cause ClearCase remove commands to fail ...
We have a couple of Sun servers running ClearCase version 4.2, patch level 3, with a NetApp F740 filer providing VOB and view storage. We host VOB databases on the filer as well, not just pools.
When we attempt to delete a VOB, using the ClearCase "rmvob" command, the command fails. Upon investigation, it appears that the filer is creating .nfsXXXX files, corresponding to files that were open at the time they were deleted.
I'd like to know if others have encountered this problem, and if so what they did to resolve it. Perhaps the creation of these files is configurable?
Thanks for any advice.
John Sambrook
Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
Yep. This is consistent with what I observe.
What I have also found is that if I kill ClearCase's vob server process by hand ('ps -elf | grep vob' then kill -15 <pid>') then there are no open files in the vob (storage dir) to be deleted, and the ClearCase "rmvob" command works fine.
Note that I am unmounting the VOB before rmvob'ing it, but not manually finding and kill the vob server process. The ClearCase 'rmview' command doesn't seem to suffer from this problem, so perhaps it does an "endview" command internally as part of deleting a view.
At any rate, the problem is clearly a ClearCase issue, and not a problem with the filer. We are really happy with the filer and the support from NetApp, BTW.
Thanks for the help.
John Sambrook --- "Fox, Adam" Adam.Fox@netapp.com wrote:
It's not configurable, it's not even a filer-specific thing. Those .nfs files are being created because some other process out there is currently accessing the file that you asked to be deleted. That's what causes .nfs files. It's part of the NFS spec to do so. If they are still around after the client is no longer accessing the file, then the client did not delete them which again, according to the spec, it the client's responsibility. At that point, you can delete them manually.
Check out the following NTAP Knowledge Base article for more details:
http://now.netapp.com/Knowledgebase/solutionarea.asp?id=ntapcs1105&resou...
Hope this helps.
-- Adam Fox NetApp Professional Services, NC adamfox@netapp.com
-----Original Message----- From: John Sambrook [mailto:john_sambrook@yahoo.com] Sent: Tuesday, July 24, 2001 3:57 PM To: toasters@mathworks.com Subject: .nfsXXXX files cause ClearCase remove commands to fail ...
We have a couple of Sun servers running ClearCase version 4.2, patch level 3, with a NetApp F740 filer providing VOB and view storage. We host VOB databases on the filer as well, not just pools.
When we attempt to delete a VOB, using the ClearCase "rmvob" command, the command fails. Upon investigation, it appears that the filer is creating .nfsXXXX files, corresponding to files that were open at the time they were deleted.
I'd like to know if others have encountered this problem, and if so what they did to resolve it. Perhaps the creation of these files is configurable?
Thanks for any advice.
John Sambrook
Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
__________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
John> Note that I am unmounting the VOB before rmvob'ing it, but not John> manually finding and kill the vob server process. The ClearCase John> 'rmview' command doesn't seem to suffer from this problem, so John> perhaps it does an "endview" command internally as part of John> deleting a view.
Why are you doing this? You should do the 'rmvob' first, then unmount the filesystem which held the Vob. This is probably why you're having problems here. You need to let ClearCase shutdown the various VOB processes before you actually unmount the filesystem holding the vob(s).
John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel@lucent.com - http://www.lucent.com - 978-952-7548
After jumping through the various web browser hoops to get Secureadmin 1.0 installed on a 740 running 6.1.1, I tried to run
secureadmin setup ssh
on the console, as the install.htm (and release.htm) file said. But that simply returns
secureadmin not found. Type '?' for a list of commands
What am I missing? The filer did log
Tue Jul 24 14:53:26 MST [luiza: Java Thread:info]: netapp.servlets.admin.Api: SecureAdmin 1.0 has been successfully installed.
Adam.Fox@netapp.com gives a good description of what causes these files, in particular that it's all a matter for NFS clients, but I don't think it is really correct to say
[...] That's what causes .nfs files. It's part of the NFS spec to do so.
Not the "NFS spec" in the sense of RFCs 1094, 1813, or 3010, it isn't! (Unless I've overlooked something in them, which is certainly possible.)
It is rather a long-established "trick" (it goes right back to the original Sun implementations) used by NFS client implementations to simulate the behaviour of local Unix filing systems when an open file is unlinked.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.