I just rsynced everything on one fs to another of the same type and size. Both underlying disks arw partitioned the same, and of the same model number. What could be causing this discrepancy in availiable space? [BCrook@Desktop1 ~]$ df -h Filesystem Size Used Avail Use% Mounted on .... /dev/mapper/crypt 688G 561G 120G 83% /mnt/crypt /dev/mapper/crypt2 688G 561G 92G 86% /mnt/crypt2 [BCrook@Desktop1 ~]$ mount ..... /dev/mapper/crypt on /mnt/crypt type ext3 (rw) /dev/mapper/crypt2 on /mnt/crypt2 type ext3 (rw)
On Sat, Jul 21, 2007 at 09:58:03AM -0500, Billy Crook wrote:
I just rsynced everything on one fs to another of the same type and size. Both underlying disks arw partitioned the same, and of the same model number. What could be causing this discrepancy in availiable space?
[BCrook@Desktop1 ~]$ df -h Filesystem Size Used Avail Use% Mounted on .... /dev/mapper/crypt 688G 561G 120G 83% /mnt/crypt /dev/mapper/crypt2 688G 561G 92G 86% /mnt/crypt2 [BCrook@Desktop1 ~]$ mount ..... /dev/mapper/crypt on /mnt/crypt type ext3 (rw) /dev/mapper/crypt2 on /mnt/crypt2 type ext3 (rw)
Check the reserved block count. This is the count of filesystem blocks reserved for the super-user. tune2fs -l /dev/mapper/crypt tune2fs -l /dev/mapper/crypt2 or dumpe2fs -h /dev/mapper/crypt dumpe2fs -h /dev/mapper/crypt2 At a guess, I'd say that crypt has a reserve of 0%, and crypt2 has a reserve of 5%, which is the mke2fs default. -- Hal Duston hald@kc.rr.com
That must be exactly it. I remember when I formatted crypt, I did specifiy options. Whereas when I formatted crypt2, I did not. Can't check to make sure though. crypt2 will be in a bank vault for 6 months. Crypt3 is in the works though. Should be ready to play with by next Friday. Im just glad it wasn't a filesystem error. On 7/21/07, Hal Duston <hald@kc.rr.com> wrote:
On Sat, Jul 21, 2007 at 09:58:03AM -0500, Billy Crook wrote:
I just rsynced everything on one fs to another of the same type and size. Both underlying disks arw partitioned the same, and of the same model number. What could be causing this discrepancy in availiable space?
[BCrook@Desktop1 ~]$ df -h Filesystem Size Used Avail Use% Mounted on .... /dev/mapper/crypt 688G 561G 120G 83% /mnt/crypt /dev/mapper/crypt2 688G 561G 92G 86% /mnt/crypt2 [BCrook@Desktop1 ~]$ mount ..... /dev/mapper/crypt on /mnt/crypt type ext3 (rw) /dev/mapper/crypt2 on /mnt/crypt2 type ext3 (rw)
Check the reserved block count. This is the count of filesystem blocks reserved for the super-user.
tune2fs -l /dev/mapper/crypt tune2fs -l /dev/mapper/crypt2
or
dumpe2fs -h /dev/mapper/crypt dumpe2fs -h /dev/mapper/crypt2
At a guess, I'd say that crypt has a reserve of 0%, and crypt2 has a reserve of 5%, which is the mke2fs default.
-- Hal Duston hald@kc.rr.com _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Billy Crook wrote:
That must be exactly it. I remember when I formatted crypt, I did specifiy options. Whereas when I formatted crypt2, I did not. Can't check to make sure though. crypt2 will be in a bank vault for 6 months. Crypt3 is in the works though. Should be ready to play with by next Friday. Im just glad it wasn't a filesystem error.
The other thing that can cause this are hard links, which are *NOT* copied by default when using the -a switch to rsync. You have to specify --hard-links or you wind up with N actual copies of any hardlinked files, instead of one file and N inodes. - -- Charles Steinkuehler charles@steinkuehler.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGomiNLywbqEHdNFwRAmibAKDS5RixuHos1h0on7fxQRQZTQTPnwCggAv5 aeotZsbZrSWZOCo5jcXZHFk= =kYE+ -----END PGP SIGNATURE-----
I read the man pace ahead of time, and noticed that little quirk. i guess i understand why it might copy each link to the inode as a seperate file. It makes me wonder though if there's not a better tool for the job of replicating a filesystem to another disk aside from dd'ing the whole thing. On 7/21/07, Charles Steinkuehler <charles@steinkuehler.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Billy Crook wrote:
That must be exactly it. I remember when I formatted crypt, I did specifiy options. Whereas when I formatted crypt2, I did not. Can't check to make sure though. crypt2 will be in a bank vault for 6 months. Crypt3 is in the works though. Should be ready to play with by next Friday. Im just glad it wasn't a filesystem error.
The other thing that can cause this are hard links, which are *NOT* copied by default when using the -a switch to rsync. You have to specify --hard-links or you wind up with N actual copies of any hardlinked files, instead of one file and N inodes.
- -- Charles Steinkuehler charles@steinkuehler.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGomiNLywbqEHdNFwRAmibAKDS5RixuHos1h0on7fxQRQZTQTPnwCggAv5 aeotZsbZrSWZOCo5jcXZHFk= =kYE+ -----END PGP SIGNATURE-----
The best software to make exact copies are dd and ghost. Newer tools worth looking into are partimage and clonezilla. There is a liveCD with gparted and clonezilla that I've been looking at lately. You may want to check it out. It is a good idea to make your ghost image or copy with a tool that does so while the on disk OS is inactive, such as with a liveCD or DOS boot image. Brian On 7/21/07, Billy Crook <> wrote:
I read the man pace ahead of time, and noticed that little quirk. i guess i understand why it might copy each link to the inode as a seperate file. It makes me wonder though if there's not a better tool for the job of replicating a filesystem to another disk aside from dd'ing the whole thing.
On 7/21/07, Charles Steinkuehler <> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Billy Crook wrote:
That must be exactly it. I remember when I formatted crypt, I did specifiy options. Whereas when I formatted crypt2, I did not. Can't check to make sure though. crypt2 will be in a bank vault for 6 months. Crypt3 is in the works though. Should be ready to play with by next Friday. Im just glad it wasn't a filesystem error.
The other thing that can cause this are hard links, which are *NOT* copied by default when using the -a switch to rsync. You have to specify --hard-links or you wind up with N actual copies of any hardlinked files, instead of one file and N inodes.
- -- Charles Steinkuehler
Billy Crook wrote:
I just rsynced everything on one fs to another of the same type and size. Both underlying disks arw partitioned the same, and of the same model number. What could be causing this discrepancy in availiable space?
[ BCrook@Desktop1 ~]$ df -h Filesystem Size Used Avail Use% Mounted on .... /dev/mapper/crypt 688G 561G 120G 83% /mnt/crypt /dev/mapper/crypt2 688G 561G 92G 86% /mnt/crypt2 [BCrook@Desktop1 ~]$ mount ..... /dev/mapper/crypt on /mnt/crypt type ext3 (rw) /dev/mapper/crypt2 on /mnt/crypt2 type ext3 (rw)
------------------------------------------------------------------------
_______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
What switches are you using for rsync? I typically use -aHx --delete when rsync'ing to a local disk for backup purposes. -Scott Oertel
participants (5)
-
Billy Crook -
Brian Kelsay -
Charles Steinkuehler -
Hal Duston -
Scott Oertel