If you're running TSM to backup/restore data on Novell OES (NSS file systems, specifically), and you're using the "directory quota" feature of NSS, you should have a look at the following.
On NSS file systems, it is possible to set directory quotas such that the quota setting is LOWER than the amount of data stored within that directory. The resulting directory is "over quota". The TSM client will happily backup those directories, but it can't restore them, at least not completely. Together with TSM support, we determined that the client restores the quota setting on the base directory first, and then tries to restore the data (files, subdirs) that was stored there. That, of course, fails, because there is more to be restored than the quota setting permits. As a result, you get ANS4009E "filesystem full condition", even though the file system as such is not full. Even worse, the client stops and asks for user intervention. For every single file to be restored to that directory after it has hit its quota limit... potentially hundreds, thousands, or even millions of times. After many tries, TSM support found a workaround for the problem: First, restore just the files. Second, restore the directories (including the rights and quotas). Third, restore the base directory (including its rights and quotas). At that point, TSM support told me that the problem was solved now, the client "works as designed" and I should submit an RFE if I wanted more. Huh. Are you serious? The client is unable to restore the file system to exactly the state it was in when the backup was performed, and that's called "works as designed"? So, if you're in a similar situation (Novell OES, NSS, dir quotas) you know about the workaround, and you should perhaps have a look at my RFE (vote, please!): http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=33567 -- Jürgen Weinelt Rechenzentrum der Universität Würzburg
