zfs: du and df output with snapshots

M

mrab54

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.
 
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.
 
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.
 
Did you change the default zfs copies attribute of the original file system during or after creating it? You could compare the output of

Code: 
# zfs get copies /file system

between the two file systems to find out.
 
Code: 
# 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?
 
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.
 
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.
Click to expand...

The target directory ends up smaller than the source, sorry for the confusion. I'll have to try rsync tonight.
 
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:
Code: 
#!/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.
 
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.
 
You must log in or register to reply here.
Back
Top