In CIFS, which of this causes a new instance of the data/blocks?

[mdvillanueva]

Hi Expert,

Recently, we had this incident where:

A) a user accidentally moved a large folder inside another folder (example sharefolder\Folder1 is moved to sharefolder\Folder2). User says it was instantaneous.

B.) Now I am trying to move it back to sharefolder level but it was not instantaneous. It takes a long time. The folder is 600GB.

C.) Just to be safe, I just decided to copy sharefolder\folder2\folder1 as sharefolder\newfolder1

Which of A, B, C creates new instance of the data/blocks. Is it possible what the user was saying that it got moved instantaneously?

Also, does renaming the folder creates new instance of the blocks? I think not, but just want to confirm.

Thanks,

Maico

[billshaffer]

A) should result in no new blocks, as it is a move within the same filesystem - only inode info is changing, and should be instantaneous (nearly).  Caveat - if data in Folder2 is changed, it will consume snapshot space in the volume.

B) should result in no new blocks, as above - it is a move within the same fileystem and should be quick.  Same caveat, if snapshots were taken while it was in the "new" location.

C) WILL consume new blocks, as you are duplicating the data.

Are you saying you first tried to move it, then decided to copy it?

Bill

[mdvillanueva]

Hi Bill,

Thanks. Yes, I first tried to move but it takes forever, I guess it is because a scheduled snapshot already occured and the blocks were locked? Is that right?

[billshaffer]

My understanding is that a move within the same filesystem does not incur a true delete/write sequence, as only inodes are being changed, and thus will happen very quickly.  This in true in the unix world - I'm pretty sure it is true in the windows world, but I'd have to check.  The user saying the initial move would seem to validate this, though your experience seems to invalidate it....  Are these different qtrees?  That would count as different filesystems, and would explain the time it is taking (as for the user saying it was instantaneous - well, we know how unreliable users are....)

Any existing snapshots shouldn't affect the move/copy itself - NetApp does what it needs to do in the background.  There ARE chances of mass block reclamation impacting performance, though.

I'm rethinking an earlier comment.  If you move a file, technically it IS getting deleted from the source location, and thus will show in a snapshot.  The question is whether NetApp sees that it was a move, and points those snapshot blocks to the new location, or keeps the blocks in the snapshot and provides new blocks for the destination copy, in which case A) would take new blocks.

I would have to run some tests to be sure.  Either way, the status of the snapshots shouldn't affect the user experience in moving data around.  Let me know if the source and destination are different qtrees.

Bill

[mdvillanueva]

so base in what you said about the snapshot, if I delete the snapshot that was taken after the move, would that mean that it is possible that it will move fast?