-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
And speaking of data migrations...
I performed an ndmpcopy of a filesystem to move it off of a set of DS14 Mk1 shelves (72 GB FC drives, which are now end of support) to a newer set of DS14Mk4 shelves containing 300 GB FC drives. The problem is that after ndmpcopy has finished, the source and destination volume sizes are different:
filer*> df -k old_vol Filesystem total used avail capacity Mounted on /vol/old_vol/ 547880960KB 401694484KB 146186476KB 73% /vol/old_vol/
filer*> df -k new_vol Filesystem total used avail capacity Mounted on /vol/new_vol/ 547880960KB 401639832KB 146241128KB 73% /vol/new_vol/
So we're looking at ~50 MB of difference between the two. After doing filesystem checks on both, I found that both contain the same number of files, all of which are equivalent in size. The directory structures are also equivalent, with one exception: one directory is 12KB on the source and 4KB on the destination. Another anomaly is that a 'df' of the filesystems on Solaris 10 show a difference of 16 files between the source and destination.
/usr/SAG/db-backup (filer:/vol/new_vol/db-backup):292482200 blocks 19023148 files /mnt/old_vol (filer:/vol/old_vol/db-backup):292372920 blocks 19023132 files
So, I know that ndmpcopy is a logical (not physical) copy of the volume, but how is that accounting for more files with fewer blocks? Is it an artifact of fragmentation and metadata changes in WAFL when the data is dumped? I don't have a good explanation for my customer, so I'm hoping someone here will have a quick and easy answer.
Thanks,
- -=Tom Nail
Is the directory entry larger on the source side than the dest?
This may be expected as large directories get large entries, but when you pull files from them...they dont shrink.
But would be smaller on the destination side as the directory entry has...well, fewer entries in it.
On Tue, Jul 10, 2012 at 9:17 AM, Thomas Nail tnail@austin.utexas.edu wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
And speaking of data migrations...
I performed an ndmpcopy of a filesystem to move it off of a set of DS14 Mk1 shelves (72 GB FC drives, which are now end of support) to a newer set of DS14Mk4 shelves containing 300 GB FC drives. The problem is that after ndmpcopy has finished, the source and destination volume sizes are different:
filer*> df -k old_vol Filesystem total used avail capacity Mounted on /vol/old_vol/ 547880960KB 401694484KB 146186476KB 73% /vol/old_vol/
filer*> df -k new_vol Filesystem total used avail capacity Mounted on /vol/new_vol/ 547880960KB 401639832KB 146241128KB 73% /vol/new_vol/
So we're looking at ~50 MB of difference between the two. After doing filesystem checks on both, I found that both contain the same number of files, all of which are equivalent in size. The directory structures are also equivalent, with one exception: one directory is 12KB on the source and 4KB on the destination. Another anomaly is that a 'df' of the filesystems on Solaris 10 show a difference of 16 files between the source and destination.
/usr/SAG/db-backup (filer:/vol/new_vol/db-backup):292482200 blocks 19023148 files /mnt/old_vol (filer:/vol/old_vol/db-backup):292372920 blocks 19023132 files
So, I know that ndmpcopy is a logical (not physical) copy of the volume, but how is that accounting for more files with fewer blocks? Is it an artifact of fragmentation and metadata changes in WAFL when the data is dumped? I don't have a good explanation for my customer, so I'm hoping someone here will have a quick and easy answer.
Thanks,
- -=Tom Nail
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/8VYkACgkQH7E81Q7leo5frgCfbLd7vEcYPqELc0A/rCnWkMzL IcYAni/30uPVEAyntWvaTCjeBCnTjPmZ =nqZ5 -----END PGP SIGNATURE----- _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Ditto. I have seen this myself many times which is one reason I do not like ndmpcopy and why if I am not doing a block-level copy I usually choose rsync.
--tmac Tim McCarthy Principal Consultant
RedHat Certified Engineer 804006984323821 (RHEL4) 805007643429572 (RHEL5)
On Tue, Jul 10, 2012 at 12:31 PM, Jeff Mohler speedtoys.racing@gmail.com wrote:
Is the directory entry larger on the source side than the dest?
This may be expected as large directories get large entries, but when you pull files from them...they dont shrink.
But would be smaller on the destination side as the directory entry has...well, fewer entries in it.
On Tue, Jul 10, 2012 at 9:17 AM, Thomas Nail tnail@austin.utexas.edu wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
And speaking of data migrations...
I performed an ndmpcopy of a filesystem to move it off of a set of DS14 Mk1 shelves (72 GB FC drives, which are now end of support) to a newer set of DS14Mk4 shelves containing 300 GB FC drives. The problem is that after ndmpcopy has finished, the source and destination volume sizes are different:
filer*> df -k old_vol Filesystem total used avail capacity Mounted on /vol/old_vol/ 547880960KB 401694484KB 146186476KB 73% /vol/old_vol/
filer*> df -k new_vol Filesystem total used avail capacity Mounted on /vol/new_vol/ 547880960KB 401639832KB 146241128KB 73% /vol/new_vol/
So we're looking at ~50 MB of difference between the two. After doing filesystem checks on both, I found that both contain the same number of files, all of which are equivalent in size. The directory structures are also equivalent, with one exception: one directory is 12KB on the source and 4KB on the destination. Another anomaly is that a 'df' of the filesystems on Solaris 10 show a difference of 16 files between the source and destination.
/usr/SAG/db-backup (filer:/vol/new_vol/db-backup):292482200 blocks 19023148 files /mnt/old_vol (filer:/vol/old_vol/db-backup):292372920 blocks 19023132 files
So, I know that ndmpcopy is a logical (not physical) copy of the volume, but how is that accounting for more files with fewer blocks? Is it an artifact of fragmentation and metadata changes in WAFL when the data is dumped? I don't have a good explanation for my customer, so I'm hoping someone here will have a quick and easy answer.
Thanks,
- -=Tom Nail
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/8VYkACgkQH7E81Q7leo5frgCfbLd7vEcYPqELc0A/rCnWkMzL IcYAni/30uPVEAyntWvaTCjeBCnTjPmZ =nqZ5 -----END PGP SIGNATURE----- _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
--
Gustatus Similis Pullus _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-
Jeff Mohler -
Thomas Nail -
tmac