Hristo Benev wrote: > Arno Lehmann wrote: >> Hi, >> >> On 9/25/2006 8:31 PM, Hristo Benev wrote: >> >>> Hi, >>> >>> I have Python 04106-XXX Rev: 7550 DDS-3 tape drive. >>> >>> Is there a way to check if HW compression is ON or OFF, and what is >>> better to use HW or SW one currently I use GZIP=1 SW one >>> >> >> Well, Hardware compression is done in the tape hardware. You transfer >> the uncompressed data through your network and backup server and SCSI >> subsystem, but don't need extra CPU power on the client. >> >> Personally, I prefer hardware compression, but there are claims that you >> might lose the whole tape contents when you encounter incompatible >> devices. Which is something I consider a myth, given that >> hardware-compressing tape drives are always compatible (as far as I know). >> >> Trying to compress pre-compressed or encrypted data is >> counterproductive, so, if you need fine-grained control over compression >> you better use software compression. >> >> > I'm aware of all this, but in my case I think SW compression is > better, because I have 10MB network between servers (and that is > enough for my setup - except backup there is no high bandwidth demand > application). > > Also I've tested the HW compression (on similar drive in 1999) and the > backup was much slower??? and compression really bad!!! > > Thats why I typed the command that should disable compression, but how > I can check??? > mt -f /dev/tape compression off I believe that tapeinfo (from mtx, I think) can give you the information that you are looking for (but you may have to figure out which is the generic device for your tape drive). You may also consider using stinit to initialize your tape settings at boot-time. With stinit, you can define several different modes of operation for the same tape device that will then be accessible as different tape device files (I believe if the 'real' device is /dev/st0, then the second mode could be accessed as /dev/st0a? README.st in the kernel source can probably tell you).
With your network topology, it seems like client-side sw compression could be a big win--assuming your clients are relatively recent vintage machines (given that your net is 10Mbit, not something I can assume :-)). For myself, when I was using DDS-3 and DDS-4 drives, I used _no_ compression, the hw compression module in at least HP DDS drives pretty much guaranteed that mostly non-compressible data would _grow_ in size, sometimes by as much as 15%. The bulk of my backups were compressed video/audio files, so no compression was the best answer for me. Now I've switched to LTO (specifically an IBM LTO-2 drive), and it can compress every set of data I send it (often not very much, but it never seems to expand the data, at least not by any amount I can detect). SW compression has the benefit that you can turn it on selectively, on a file pattern basis--I briefly did something like that too with hw compression, using two different modes (using stinit) for different backups with bacula, but it got too complicated (especially since one tape apparently cannot mix compressed and non-compressed use). I'm no expert, but I'm given to understand you may have to relabel your media if you change hw compression settings. Hope this helps, -se ------------------------------------------------------------------------- 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