Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Using FreeBSD and a mounted NetApp NFS Share.

I'm trying to copy a file

FROM: localdisk/something.vmdk (size 527776 kilobytes)
TO: nfsmount/copy-something.vmdk (size 533168 kilobytes)

But it seems like from the above size I've demonstrated that the file somehow grew after the action of copying. Even though I'm just trying to duplicate the file.

Any idea's how this could happen? I'm simply running

cp localdisk/something.vmdk nfsmount/copy-something.vmdk

Then running a du on each to check file size and they're mysteriously growing in size.

uname -rs
FreeBSD 8.1-RELEASE-p2
share|improve this question
This can happen if the block sizes of the filesystems are different. Are the source and destinationss formatted differently? – Nathan C May 9 '14 at 14:30
If you want to confirm that you have an exact copy of the file, it's usually better to run md5sum on both and compare the hash. If it's the same you can be sure the file is exactly the same. – faker May 9 '14 at 14:34
du reports disk space used not file size. For sparse files these are not the same. Does ls -ls show them the same size? (first column will be blocks used - may differ, latter size should be the same). – Brian May 9 '14 at 14:46
@Brian ls -ls still shows a difference. Source: 527776 Dst: 533168 – rainereality May 9 '14 at 14:58
@faker md5 reports a match: src: 224067840895a0499f2a0d8d33ecd185 dst: 224067840895a0499f2a0d8d33ecd185 – rainereality May 9 '14 at 14:59

Based on your comments, here's what I understand:

  • You have a VM saved on a local disk
  • You are trying to copy it to a Netapp NFS share with dedupe enabled to test dedupe

If this is true, the reason you're not seeing an immediate gain is probably that the deduplication on Netapp is post process. The Netapp does a bit-to-bit comparison of any candidate blocks as a background task before deduplicating (which replaces a duplicate block with a pointer to an original block). This process is managed centrally, so only your storage admin can tell you what the schedule is. It's a lot of reads, so people tend to not schedule it during, for example, backups.

share|improve this answer
You also won't see the dedupe saving on ls - you'll see the original file size. You may not even see it on dfas that depends rather if the exported filesystem is a volume or (quotaed) qtree. And whether snapshots are enabled. (First pass dedupe saving probably moves into snapshots, and only actually saves space once snaps expire) – Sobrique May 15 '14 at 14:27
The asker specified that they're using du :) – Basil May 15 '14 at 18:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.