On Wednesday 27 March 2002 09:03 am, Fernan Aguero wrote:
>Thanks everybody for your helpful responses. All of them had
>different and useful tips. I'll try to summarize and add some
>comments.
>
>i) Regarding compression on FreeBSD: thanks John (Merryweath) for
>reminding me of mt.
>I have now turned HW compression ON && host control ON and I can
>manage it myself!
>
>ii) Thanks Joshua & John (Jackson) for the tips on the tapelength when
>using hardware compression. I'll try to lie to amanda :( for a few
> runs and see what I get for every fs.
>
>iii) After thinking a bit on what Gene wrote regarding hardware
> compression ("Generally speaking, the hardware compression should be
> disabled.") I can only say that I haven't made a final decision and
> I'm just doing my experience on this.
>I thought about leaving the task to the tape drive, mostly
>because both the client and the server (the only two machines we have)
>are sometimes running important processes that need CPU resources
>badly. And even when they're not, the times are not predictable
>(sometimes we leave things running overnight, for a whole weekend, or
>even for weeks ...)
>
>iv) Regarding what Gene wrote about drives switching compression
>back on (if they find a compressed tape): AFAIK the HP DAT 40 will
>read compressed tapes no matter what the compression setting is. (Even
>if you set the jumpers on the hardware to turn both compression and
>host control to OFF). But I cannot tell if this means that compression
>will get turned ON for writes afterward (I haven't actually
>tested it).That was what I found in the case of the seagate changer in this machine. It may be possible to turn it off, but it would require that the compression off command be issued somehow after the header read and rewind, and before the subsequent write operation to over-write the header. I've even fooled around using dd to rewrite the header read, set it off, and write it back. No luck with this particular drive. And the compression is slowly contaminating the rest of my tapes. :((( >And finally >v) Gene said: "Any partition thats that much gzipped already, should > have the compression turned off, doing a straight tar of it." >Again, I'm a newbie, and if I decided not to use tar, was not based on >my own experience but from what I've read elsewhere. >I'd like to know your points here. I have avoided tar, because earlier >on when I did backups manually (i.e. without amanda) I had a few >problems with tar (FreeBSD tar, v1.11.2), and upon >reading several mail archives with the same or similar problems >(quitting after too many errors, even when tar started >extracting/reading OK) other people suggested avoiding tar in favor of >dump. >But again, I'm open to be converted back to tar if I can trust it. >(I know that while installing amanda's freebsd port, it required >gtar-1.13.25 so perhaps I should give now gtar a chance?) Yes. That new a tar has no known gotchas. One or 2 of the earlier 1.13 issues had some real killers. :)) I'm a tar fan, mainly because tar doesn't care about the filesystem, ext2, ext3, reiserfs, etc. Dump is based on the inode structure of the filesystem I believe, and therefore not as 'portable'. Speedwise, on todays hardware, its a moot point IMO. YMMV as usual. Cheers, Gene
