Simple NFS client/server copy question

[MPERIYAK]

Simple NFS question.

3 scenarios

===============================

Scenario 1

netapp has 2 nfs shares
/a
/b

Linux client has 2 mount points
Mounta points to /a
mountb points to /b

when data copy initiates on the linux client from mounta to mountb..does it all happens on the storage side or client side. I am 100% positive this happens on the client side.

===============================

Scenario 2

netapp has 1 nfs share
/a

Linux client has 1 mount point
mounta points to /a

when data copy initiates on the linux client from a folder within mounta directory structure..

example cp files /mounta/dir1 to /mounta/dir2

does it all happens on the storage side or client side ?
===================

Scenario 3

Also what will be the case if it the above situation is a  CIFS share and a windows client

[ShivaBhat]

In all the cases, the copy happens over the network over CIFS or NFS protocol. The copy does not happen on the storage side but the client.

Do note however, that Storage Vmotion is a feature with VMware, that enables offload of copy process on to the storage. ie, the copy happens within the storage and not over the network

[MPERIYAK]

In scenario 2 being a single NFS file system why the copy happens on the client side.

The client will send a command “move this from here to here” via NFS and when WAFL gets it, it will update the metadata file pointer rather than physically move the data

[aborzenkov]

---

In all the cases, the copy happens over the network over CIFS or NFS protocol. The copy does not happen on the storage side but the client.

---

What about SMB3 copy offload? I think NetApp supports it?

[aborzenkov]

---

The client will send a command “move this from here to here”

---

Example used "cp" and "cp" does read/write, at least in this example. "mv" would probably use NFS RENAME indeed.

[ShivaBhat]

There is a difference in behaviour for move commandn and copy command. A mv /mounta/dir1 /mounta/dir2 will cause a RENAME as long as the file is not open for read.