Re: ontape vs onbar

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