Questions[netapp](server)

I've got a process that:

• writes a new '.tmp' file.
• uses a rename() syscall to replace an existing file.
• This file is being accessed from a remote NFS client.

We do this, because we want atomic file updates, and the rename() spec says:

If newpath already exists, it will be atomically replaced, so that there is no point at which another process attempting to access newpath will find it missing. However, there will probably be a window in which both oldpath and newpath refer to the file being renamed.

We rely on this behaviour.

But here's the gotcha - just recently, since migrating to a new NetApp (Cluster mode, from 7 mode) - we've had a process that very occasionally falls over with ENOENT - no such file or directory.

By 'very occasionally' I mean - 4 or 5 times in the last few weeks, on a process that happens every 5 minutes or so.

I'm investigating with the vendor as to whether this might be a bug or not with their NFS server.

But what I'm actually trying to figure out is whether that atomicity guarantee is actually applicable to NFS. Is anyone able to clarify for me if rename()'s atomicty guarantee applies to multi-client NFS scenarios? I'm not actually sure that this feature is one that has been working, but was never guaranteed to in the first place.

From: RFC1813

Procedure RENAME renames the file identified by from.name in the directory, from.dir, to to.name in the directory, to.dir. The operation is required to be atomic to the client.

In case it's relevant, we've got SL 6.5 clients hitting NFS datastores on ONTAP-CDOT 8.3.

What are the commands to enable disk encryption on a NetApp NAS, can this be done per disk/array?

I have a problem with a NetApp file server with Windows XP clients.

The files are on a single SAN drive. The users regularly move files from \\storage\share to their personal folder at e.g. \\storage\myfolder. This is fine so far, but it becomes a problem when they move files from \\storage\share to \\storage\secretCompany and add some secret information to the file. The permissions for the file are still the same as they were in share, hence everyone with the permissions to share can now see this file in secretCompany.

Is there any way to prevent Windows from copying permissions and just always use the target permissions?

A vendor is attempting to map and preserve a network drive using nt authority/system; so it stays persistent when the interactive session of the server is lost. They were able to do this on one server (Windows 2008 R2) but not a second computer (also Windows 2008 R2).

D:\PsExec.exe -s cmd.exe

PsExec v1.98 - Execute processes remotely
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. all rights reserved.

C:\Windows\system32>whoami
nt authority\system

C:\Windows\system32>net use
New connections will be remembered.

Status        Local   Remote               Network
--------------------------------------------------------------------
OK            X:      \\netapp1\share1     Microsoft Windows Network
The command completed successfully.

C:\Windows\system32>net use q: \\netapp1\share1
System error 1808 has occurred.

The account used is a computer account. Use your global user account
or local user account to access this server.

C:\Windows\system32>

I am unsure on how to set up a "machine account mapping" which will preserve the drive letter of the Netapp path being mapped, so that the service account running a Windows service can continue to access the share after interactive logon has expired on the server. Since they were able to do this on one server but not another, I'm not sure how to troubleshoot the problem? Any suggestions?

NetApp provides block-level deduplication (ASIS). Do you know any filesystem (even FUSE-based) on Linux (or OpenSolaris, *BSD) that provides the same functionnality ?

(I'm not interested in false deduplication like hardlinks).