* Brian Cuttler <[email protected]> [20140108 11:38]:
> On Wed, Jan 08, 2014 at 11:18:46AM -0500, Jean-Francois Malouin wrote:
> > * Brian Cuttler <[email protected]> [20140108 11:09]:
> > >
> > > Jean-Louis,
> > >
> > > googled it... I had my numbers wrong, it can supposedly hold
> > > 800 Gig, and with HW compression up to 2x that. I should not
> > > have to adjust the tape length and no reason (that I can see)
> > > for dumps to take more than one tape.
> > >
> > > Its odd that I'm not seeing an end of media error message...
> > > I think I need to run a cleaning tape and keep an eye on this.
> >
> > I was about to chime in but you bet me to it.
> > Indeed LTO4 is 800GB.
> >
> > Now, did you verify that you're in fact HW not using compression
> > enabled? Having both hw and sw compression can actually lead to
> > smaller tape usage and waste of cpu cycles.
> > I don't know about Solaris but on my Linux servers the command
> > tapeinfo from the mtx package will tell me You must pass it the
> > generic scsi device of the tape drive. In my case, it's /dev/sg7:
> >
> > ~# tapeinfo -f /dev/sg7
> > Product Type: Tape Drive
> > Vendor ID: 'HP '
> > Product ID: 'Ultrium 4-SCSI '
> > Revision: 'B12H'
> > Attached Changer API: No
> > SerialNumber: 'HUE084156W'
> > ...
> > DataCompEnabled: yes
> > DataCompCapable: yes
> > DataDeCompEnabled: yes
> > ...
>
> Ok, learn something new every day.
>
> The LTO is advertised as having block level decision making on
> compression so that it doesn't expand the data, wonder if that
> is not quite true.
>
> Also - Isn't there another level of tape header that needs to be
> cleared? Isn't re-writing the tape with compression off a little
> bit of a trick? If you don't clear that other level of header, then
> the compression is determined by the header info and not by the
> device type selected when you write the tape?
There ends my rather narrow knowledge of the issue: I remember years
ago trying to figure out this art/black magic but I gave up in
frustation! Hope you will fare better! If you do, by all means, share
it!
In any case, having hw compression on has only one drawback I know of:
you fool amanda calculations a bit for the estimate phase. But, in my
local environment I typically fit 150% to 200% more than 800GB in one
tape and with runtapes > 1 and the following:
flush-threshold-dumped 100
flush-threshold-scheduled 100
taperflush 100
autoflush yes
I really maximize the amount of data amanda can stuff in the tapes. Of
course, some data will be left in the holddisk overnight, a small risk
I'm willing to take. YMMV.
cheers!
jf
>
>
> [finsen]: /devices > /usr/local/sbin/tapeinfo -f /dev/rmt/3n
> Product Type: Tape Drive
> Vendor ID: 'HP '
> Product ID: 'Ultrium 4-SCSI '
> Revision: 'H5AW'
> Attached Changer API: No
> SerialNumber: 'HU1102EE9V'
> MinBlock: 1
> MaxBlock: 16777215
> Ready: yes
> BufferedMode: yes
> Medium Type: Not Loaded
> Density Code: 0x46
> BlockSize: 0
> DataCompEnabled: yes
> DataCompCapable: yes
> DataDeCompEnabled: yes
> CompType: 0x1
> DeCompType: 0x1
> BOP: yes
> Block Position: 0
> Partition 0 Remaining Kbytes: 800226
> Partition 0 Size in Kbytes: 800226
> ActivePartition: 0
> EarlyWarningSize: 0
> NumPartitions: 0
> MaxPartitions: 0
>
>
>
> >
> > >
> > > thank you,
> > >
> > > Brian
> > >
> > > On Wed, Jan 08, 2014 at 10:57:22AM -0500, Jean-Louis Martineau wrote:
> > > > On 01/08/2014 10:47 AM, Brian Cuttler wrote:
> > > > >Jean-Louis,
> > > > >
> > > > >Good question, especially as I badly misspoke.
> > > > >
> > > > >The tape is not DLT IV, it is LTO IV, I used the standard
> > > > >tape type definition, provided, as I would not have used
> > > > >such a specific number.
> > > > >
> > > > >define tapetype LTO4 {
> > > > > comment "Dell LTO4 800Gb - Compression Off"
> > > > > length 802816 mbytes
> > > > > filemark 0 kbytes
> > > > > speed 52616 kps
> > > > >}
> > > > >
> > > > >I am not using HW compression.
> > > > >I am using "compress client fast" for the dumptypes.
> > > > >All file systems are local to the host, we have a large > 255
> > > > >DLE that are ZFS file systems.
> > > > >
> > > > >That being said - I think you are correct, I am using the
> > > > >wrong tape length.
> > > > >
> > > > >If they are LTO IV tapes, they hold 400 Gig, up to 800 G with
> > > > >HW compression, which we are not using...
> > > > >
> > > > >
> > > > > Q - Would it be correct to reset the tape length to 400 Gig ?
> > > >
> > > > no, you can write at least 603197M on a tape.
> > > >
> > > > Jean-Louis
> > > >
> > > > >
> > > > > thank you/rookie
> > > > > mistake,
> > > > >
> > > > > Brian
> > > > >
> > > > >
> > > > >On Wed, Jan 08, 2014 at 10:06:54AM -0500, Jean-Louis Martineau wrote:
> > > > >>Brian,
> > > > >>
> > > > >>Maybe you defined the tape larger than it is?
> > > > >>Are you sure the tape can hold 800000M of data?
> > > > >>Are you using hardware compression?
> > > > >>
> > > > >>Jean-Louis
> > > > >>
> > > > >>On 01/08/2014 09:13 AM, Brian Cuttler wrote:
> > > > >>>I'm not sure I understand this tape usage... 18% plus 75% < 100%,
> > > > >>>isn't
> > > > >>>it?
> > > > >>>
> > > > >>>Amanda 3.3.0
> > > > >>>Solaris 10x86
> > > > >>>tapes are DLT IV
> > > > >>>
> > > > >>>This, using a second tape, is new behaivor.
> > > > >>>
> > > > >>>I did try a newer amanda but the dump clients wouldn't die when
> > > > >>>they needed two, amanda never completed and required a lot of
> > > > >>>daily manual cleanup. I haven't tried the latest...
> > > > >>>
> > > > >>>
> > > > >>>FAILURE DUMP SUMMARY:
> > > > >>>
> > > > >>> finsen / lev 0 partial taper: No space left on device, splitting
> > > > >>> not
> > > > >>> enabled finsen / lev 0 was successfully re-flushed
> > > > >>>
> > > > >>>USAGE BY TAPE:
> > > > >>> Label Time Size % DLEs Parts
> > > > >>> Finsen32 2:57 603197M 75.1 17 17
> > > > >>> Finsen33 0:48 145593M 18.1 259 259
> > > > >>>
> > > > >---
> > > > > Brian R Cuttler [email protected]
> > > > > Computer Systems Support (v) 518 486-1697
> > > > > Wadsworth Center (f) 518 473-6384
> > > > > NYS Department of Health Help Desk 518 473-0773
> > > > >
> > > >
> > > ---
> > > Brian R Cuttler [email protected]
> > > Computer Systems Support (v) 518 486-1697
> > > Wadsworth Center (f) 518 473-6384
> > > NYS Department of Health Help Desk 518 473-0773
> >
> > --
> > <° >< Jean-François Malouin
> > Systems/Network Manager | McConnell Brain Imaging Centre | MNI
> > 3801 University St, Suite WB219, Montreal, QC, H3A 2B4, Canada
> ---
> Brian R Cuttler [email protected]
> Computer Systems Support (v) 518 486-1697
> Wadsworth Center (f) 518 473-6384
> NYS Department of Health Help Desk 518 473-0773
--
<° >< Jean-François Malouin
Systems/Network Manager | McConnell Brain Imaging Centre | MNI
3801 University St, Suite WB219, Montreal, QC, H3A 2B4, Canada
