Steve Losen scl@sasha.acc.virginia.edu writes:
We have a F630 running 4.2a and are having trouble accessing snapshots with CIFS.
This may be unrelated, but some NFS clients have problems using the .snapshot way of accessing snapshots. Apparently, Netapp returns the same NFS filehandle or at least the same inode number for snapshots as for the current version of the file, and this can confuse NFS clients.
sodium:~ $ ls -i .profile 602274 .profile sodium:~ $ ls -i .snapshot/hourly.0/.profile 602274 .snapshot/hourly.0/.profile
To work around this problem, we set up a separate NFS export of filer:/.snapshot that we mount under /snapshot/filer. That way, you can use a completely different mount point to recover a file and the inode problem is a non-issue.
Since we've had people experience file corruption when using the .snapshot in their working directory, and no problems when using the separate mount point, I asked NetApp several times for an option to disable all .snapshots except for the root one.
- Dan
This may be unrelated, but some NFS clients have problems using the .snapshot way of accessing snapshots. Apparently, Netapp returns the same NFS filehandle or at least the same inode number for snapshots as for the current version of the file, and this can confuse NFS clients.
Can you say more about the clients that are getting confused? (What vendor, what OS, etc.)
We do *NOT* return the same file handle for snapshotted files, and the clients we've tested with have worked just fine. (We do return the same inode number, since we didn't want to reduce the number of available inodes by 5 bits that would be required to uniquify accross all snapshots.)
If some clients are having trouble handling the snapshots, then we need to have a talk with some implementors...
Dave
-
Daniel Quinlan -
hitz＠netapp.com