On Wed, 3 Mar 2010, John Austin wrote:
Date: Wed, 03 Mar 2010 13:06:11 +0000 From: John Austin ja@jaa.org.uk Reply-To: ja@ee.port.ac.uk, Community support for Fedora users users@lists.fedoraproject.org To: users@lists.fedoraproject.org Subject: Dump/Restore Errors
Hi
I have been following recent threads about the best way to clone/backup disks.
"Risks of backing up live mounted filesystems using dump(8)"
I have just tested dump/restore using a System Rescue CD using dump 0.4b42
The source /dev/sda7 is a fully working updated F12 / partition (including /boot)
The destination is a similar partition on the same disk /dev/sda9
mkfs -t ext3 /dev/sda9 mkdir /mnt/out mount /dev/sda9 /mnt/out dump 0f - /dev/sda7 | (cd /mnt/out; restore -rf -) 40GB dump/restore took 46 minutes
I received 9 errors of the type
resync restore, skipped 1 blocks error in EA block 1 magic = 0
Google tells me that dump saves as is and that restore is finding an error in an Attribute Block (maybe/sometimes associated with NFS)
I have not been able to find definitive answers to some obvious questions.
- Are these fatal for the file concerned hence invalidating the clone/backup?
I am unsure how to interpret the error message
Why are they present in the first place?
How can I find which files they are caused by?
Can I correct the errors, do I need to?
Grateful for any help
Regards John
On Wed, 2010-03-03 at 18:56 -0600, Paul Thompson wrote: I believe these generally fall on files which were deleted between when the index was created and the file is reached in the backup.
Second attempt at posting !!
Hi Paul
Yes I had thought along those lines as I originally had the source partition mounted.
However I repeated the dump/restore and the case shown above was with the source unmounted and hence I believe the errors are present in the source partition/file system.
I assume something is wrong in the SElinux extended attributes?
I have seen this suggestion for "processing" the source file system before executing the dump/restore.
However I don't know enough about SELinux to feel confident about using it.
Disable selinux; reboot and then find . -exec setfattr -h -x security.selinux '{}' ;
Is it a good idea to zap all SELinux attributes in the first place? a. When the partition/file system is / for the operating system b. When the partition/file system is mounted from a rescue CD boot?
John
On 03/04/2010 04:39 AM, John Austin wrote:
On Wed, 3 Mar 2010, John Austin wrote:
Date: Wed, 03 Mar 2010 13:06:11 +0000 From: John Austinja@jaa.org.uk Reply-To: ja@ee.port.ac.uk, Community support for Fedora usersusers@lists.fedoraproject.org To: users@lists.fedoraproject.org Subject: Dump/Restore Errors
Hi
I have been following recent threads about the best way to clone/backup disks.
"Risks of backing up live mounted filesystems using dump(8)"
I have just tested dump/restore using a System Rescue CD using dump 0.4b42
The source /dev/sda7 is a fully working updated F12 / partition (including /boot)
The destination is a similar partition on the same disk /dev/sda9
mkfs -t ext3 /dev/sda9 mkdir /mnt/out mount /dev/sda9 /mnt/out dump 0f - /dev/sda7 | (cd /mnt/out; restore -rf -) 40GB dump/restore took 46 minutes
I received 9 errors of the type
resync restore, skipped 1 blocks error in EA block 1 magic = 0
Google tells me that dump saves as is and that restore is finding an error in an Attribute Block (maybe/sometimes associated with NFS)
I have not been able to find definitive answers to some obvious questions.
Are these fatal for the file concerned hence invalidating the clone/backup? I am unsure how to interpret the error message
Why are they present in the first place?
How can I find which files they are caused by?
Can I correct the errors, do I need to?
Grateful for any help
Regards John
On Wed, 2010-03-03 at 18:56 -0600, Paul Thompson wrote: I believe these generally fall on files which were deleted between when the index was created and the file is reached in the backup.
Second attempt at posting !!
Hi Paul
Yes I had thought along those lines as I originally had the source partition mounted.
However I repeated the dump/restore and the case shown above was with the source unmounted and hence I believe the errors are present in the source partition/file system.
I assume something is wrong in the SElinux extended attributes?
I have seen this suggestion for "processing" the source file system before executing the dump/restore.
However I don't know enough about SELinux to feel confident about using it.
Disable selinux; reboot and then find . -exec setfattr -h -x security.selinux '{}' ;
Is it a good idea to zap all SELinux attributes in the first place? a. When the partition/file system is / for the operating system b. When the partition/file system is mounted from a rescue CD boot?
John
SELinux attributes on a disabled system should not cause any problems. If an extented attribute is causeing these tools to break, then the tools have a bug. Please open a bugzilla.
Having to manually remove all attributes should not be necessary.
I have just tested dump/restore using a System Rescue CD using dump 0.4b42
The source /dev/sda7 is a fully working updated F12 / partition (including /boot)
The destination is a similar partition on the same disk /dev/sda9
mkfs -t ext3 /dev/sda9 mkdir /mnt/out mount /dev/sda9 /mnt/out dump 0f - /dev/sda7 | (cd /mnt/out; restore -rf -) 40GB dump/restore took 46 minutes
I received 9 errors of the type
resync restore, skipped 1 blocks error in EA block 1 magic = 0
...
SELinux attributes on a disabled system should not cause any problems. If an extented attribute is causeing these tools to break, then the tools have a bug. Please open a bugzilla.
Having to manually remove all attributes should not be necessary.
From: Paul Thompson pt@new.rr.com To: John Austin ja@jaa.org.uk Subject: Re: Dump/Restore Errors Date: 03/04/2010 07:17:19 PM I think I deleted all the logs I generated because this had bothered me enough that I was going to file a bugzilla on it. Maybe what you're noticing is subltly different from what I had happen but I remember being surprised that no one would have remarked on it previously.
I duplicated it on systems from FC9 through 12 and could not convince myself it was anything other than some debugging print statement accidentally left "on" in the restore command.
I recall suspecting a selinux component to it, but when I actually traced the error to which file was being backed up at the time, it wound up being bogus stuff every time. FIFO files, temporary mozilla files, etc.
I did some combination of dump -v, strace in a logged screen session and a restore -d and strace in a logged screen session.
---------------------------------------------------------- Hi Paul and Daniel
I have now investigated further and found the files that are causing the problem
In each case the problem seems to be "an extra block"
File header, ino 1048703; predicted 0 blocks, got 1 blocks
This doesn't help me much as I don't know what it really means
All the problem files but one do not seem too important to me
but /var/lib/rpm/Providename might well be !
Six are associated with kde
It is still not clear to me whether
1. the original file system has the 9 errors and dump/restore detects them
2. the file system is correct and dump/restore incorrectly indicates an error (and possibly corrupts the restored file system)
3. the error messages are miss-leading and nothing to do with SELinux
Do you think I should submit a bugzilla ? Against dump/restore ?
Are there any other tests I can usefully make ?
John
fuerte ~ 3# cat error_files extract file ./root/.mozilla/firefox/6lanhsnd.default/Cache/_CACHE_003_ File header, ino 1048703 File continuation header, ino 1048703 reading EA data for inode 1048703 File header, ino 1048703; predicted 0 blocks, got 1 blocks resync restore, skipped 1 blocks xattr_extract(./root/.mozilla/firefox/6lanhsnd.default/Cache/_CACHE_003_) error in EA block 1 magic = 0 ---------------------------------- extract file ./var/lib/rpm/Providename File header, ino 1327114 File continuation header, ino 1327114 File continuation header, ino 1327114 reading EA data for inode 1327114 File header, ino 1327114; predicted 0 blocks, got 1 blocks resync restore, skipped 1 blocks xattr_extract(./var/lib/rpm/Providename) error in EA block 1 magic = 0 ---------------------------------- extract file ./var/tmp/kdecache-root/kpc/kde-icon-cache.index File header, ino 1376288 File continuation header, ino 1376288 ... File continuation header, ino 1376288 reading EA data for inode 1376288 File header, ino 1376288; predicted 0 blocks, got 1 blocks resync restore, skipped 1 blocks xattr_extract(./var/tmp/kdecache-root/kpc/kde-icon-cache.index) error in EA block 1 magic = 0 ---------------------------------- extract file ./var/tmp/kdecache-root/kpc/kde-icon-cache.data File header, ino 1376305 File continuation header, ino 1376305 ... File continuation header, ino 1376305 reading EA data for inode 1376305 File header, ino 1376305; predicted 0 blocks, got 1 blocks resync restore, skipped 1 blocks xattr_extract(./var/tmp/kdecache-root/kpc/kde-icon-cache.data) error in EA block 1 magic = 0 ---------------------------------- extract file ./var/tmp/kdecache-fred/kpc/kde-icon-cache.updated File header, ino 1376307 reading EA data for inode 1376307 File header, ino 1376307; predicted 0 blocks, got 1 blocks resync restore, skipped 1 blocks xattr_extract(./var/tmp/kdecache-fred/kpc/kde-icon-cache.updated) error in EA block 1 magic = 0 ---------------------------------- extract file ./var/tmp/kdecache-fred/kpc/kde-icon-cache.index File header, ino 1376347 File continuation header, ino 1376347 ... File continuation header, ino 1376347 reading EA data for inode 1376347 File header, ino 1376347; predicted 0 blocks, got 1 blocks resync restore, skipped 1 blocks xattr_extract(./var/tmp/kdecache-fred/kpc/kde-icon-cache.index) error in EA block 1 magic = 0 ---------------------------------- extract file ./var/tmp/kdecache-fred/kpc/kde-icon-cache.data File header, ino 1376351 File continuation header, ino 1376351 ... File continuation header, ino 1376351 reading EA data for inode 1376351 File header, ino 1376351; predicted 0 blocks, got 1 blocks resync restore, skipped 1 blocks xattr_extract(./var/tmp/kdecache-fred/kpc/kde-icon-cache.data) error in EA block 1 magic = 0 ---------------------------------- extract file ./var/tmp/kdecache-ja/kpc/kde-icon-cache.index File header, ino 1630260 File continuation header, ino 1630260 ... File continuation header, ino 1630260 reading EA data for inode 1630260 File header, ino 1630260; predicted 0 blocks, got 1 blocks resync restore, skipped 1 blocks xattr_extract(./var/tmp/kdecache-ja/kpc/kde-icon-cache.index) error in EA block 1 magic = 0 ---------------------------------- extract file ./var/tmp/kdecache-ja/kpc/kde-icon-cache.data File header, ino 1630268 File continuation header, ino 1630268 ... File continuation header, ino 1630268 reading EA data for inode 1630268 File header, ino 1630268; predicted 0 blocks, got 1 blocks resync restore, skipped 1 blocks xattr_extract(./var/tmp/kdecache-ja/kpc/kde-icon-cache.data) error in EA block 1 magic = 0
Hi
I have submitted a buzilla to sourceforge re dump/restore
http://sourceforge.net/tracker/?func=detail&aid=2964667&group_id=130...
John
On Sat, 2010-03-06 at 10:59 +0000, John Austin wrote:
Hi
I have submitted a buzilla to sourceforge re dump/restore
http://sourceforge.net/tracker/?func=detail&aid=2964667&group_id=130...
John
This problem has now been fixed in CVS!
From Stelian
Date: 2010-03-19 13:53 "Ok, found it: it is a genuine bug in dump, the "header" block for the extended attributes is not correctly filled with the needed information."
Date: 2010-03-22 15:40 "Thanks for the feedback, the fixes have now been commited in CVS."
John