On Wed, Jan 08, 2014 at 11:18:46AM -0500, Jean-Francois Malouin wrote:
> * Brian Cuttler <br...@wadsworth.org> [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?


[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                 brian.cutt...@wadsworth.org
> > > >    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                 brian.cutt...@wadsworth.org
> >    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                 brian.cutt...@wadsworth.org
   Computer Systems Support        (v) 518 486-1697
   Wadsworth Center                (f) 518 473-6384
   NYS Department of Health        Help Desk 518 473-0773

Reply via email to