Forwarding info on a GTAR failure.
Best Regards
David W. Allen
Principal Staff Applications Engineer
Engineering Systems Continental AG
21440 W. Lake Cook Rd.
Deer Park, IL 60010, USA.
Voice # 847-862-0184
Fax # 847-862-8244
Email: [EMAIL PROTECTED],[EMAIL PROTECTED]
ES Web Site: http://es.iess.mot.com/es_pages/index.shtml
________________________________
From: Allen David-G12112
Sent: Thursday, December 14, 2006 6:43 PM
To: Allen David-G12112; Do Tinh-G99000; Splattstoesser Kevin-g19015
Cc: Omaraie Farzad-G13402; Li Ned-G19974; Liu Li-g26854; Allen
David-G12112; Ghani Asif-G14561; Lian Rui-g26855; Macnak David-GUSR310;
Oswald Mike-G10476; Raini Haribabu-G17452; Wang Kitty-G20140; Low
Douglas-ADL305; Collier Paul-G18889
Subject: RE: Report on GTAR failure in Munich
Forgot Paul and Doug in Munich when doing the CC's
This is a text file and best viewed with WORDPAD and not NOTEPAD.
Best Regards
David W. Allen
Principal Staff Applications Engineer
Engineering Systems Continental AG
21440 W. Lake Cook Rd.
Deer Park, IL 60010, USA.
Voice # 847-862-0184
Fax # 847-862-8244
Email: [EMAIL PROTECTED],[EMAIL PROTECTED]
ES Web Site: http://es.iess.mot.com/es_pages/index.shtml
________________________________
From: Allen David-G12112
Sent: Thursday, December 14, 2006 6:29 PM
To: Do Tinh-G99000; Splattstoesser Kevin-g19015
Cc: Omaraie Farzad-G13402; Li Ned-G19974; Liu Li-g26854; Allen
David-G12112; Ghani Asif-G14561; Lian Rui-g26855; Macnak David-GUSR310;
Oswald Mike-G10476; Raini Haribabu-G17452; Wang Kitty-G20140
Subject: Report on GTAR failure in Munich
Here is the report in a gtar failure in Munich in a release transfer of
gui.tar.gz
The Untar command
ksh> gtar -xf gtar.tar
gave two bad links in one directory that caused a problem.
See details in the attached report.
Report is a TEXT file so please view with WORDPAD and not the obsolete
NOTEPAD.
Best Regards
David W. Allen
Principal Staff Applications Engineer
Engineering Systems Continental AG
21440 W. Lake Cook Rd.
Deer Park, IL 60010, USA.
Voice # 847-862-0184
Fax # 847-862-8244
Email: [EMAIL PROTECTED],[EMAIL PROTECTED]
ES Web Site: http://es.iess.mot.com/es_pages/index.shtml
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
REPORT ON GTAR FAILURE
Author: Dave Allen Date: Dec 14,2006
RELEASE PROBLEM DUE TO GTAR FAILURE:
Recently there was a problem doing an UPDATE release to Munich because the
untar in Munich using GTAR generated two bad links.
It is wise for any sys-admins and/or support developers to know this.
I will try to look for info on Google about gtar failures and I would
appreciate any help from sys-admins if you have heard of problems with
tar or gtar before.
If there is some one the sys-admins know to contact that would be good also.
Some facts about our use of tar/gtar:
1) All cron jobs doing the nightly Mentor library transfers to Munich and
Shanghai, (6 nights a week), use tar and gzip on the HP server bu980a0
In addition to the nightly transfers for current library there is a
once-a-week transfer for the older rlslib_C2.
I know of only one suspected failure with this over 7 years or so, for
transfers to Elk Grove/Munich, and no known failures for the time it
has been used for Shanghai.
2) The design-transfers (design_xfer) between sites uses GTAR and gzip.
Most designs now will have only 10-50 links perhaps under the design_geom
and these are supposed to be purged or go away with time.. There is
generally one other link under design_maps.
I know of no recorded failure due to an untar.
3) Another note about current operation would be that Tinh Do and
I worked, (together with Terry Lian), to get an updated gtar in Deerpark
and Shanghai so as to allow tar files greater than 2 gig.
All three sites now show a version of gtar of 1.15.1
4) I have saved the BAD copy of the gui directory in Munich at
/apps/elec/mentor/gui_BAD_links
and the two bad links are under the sub-directory at
/apps/elec/mentor/gui_BAD_links/batch
The possibly-bad tar file is at
/apps/elec/mentor/d_untar/gui.tar_gave_bad_links
It could have been a system glitch as I cant reproduce.
See more details below.
5) The same exact gui.tar.gz file sent to Shanghai caused no such
problem, and when I repeat the untar in Munich I do not get those
two bad links.
The exact command I always use for an untar is:
KSH> gunzip gui.tar.gz
followed by
KSH> gtar -xf gui.tar
6) The five extra characters added to the links were 'ustar'. Is it
possible this means us-tar (or US-tar) and refers to localization??
Wild guess..
7) SUN version in Munich on server zwg18srv01
zwg18srv01> uname -a
SunOS zwg18srv01 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Fire-V440
gtar version is 1.15.1
UNTAR USING GTAR MADE TWO BAD LINKS:
## Doing an untar for a critical directory transferred to Munich resulted
## in two bad links under the /apps/elec/mentor/gui/batch directory.
## These caused Doug Low's problem with the Conti border update for
## the drawings in a fablink session.
## I am going to CC sys-admins at all three SITES on this.
## Does any sys-admin with your vast knowledge and experience with
## any Unix anomalies know or have heard of gtar failures?
## If you cant TRUST a gtar - then how can someone reliably do backups??
## Perhaps commercial backup systems dont trust tar and do by other means..
## I can remember Farzad Omaraie warning about tar/gtar in a group
## discussion on backup strategies in Northbrook a long time ago.
## The Munich site were unlucky enough that out of 400 or so files
## and links under just one sub-directory mentor/gui there were two bad
## bad links that appeared out of the untar.
## This represents the first case of a tar.gz failure that I have
## seen in about five years or so.
## The /apps/elec/mentor/gui/batch
## - is quite large
## - has many LONG links that point to about 70% of the scripts and
## perl and binaries/exe's that we use..
## This directory wound up with at least TWO bad links that I can see
## after I did gunzip and gtar -xf
## on the gui.tar.gz that I ftp'd from Deerpark to Munich.
## I know many years ago Unix tar had problems with LONG LINKS.
## I am VERY disappointed to see this in a GTAR especially after I and
## the sys-admin Tinh Do here spent time to actually upgrade the gtar on
## our SUN server il106ee1.. to bring it in line with the gtar at
## Munich and Shanghai.
INFO THAT I FOUND:
## On Deerpark SUN server..
il106ee1> uname -a
SunOS il106ee1 5.8 Generic_117350-29 sun4u sparc SUNW,Sun-Fire-480R
il106ee1> gtar --version
tar (GNU tar) 1.15.1
## On Munich SUN server..
zwg18srv01> uname -a
SunOS zwg18srv01 5.9 Generic_112233-12 sun4u sparc SUNW,Sun-Fire-V440
zwg18srv01> gtar --version
tar (GNU tar) 1.15.1
## There are TWO links under the gui/batch directory that wuold up with
## some extra characters at the end of the path.
zwg18srv01> pwd
/apps/elec/mentor/gui/batch
zwg18srv01> ls -dl * | grep star
### TWO BAD LINKS HERE. NOT_AT Deerpark and NOT_IN Shanghai which got same
gui.tar.gz as Munich
lrwxrwxrwx 1 g12112 users 107 Dec 11 03:09
do_lsxlR_for_veritas_restore.prl
->
/apps/elec/mentor/idea.common/d_tools/d_pcb_tools/d_veritas_restore/do_lsxlR_for_veritas_restore.prlustar
lrwxrwxrwx 1 g12112 users 107 Dec 11 03:09
do_upd_formats_conti_in_design.ksh
->
/apps/elec/mentor/idea.common/d_tools/d_pcb_utils/d_CONTI_updates/do_upd_formats_conti_in_design.kshustar
### Other links are fine.
lrwxrwxrwx 1 g12112 users 67 Dec 11 03:09 start_ee_cron_jobs
-> /apps/elec/mentor/idea.common/d_tools/d_cron/start_ee_cron_jobs.ksh
zwg18srv01>
Regards,
Dave Allen
Mentor Support
