Talk:Hardware compression: Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
mNo edit summary
 
No edit summary
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Shouldn't the Linux example '''mt -f /dev/nst0 datcompression 0''' actually be '''mt -f /dev/nst0 defcompression 0'''?
Shouldn't the Linux example '''mt -f /dev/nst0 datcompression 0''' actually be '''mt -f /dev/nst0 defcompression 0'''?
[[User:Paddy|Paddy]] 13:24, 5 January 2007 (PST) Yes. you are correct. I will fix it.
== Verifying hardware compression status ==
Is there any way to verify that the hardware compression is actually ON or OFF?
--[[User:Maximd|maximd]] 05:02, 12 March 2009 (PDT)
Best is to run '''amtapetype -c''' with a scratch tape inserted (it will be erased). It detects hw compression without trusting any settings, but by measuring tape write speed difference, a direct result of the fact that very compressable input data results in much less bits to write to tape with hw compression on, and thus a significant larger throughput in that case.
(See man page for more details).
--[[User:Paul.bijnens|Paul.bijnens]] 05:49, 12 March 2009 (PDT)

Latest revision as of 12:49, 12 March 2009

Shouldn't the Linux example mt -f /dev/nst0 datcompression 0 actually be mt -f /dev/nst0 defcompression 0?

Paddy 13:24, 5 January 2007 (PST) Yes. you are correct. I will fix it.

Verifying hardware compression status

Is there any way to verify that the hardware compression is actually ON or OFF?

--maximd 05:02, 12 March 2009 (PDT)

Best is to run amtapetype -c with a scratch tape inserted (it will be erased). It detects hw compression without trusting any settings, but by measuring tape write speed difference, a direct result of the fact that very compressable input data results in much less bits to write to tape with hw compression on, and thus a significant larger throughput in that case. (See man page for more details).

--Paul.bijnens 05:49, 12 March 2009 (PDT)