On Sat March 29 2003 12:04, Jean-Louis Martineau wrote: >Hi Mike, > >Thanks for your good description of the problem. > >You found a bug in a the way the taper read a file from holding > disk if blocksize > 32k. > >There is two posible workaround (untested). > >1. Set your chunksize to '32k + n * blocksize' where n is an > integer. >2. Set file-pad to false. > >Setting chunksize to an arbitrary big value will not work if a >dump must be written to two different holding disk, you should set >it acording to workaround 1. > >Jean-Louis
Humm. While looking for the file-pad variable, right above it is this statement, which seems like a rather odd way of saying that the blocksize as used is actually fixed at 32768 bytes ----------------------- blocksize "int" Default: 32 kbytes. How much data will be written in each tape record. The minimum blocksize value is 32 KBytes. The maximum blocksize value is 32 KBytes. ----------------------- Please comment or discuss this. >On Fri, Mar 28, 2003 at 11:46:11AM -0600, Mike Simpson wrote: >> Hi -- >> >> > Any tips or tricks or other thoughts? Is this the Linux >> > dump/restore problem I've seen talked about on the mailing >> > list? I don't understand how the gzip file could be corrupted >> > by a problem internal to the dump/restore cycle. >> >> Answering my own question after a week of testing ... I think >> I've discovered a bug in Amanda 2.4.4. This is what I've >> deciphered: >> >> (1) Restores of backup sets that compressed to < 1 gb worked >> fine. Backup sets that, when compressed, were > 1 GB blew up >> every time with gzip corruption error messages. This was >> consistent across OS's (Solaris 8, RedHat 7.x), filesystem types >> (ufs, vxfs, ext2/3), and backup modes (DUMP, GNUTAR). >> >> (2) The gzip corruption message always occured at the same spot, >> i.e. >> >> gzip: stdin: invalid compressed data--format violated >> Error 32 (Broken pipe) offset 1073741824+131072, wrote 0 >> >> which is 1024^3 bytes + 128k. I note that in my Amanda >> configuration, I had "chunksize" defined to "1 gbyte" and >> "blocksize" set to "128 kbytes" (the chunksize was just for >> convenience, the blocksize seems to maximize my write >> performance). >> >> (3) I used "dd" to retrieve one of the compressed images that >> was failing. At the 1 gb mark in the file, the more-or-less >> random bytes of the compressed stream were interrupted by >> exactly 32k of zeroed bytes. I note that 32k is Amanda's >> default blocksize. >> >> (4) For last night's backups, I set "chunksize" to an >> arbitrarily high number, to prevent chunking, which works fine >> in my setup because I use one very large ext3 partition for all >> of my Amanda holding disk, which nullifies concerns about >> filesystem size and max file size. The restores I've done this >> morning have all worked fine, including the ones that had >> previously shown the corruption. >> >> I'm not enough of a C coder to come up with a real patch to fix >> this. I'm hoping the above gives enough clues to let someone who >> _is_ a real C coder do so. >> >> If this should be posted to the amanda-hackers list, please feel >> free to do so, or let me know and I'll do it. Also, if any >> other information would be helpful, just ask. >> >> Thanks, >> >> -mgs -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.25% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.