This problem occurs when FTP clients which do not send an ALLO command are used. When this happens, the file size cannot be determined ahead of time by the PFTP Daemon, so the class of service selection algorithm chooses one which will contain very large files, so as to guarantee that the transfer will not be aborted due to exceeding the maximum size allowed for a COS.
However, the allocation chunk size used for files in the large-file categories is also very large (128 MB); this chunk size is reserved even if a single byte is written to the file. In addition, the "change class of service" HPSS function [which is issued by the PFTP daemon when the transfer completes and the file size is known] copies the file to the device at the lowest level of the destination hierarchy - in our case this is 3590 tape. Since very small files can be written to HPSS at a much faster rate than they can be copied to tape and each file takes a mimimum of 128 MB, the large file disk cache can be used up very quickly, resulting in error -28 (ENOSPACE).
We are currently trying to work around this problem while the HPSS developers design a permanent fix. For the interim period, we have switched the "temporary" class of service selection algorithm so it will choose the "medium file" COS, which has the largest amount of disk cache allocated, and we have temporarily disabled enforcement of maximum file size for this COS.
You can also force selection of the class of service by using the "quote site setcos"
command before sending files,e.g.:
quote site setcos 1
will select the small-file class of service.
See the Frequently Asked Questions document for a
current list of HPSS Classes of Service.