# zfs: du and df output with snapshots



## mrab54 (Jan 24, 2013)

I am attempting to copy all of my data from zfs Filesystem A to zfs Filesystem B (same zpool).  I used the following to copy the data: 
`# pax -p aop -rw . /dest`

pax completes without error.

When I run `# df -h`
I see 694G for Filesystem A and 461G for Filesystem B.  I see similar results when using du.  But, a file count produces the same number of files in both directories.  I've repeated the copy twice, both having the same results.

At one point I had taken a snapshot of Filesystem A.  Would that be the cause of the discrepancy of df/du?  How can you get the file size of a file minus the zfs bits?

I should note, compression is disabled on both filesystems.


----------



## wblock@ (Jan 24, 2013)

df(1) and du(1) use different methods to calculate space.  There is an entry in the FAQ about it: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#du-vs-df

But more to the point: zfs send and zfs receive are made for copying from one ZFS filesystem to another.  See zfs(8).


----------



## mrab54 (Jan 24, 2013)

My concern is that when I used pax to copy one directory to another, the resulting file sizes of source and dest directories differ.  If you take zfs out of the picture that discrepancy should only happen if some of the files were unable to be copied.  A file count on the source and destination rules out that possibility.  

My question remains - why are the file sizes of the source/dest different?  My suspicion is that it has something to do with how du/df works with zfs and the fact that I had previously taken a snapshot of Filesystem A.


----------



## wblock@ (Jan 24, 2013)

If the target directory was larger than the source, hard links are usually the cause.  Here, I don't know.  Try copying with net/rsync, using -axHAXS, and maybe --delete.


----------



## protocelt (Jan 24, 2013)

Did you change the default zfs copies attribute of the original file system during or after creating it? You could compare the output of


```
# zfs get copies /file system
```

between the two file systems to find out.


----------



## mrab54 (Jan 24, 2013)

```
# zfs get copies
NAME                       PROPERTY  VALUE   SOURCE
...
zroot/usr/home             copies    1       local
zroot/homebackup           copies    1       default
...
```

zroot/usr/home is the only directory that shows a Source as "local".  Does that mean I had copies on at one time?


----------



## wblock@ (Jan 24, 2013)

Incidentally, you can use the rsync(1) options in post #4 and add -nv to do a fake copy that will show what it finds is different between the two directories without actually copying or deleting anything.


----------



## mrab54 (Jan 24, 2013)

wblock@ said:
			
		

> If the target directory was larger than the source, hard links are usually the cause.  Here, I don't know.  Try copying with net/rsync, using -axHAXS, and maybe --delete.



The target directory ends up smaller than the source, sorry for the confusion.  I'll have to try rsync tonight.


----------



## mrab54 (Jan 25, 2013)

I ran the following to get a history of my zpool commands:
`# zpool history`

From the output, I was able to verify that I did indeed enable 2 copies on Filesystem A at some point in time, then set copies back to 1.

Then, I ran the following script on Filesystem A and Filesystem B:

```
#!/bin/sh

while read line
do
    #stat -f "%N %z" "$line"
    stat -f "%N %z %b" "$line"  
    # %N(filename) %z(filesize st_size) %b(blocks allocated st_blocks)
done << HERE
`find . -type f -print`
HERE
```

The filesize of all files are equivalent, while the blocks allocated are greater for many files in Filesystem A.  This verifies my assumption - the files themselves copied just fine, there are simply extra zfs bits in Filesystem A.  

Thanks for the suggestions.


----------



## kpa (Jan 25, 2013)

If you had copies set to 2 at some point the files that were created at that time are still taking double the space, ZFS doesn't remove the extra copies automatically until the files are recreated from scratch.


----------

