>> On Tue, 29 Jan 2008 12:57:30 +0200, Michael Green <[EMAIL PROTECTED]> said:
> Bright minds, > Some time ago a problem has arisen with one of the GPFS file systems > that I happen to backup. > Basically what happens is that the backup of that particular file > system never completes, cuts short with return code 12. > 01/29/08 02:29:28 Normal File--> 684,135,874 > /srv/databases/unigeneU/Hs.retired.lst [Sent] > 01/29/08 02:29:28 ANS1999E Incremental processing of '/srv' stopped. > 01/29/08 02:29:28 --- SCHEDULEREC STATUS BEGIN Is there an errorlog entry at "about" that time? It could be offset by as much as a few minutes. I have seen a variety of situations I group under "insane metadata" which cause TSM to throw up its' hands on a given filesystem. Examples include negative MTIME, MTIME >MAXINT, (a badly behaved alternate fileystem mount on a NETAPP) Corrupt regions of the directory INODE (we think those are SAN-blip corruption), etc. Often there's a particular error in the errorlog, and if you go ls -l around in the place where it failed you find something which is odd. Sorry to have nothing more specific than "odd", that's as precisely as I can group the cases I've seen. - Allen S. Rout