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