RE: Samba - which does compress-client-best point to?
Thanks for the info Paul (and Jay). Paul, a few additional questions directed towards your response. In my experience the compress best uses 4 times as much CPU for only 5% better compression, so it's not worth it, unless you have spare CPU cycles to burn. Maybe it's better to increase the dumpcycle (maybe Is this 5% difference you're referring to between compress-fast vs. compress-best? Right. If you think a litter more about this, the amanda server does not need to be the computer that runs smbclient. My amandaserver has already his cpu fully loaded, and two other machines do the smbclient backups for my window machines, and they do the compression too. How could I offload the smbclient connections through another machine? Are you implying an smbmount on the client, or is there some trick with smbclient that I'm not thinking of right now? -Rob
Re: Samba - which does compress-client-best point to?
On Fri, Oct 24, 2003 at 08:55:16AM -0700, Dege, Robert C. wrote: Thanks for the info Paul (and Jay). Paul, a few additional questions directed towards your response. In my experience the compress best uses 4 times as much CPU for only 5% better compression, so it's not worth it, unless you have spare CPU cycles to burn. Maybe it's better to increase the dumpcycle (maybe Is this 5% difference you're referring to between compress-fast vs. compress-best? I've done similar measurements to Paul's and while I found a bigger difference between --fast and --best (aka -1 and -9 with 7 more gradations between) it was not huge. And yes, we are refering to compression of say 45% reduction with --fast vs say 55% with --best. But as Paul indicates with a 4x (I saw 5x) increase in cpu usage. What I also found was the writers of gzip picked a default of -6 which in my tests gives the bulk of the increased compression for only about 1.8x cpu usage compared to -1. The improvements in compression at levels -7, -8, and -9 were tiny for the increased cpu usage. Right. If you think a litter more about this, the amanda server does not need to be the computer that runs smbclient. My amandaserver has already his cpu fully loaded, and two other machines do the smbclient backups for my window machines, and they do the compression too. How could I offload the smbclient connections through another machine? Are you implying an smbmount on the client, or is there some trick with smbclient that I'm not thinking of right now? If hostA is the amanda tape server (also its own client possibly) you probably have disklist entries like hostA //pchost/xyz. But if you have other unix systems that can do samba too (say hostB), just change the quoted string to use hostB instead of hostA. If hostB does client-side compression then the compression burden is offloaded from hostA to hostB. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Samba - which does compress-client-best point to?
System: RedHat 7.1, kernel 2.4.19 amanda 2.4.2p2, samba 2.2.6 I've been backing up several Windows machines for a while now (months). Recently, I've been getting cramped with tape space, so I added compress-client-best to my samba-pc dump type. However, while watching amanda perform the dump, it seems as if the linux server is compressing the data, and not the windows client. The more I think about it, the more it makes sense, since amanda treats the smbclient connection as an ftp connection rather than an amanda client machine. So the amanda server itself is the client, and the server in one for the samba backups (right?) But, my amanda server is slow. So the PC stays connected while the dumper compresses the dumped files. Would the dumper relinquish the machine faster if I used compress-svr-fast vs. compress-client-fast? -Rob
Re: Samba - which does compress-client-best point to?
Dege, Robert C. wrote: System: RedHat 7.1, kernel 2.4.19 amanda 2.4.2p2, samba 2.2.6 I've been backing up several Windows machines for a while now (months). Recently, I've been getting cramped with tape space, so I added compress-client-best to my samba-pc dump type. In my experience the compress best uses 4 times as much CPU for only 5% better compression, so it's not worth it, unless you have spare CPU cycles to burn. Maybe it's better to increase the dumpcycle (maybe add more tapes to the tapecycle too), at the cost of having higher incrementals. Unless you have already a dumpcycle that's very long... (Many people run with a dumpcycle of 2 weeks, some even more.) If you don't have a changer, but you do have large enough holdingdisk, one of the options is also to set runtapes 2 and reserve 0, and let the dumps go to one tape, and overflow on holdingdisk, which you flush each morning manually. However, while watching amanda perform the dump, it seems as if the linux server is compressing the data, and not the windows client. The more I think about it, the more it makes sense, since amanda treats the smbclient connection as an ftp connection rather than an amanda client machine. So the amanda server itself is the client, and the server in one for the samba backups (right?) Right. If you think a litter more about this, the amanda server does not need to be the computer that runs smbclient. My amandaserver has already his cpu fully loaded, and two other machines do the smbclient backups for my window machines, and they do the compression too. But, my amanda server is slow. So the PC stays connected while the dumper compresses the dumped files. Would the dumper relinquish the machine faster if I used compress-svr-fast vs. compress-client-fast? Execute compress on the machine that has the free CPU cycles, be it your amanda server, be it one or more other machines. Another possibility is to run the cygwin client on the windows PC's themselves, and then they can do their own compression (but some recent messages on this list indicate cygwin+amanda+compression has some problems, yet to be solved). -- Paul @ Home