Re: ontape vs onbar: Changing NSR device block size

Neil, in addition to Martin's suggestion I would like to suggest an action plan for one specific tape device. The 'NSR device' parameter 'volume block size' is not displayed per default when running command 'print NSR device'. This is actually a hidden parameter, however, you will be able to set a value for this parameter. See below. For example: You want to update the volume block size of tape device '/dev/rmt0.1' from value <unknown> to <1024 KB>. To update one specific NSR device and leave others as they are the following NSR commands are needed. - Start 'nsradmin [-s localhost]' to get the NSR server interactive mode - Run the NSR command 'update type: NSR device; name: /dev/rmt0.1; volume block size: 1024 KB' -> The parameters will be displayed and you will be asked for 'Update?' - Answer 'y' -> The message 'updated resource id <number blabla>' will be displayed HTH Robert Robert Seifert _________________________________________________________________ IBM Deutschland GmbH, Software, Information Management Solutions Elite VAR support engineer Development Support for IBM Informix Products on-site @ SAP c/o SAP AG, -TechDev05-,Neurottstrasse 16, D-69190 Walldorf, Germany owner-informix-list@iiug.org wrote on 18.08.2005 12:03:09: > Hi, > > I/O block size for write operations indeed cannot be configured > in ON-Bar. This is mainly because ON-Bar doesn't do the I/O > write operations. The storage manager is doing them, therefore > you need to configure blocksize there. > > With ISM as storage manager try the following: > > - as user root execute "nsradmin" > - nsradmin> print NSR device > - nsradmin> update volume block size: 1024 KB > -- this will ask you several times (once for each device ?) > -- whether you want to update the value. > -- answer with "y" or "n" as appropriate ... > - nsradmin> quit > -- to leave nsradmin utility > > All this is a bit cryptic, but it seems to work (at least it changes > the configured values for the device(s)). > > Regards, > Martin > -- > Martin Fuerderer > IBM Informix Development Munich, Germany > Information Management > > owner-informix-list@iiug.org wrote on 17.08.2005 15:11:51: > > "Martin Fuerderer" <MARTINFU@de.ibm.com> wrote in message > > news:1124275387.367f6e33d3f4593be9c8290f7a8a7071@teranews... > > > > > > Hi, > > > > > > if you want to get to the bottom of this I think it is time to > analyse, > > > where the bottleneck is. Ontape is rather simple, writing directly to > > > a (usually local) tape. > > > > > > ON-Bar involves several components and you should look at each > > > of these and the communication between them. You can start with > > > the ON-Bar activity log file to check if there is a certain "phase" in > > > the backup that takes longer than expected. You can also > > > check/compare to the respective lines in IDS message log. You > > > may also want to look into ISM log files, but you may find that > > > messages there do not exactly (time-) match with messages from > > > ON-Bar. > > > > It just starts off slowly, and consistently writes out slowly, compared > on > > ontape. There's no particular phase in which it's slow, the throughput > is > > just consistently a quarter the speed on ontape's. > > > > I should stress again here that both ontape and onbar are writing to > *disk* > > in this comparison. > > > > If onbar is inherently slower, then it's slower. I'd just never noticed > it > > as being so before and am very surprised. > > > > As I say. my hunch is still that it's all down to being able to > configure > > TAPEBLK in ontape, but not onbar ... > > sending to informix-list sending to informix-list