RE: TAPEDEV or -t STDIO?

Got it! Thanks to all for your replies. Brian _____ From: Art Kagel [mailto:art.kagel@gmail.com] Sent: Friday, August 13, 2010 4:47 PM To: Brian Amstutz Cc: informix-list@iiug.org Subject: Re: TAPEDEV or -t STDIO? Overrides, not replaces in memory. Ontape and the engine do NOT know that the shell has redirected STDIO to /dev/null (yes, ontape COULD stat the file stdout and discover that it is connected to a device special file but tape drives and RAW disks are also device special files), so then ontape is behaving exactly like it was backing up to a "real" file and performs an actual backup. Backups using TAPEDEV, whether it is set to a filename path or to a directory name path will take the same time and MAY be slightly faster than backing up to a file using STDIO, but only very slightly. All in all, once the shell redirects stdout to a file, the actual IO is exactly like writing to any other file. The application saves the overhead of opening the file, but then the shell will have had the same overhead so that's a wash. The 'driver' for the C/UNIX special file handling within the C library has some small overhead, but it is very small and you won't be able to distinguish it from random speed differences between any two runs in general. The ONLY reason the two runs you tested were so different was that TAPEDEV set to /dev/null is handled differently, as has alrady been pointed out. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Aug 13, 2010 at 4:32 PM, Brian Amstutz <brian.amstutz@asburyseminary.edu> wrote: I understand that /dev/null bypasses the backup and doesn't actually perform any archive at all, but the manual also says that: "The -t STDIO option overrides the value of the TAPEDEV configuration parameter for the current backup." http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com. ibm.bar.doc/barmst282.htm ** BTW this link is for v10 (as specified in my original post), not v115 ** So, if using -t STDIO causes the server to OVERRIDE the value of TAPEDEV and I'm using -t STDIO > /dev/null, shouldn't either method, theoretically, do the same thing and perform the same way? However, my question still remains (aside from /dev/null) - when using ontape to perform a backup to a file, is there any difference (specifically performance-wise) between specifying the filename in TAPEDEV and using -t STDIO filename? Thanks! Brian >-----Original Message----- >From: Clive Eisen [mailto:clive@serendipita.com] >Sent: Friday, August 13, 2010 11:39 AM >To: Brian Amstutz; informix-list@iiug.org >Subject: Re: TAPEDEV or -t STDIO? > >On 13/08/2010 16:16, Brian Amstutz wrote: >> HP-UX 11i v2 >> Informix 10.00.FC9 >> >> ontape -s -L 0 with TAPEDEV set to /dev/null takes 2 seconds or less >> ontape -s -L 0 -t STDIO> /dev/null still running after 30 minutes>> >> Besides the question of "why" is it so much longer when using -t STDIO, my >> real question is if this archive were to a "real" file (instead of >> /dev/null), would the time difference be significantly longer as well - >> i.e. would using -t STDIO> <somefile> take significantly longer than >> setting TAPEDEV to<somefile>? > >er RTFM? > >http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/com.ibm.bar.d <http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/com.ibm.bar.d %0Aoc/ids_bar_455> oc/ids_bar_455 >.htm > >specifically > >When you set TAPEDEV to /dev/null and request a backup, the database >server bypasses the backup but still updates the dbspaces with the new >backup time stamps. > >-- >Clive > >-- >This message has been scanned for viruses and >dangerous content by OpenProtect(http://www.openprotect.com), and is >believed to be clean. _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list