On Thursday 03 August 2006 12:37 am, Beda Kosata wrote:
> Kern Sibbald wrote:
> > On Wednesday 02 August 2006 17:46, Mike Reinehr wrote:
> >>On Wednesday 02 August 2006 04:09 am, Kern Sibbald wrote:
> >>>On Wednesday 02 August 2006 10:58, Beda Kosata wrote:
> >>>>Kern Sibbald wrote:
> >>>>>On Wednesday 02 August 2006 06:40, Beda Kosata wrote:
> >>>>>>Dear all,
> >>>>>>I am using bacula to backup several of our machines and I have run
> >
> > into
> >
> >>>>>>a problem restoring one machine.
> >>>>>>All files are restored, but for some of them I get something like
> >>>>>> this in messages:
> >>>>>>
> >>>>>>01-Aug 15:31 fretka-fd: MilaRestoreFiles.2006-08-01_15.31.09 Error:
> >>>>>>Uncompression error on file
> >>>
> >>>/home/restore/home/nicmila/.thunderbird/fpjdjhkm.default/Mail/LocalFolde
> >>>r
> >>>
> >>>>>s/Sent.msf.
> >>>>>
> >>>>>>ERR=Zlib buffer error
> >>>>>>
> >>>>>>and the resulting files have zero length.
> >>>>>>This machine is a pretty new AMD64. When I have tried to restore to
> >>>>>> an older pentium4 machine, everything went ok. Both of them are
> >>>>>> running Gentoo Linux in similar configuration.
> >>>>>>Therefor I suspect the problem is in the 64bit machine. However
> >>>>>> trying to find any information on problems with zlib on AMD64 was
> >>>>>> not successful. I have tried to recompile both zlib and bacula, even
> >>>>>> with optimization turned off, but the errors remain.
> >>>>>>
> >>>>>>I would be glad for any suggestions how to fix this problem.
> >>>>>
> >>>>>Are you trying to restore files from Volumes that were written on the
> >>>
> >>>Pentium4
> >>>
> >>>>>on the AMD64 or did you write the Volumes with your AMD64?
> >>>>
> >>>>I am trying to restore files that were backed up on an older pentium
> >>>>machine (as part of hardware update). I have now tried to restore
> >>>> backup that was already made on the AMD64 machine and everything seems
> >>>> to be
> >
> > OK.
> >
> >>>>I guess it solves most of the problem for me now. Anyway I wonder what
> >>>>the problem is. Shouldn't zlib work regardless of the architecture?
> >>>
> >>>Yes, zlib should work regardless of the architecture -- this is a real
> >
> > pity
> >
> >>>to hear, because it means that zlib is not 32/64 bit clean and/or does
> >>> not take the trouble to handle byte order differences.
> >>>
> >>>Perhaps it is time to consider implementing other compression algorithms
> >>>such as lzma, which I believe were written more recently and probably
> >>>handle thes problems.
> >>>
> >>>I'll also take a note of this and check the Bacula code as it is
> >>> possible that there is a problem, though I doubt it.
> >>>
> >>>> Thanks
> >>>> Beda
> >>>>
> >>>>p.s.- bacula is great :)
> >>>
> >>>Thanks.
> >>>
> >>>Regards, Kern
> >>
> >>Kern,
> >>
> >>I've just checked the bug reports for Debian AMD64 & on the zlibc
> >> homepage
> >
> > and
> >
> >>can find no reference to any 64bit bugs. Also, there has been no mention
> >> of any zlibc problems on the Debian AMD64 mailing list. (I'm running
> >> Debian Sarge for AMD64 here, myself, but haven't used compression.) So I
> >> would suspect that the problem is limited either to Gentoo Linux, in
> >> particular,
> >
> > to
> >
> >>Mr. Kosata's system, or (I know this is a very remote possibility ;-)
> >
> > Bacula.
> >
> > I guess that I was not very precise. I did not mean to imply that this
> > was a 64 bit problem. What I was trying to say is that zlib does not
> > seem to be 32/64 bit clean, which means that if you compress data on a 32
> > bit machine and try to uncompress exactly the same data on a 64 bit
> > machine, it doesn't seem to work.
> >
> > Whether or not it is a zlib or a Bacula bug I cannot tell, but I do know
> > that we put a lot of effort in trying to ensure that Bacula is *totally*
> > 32/64 bit independent. Even routines such as the system printf() or
> > sscanf() are not even close to being 32/64 bit independent.
>
> I have made a few more test to be sure that it is not problem of one
> system. I have tried to restore files backed up on a 32bit machine onto
> *another* 64bit machine, with the same result - corrupted files.
> Restoring files backed up on a 64bit machine to a 32bit machine seems
> ok. The same is true for restoring files backed up on 64bit machine to
> another 64bit machine.
> So to summarize, it seems that
> 32 => 32 - OK
> 64 => 64 - OK
> 64 => 32 - OK
> 32 => 64 - Errors
>
> Unfortunately I cannot test 64bit machine under other OS than Gentoo Linux.
>
> Beda
>
I'm not sure that this is relevant, as I have not compiled anything
from
source--I just download binaries from the Debian mirrors. But if gzip &
gunzip use the same zlib's as are used in Bacula, then I do not have the 32
=> 64 errors here. As i test I compressed a tar archive with gzip on my
32-bit, PIII desktop; transferred it to my AMD64 Opeteron service and then
sucessfully uncompressed it with gunzip. The desktop runs a mixture of Debian
stable & testing while the server is running pure stable.
HTH
cmr
--
Debian 'Sarge': Registered Linux User #241964
----
"More laws, less justice." -- Marcus Tullius Ciceroca, 42 BC
--------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
