SCSI DDS tape compression
Hi, I am using amanda with DDS tapes without h/w compression and during boot the compression is disabled using mt. I noticed however a different behaviour between the mt in the cpio 2.6 package (in opensuse 10.2) and the version 2.9 which is in opensuse 11.1. The command is mt -f [dev] datcompression [count] The mt man page says: - if count is 0 - compression off - if count == 1 - status is printed - if anything else, or blank - compression on However in 2.6: - if count == 0 - off - if count == 1 or blank - status is printed - anyhing else - on And in 2.9: - if count == 0 - off - if anything else (including 1 or blank) - on and there is no count value which gives the status printed This is of course not an amanda issue, but I thought it worthwhile to let you know, in case you were also using 1 as the inquiry count, but it actually enabled the compression again. Regards, Charles
Weird compression results for DLE using 'compress NONE' (nocomp-root)
Hi I've got several disks that are showing weird compression results in the amanda report. Here's one of them: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- --- host /disk 1 20316904063380 200.0 36:34 1852.3 6:27 10487.2 Note the ORIG-KB blows out to twice the size! COMP% is 200.0... This happens on more that one disk actually. I chose this disk as it's the biggest disk that I dump, it shows the most expansive blowout and I noticed it first. This disk uses 'compress NONE' (dumptype is nocomp-root). Some of the other disks showing compression weirdness are using 'compress client fast' in their DLE's. Just so you know, I'm using file tapes for this backup. The size on disk is: -rw--- 1 amanda disk 4160933888 Jan 21 22:53 00018.host._disk.1 The server is amanda 2.6.0p2 and the client is amanda 2.4.4p3-1. There are a few more details below that may help. I'm not sure what's happening but do appreciate any help regarding the strange results. Thanks in advance, Tom amadmin conf disklist shows: host host: interface default disk /disk: program DUMP priority 0 dumpcycle 7 maxdumps 1 maxpromoteday 1 bumppercent 20 bumpdays 1 bumpmult 4.00 strategy STANDARD ignore NO estimate CLIENT compress NONE encrypt NONE auth BSD kencrypt NO amandad_path X client_username X ssh_keys X holdingdisk AUTO record YES index YES starttime fallback_splitsize 10Mb skip-incr NO skip-full NO spindle -1 the log entries for that disk are: SUCCESS dumper host /disk 20090121214501 1 [sec 2193.730 kb 4063380 kps 1852.3 orig-kb 2031690] SUCCESS chunker host /disk 20090121214501 1 [sec 2193.762 kb 4063380 kps 1852.3] STATS driver estimate host /disk 20090121214501 1 [sec 2090 nkb 4064493 ckb 4064512 kps 1945] PART taper conf 18 host /disk 20090121214501 1/1 1 [sec 387.462180 kb 4063380 kps 10487.165483] DONE taper host /disk 20090121214501 1 1 [sec 387.462180 kb 4063380 kps 10487.165483] -- Tom Robinson System Administrator MoTeC 121 Merrindale Drive Croydon South 3136 Victoria Australia T: +61 3 9761 5050 F: +61 3 9761 5051 M: +61 4 3268 7026 E: tom.robin...@motec.com.au
Re: Weird compression results for DLE using 'compress NONE' (nocomp-root)
John Hein wrote: John Hein wrote at 21:38 -0700 on Jan 21, 2009: Tom Robinson wrote at 12:30 +1100 on Jan 22, 2009: I've got several disks that are showing weird compression results in the amanda report. Here's one of them: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- --- host /disk 1 20316904063380 200.0 36:34 1852.3 6:27 10487.2 Note the ORIG-KB blows out to twice the size! COMP% is 200.0... This happens on more that one disk actually. I chose this disk as it's the biggest disk that I dump, it shows the most expansive blowout and I noticed it first. This disk uses 'compress NONE' (dumptype is nocomp-root). Some of the other disks showing compression weirdness are using 'compress client fast' in their DLE's. Smells like a factor of two error somewhere (512 byte blocks vs. 1024?). What does 'env -i du -ks /disk' say? Never mind that last request... your report above shows a level 1, not 0. So du output won't be a useful comparision to the numbers above. Does it behave the same (x2) for level 0 dumps, too? The last full run looks like this: host /disk 0 75564750 108727227 143.9 384:15 4716.0 98:47 18345.1 The thing is, I WAS using compression back then and thought that maybe it was causing the blowout so turned it off. (I'm yet to run a full dump on 'compress NONE'). It's not quite x2 but its larger than ORIG-KB. t. -- Tom Robinson System Administrator MoTeC 121 Merrindale Drive Croydon South 3136 Victoria Australia T: +61 3 9761 5050 F: +61 3 9761 5051 M: +61 4 3268 7026 E: tom.robin...@motec.com.au
Re: Weird compression results for DLE using 'compress NONE' (nocomp-root)
Tom Robinson wrote at 12:30 +1100 on Jan 22, 2009: I've got several disks that are showing weird compression results in the amanda report. Here's one of them: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- --- host /disk 1 20316904063380 200.0 36:34 1852.3 6:27 10487.2 Note the ORIG-KB blows out to twice the size! COMP% is 200.0... This happens on more that one disk actually. I chose this disk as it's the biggest disk that I dump, it shows the most expansive blowout and I noticed it first. This disk uses 'compress NONE' (dumptype is nocomp-root). Some of the other disks showing compression weirdness are using 'compress client fast' in their DLE's. Smells like a factor of two error somewhere (512 byte blocks vs. 1024?). What does 'env -i du -ks /disk' say?
Re: Weird compression results for DLE using 'compress NONE' (nocomp-root)
John Hein wrote at 21:38 -0700 on Jan 21, 2009: Tom Robinson wrote at 12:30 +1100 on Jan 22, 2009: I've got several disks that are showing weird compression results in the amanda report. Here's one of them: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- --- host /disk 1 20316904063380 200.0 36:34 1852.3 6:27 10487.2 Note the ORIG-KB blows out to twice the size! COMP% is 200.0... This happens on more that one disk actually. I chose this disk as it's the biggest disk that I dump, it shows the most expansive blowout and I noticed it first. This disk uses 'compress NONE' (dumptype is nocomp-root). Some of the other disks showing compression weirdness are using 'compress client fast' in their DLE's. Smells like a factor of two error somewhere (512 byte blocks vs. 1024?). What does 'env -i du -ks /disk' say? Never mind that last request... your report above shows a level 1, not 0. So du output won't be a useful comparision to the numbers above. Does it behave the same (x2) for level 0 dumps, too?
