Use the PoolMgrSelectWritePoolMsg to get a pool which matches the attraction scheme and provides (for now) the best cost. The PoolMgrSelectWritePoolMsg needs to have the StorageInfo which should be obtained by a PnfsGetStorageInfoMessage and the ProtocolInfo which should be the IpProtocolInfo to provide the hostname (IpNumber) from which the file will be requested later on. I guess SRM should know. It would be fair, but not essential to provide the filesize as well.
Requesting space is done by using the PoolReserveSpaceMessage, specifying the numbers of bytes to allocate. On return the request will either report success of failure.PoolReserveSpaceMessage reserve = new PoolReserveSpaceMessage( poolname , space ) ; CellMessage msg = new CellMessage( new CellPath(poolName) , reserve ) ; msg = sendAndWait( msg , 30000L ) ; if( msg == null ) ... timeout ... reserve = (PoolReserveSpaceMessage)msg.getMessageObject() ; if( reserve.getReturnCode() != 0 ) .... error .... long totallyReservedSpaceByThisPool = reserve.getReservedSpace() ;
Io Requests (Write), intending to use preallocated space, have to specify the maximum amount within the StorageInfo of the PoolAcceptFileMessage. Use the setKey mechnism to set the use-preallocated-space key to whatever is requested. The value is expected to be a String containing the amount in bytes.
After the preallocated space has been used, the pool will fall back to its standard mechnism to allocate space as long as needed.long filesize = ... storageInfo.setKey( "use-preallocated-space" , ""+filesize ) ; PoolAcceptFileMessage msg = new PoolAcceptFileMessage( poolName , pnfsId , protocolInfo , storageInfo ) ;
Similar but independed of the Preallocation Mechanism a maximum number of bytes can be specified which the mover is allowed to store within the selected pool. The StorageInfo key is use-max-space.long maxfilesize = ... storageInfo.setKey( "use-max-space" , ""+maxfilesize ) ; PoolAcceptFileMessage msg = new PoolAcceptFileMessage( poolName , pnfsId , protocolInfo , storageInfo ) ;Though this mechanism is prepared, the PreallocationSpaceMonitor doesn't honour this parameter yet.
In case preallocated space is not going to be used, it may be freed by a PoolFreeSpaceReservationMessage. Freeing more space than allocated in total, will result in an error and no space is freed at all.PoolSpaceReservationMessage freeSpace = new PoolFreeSpaceReservationMessage( poolname , spaceToFree ) ; CellMessage msg = new CellMessage( new CellPath(poolName) , freeSpace ) ; msg = sendAndWait( msg , 30000L ) ; if( msg == null ) ... timeout ... freeSpace = (PoolSpaceReservationMessage)msg.getMessageObject() ; if( freeSpace.getReturnCode() != 0 ) .... error .... long restOfReservedSpaceByThisPool = freeSpace.getReservedSpace() ;
At any time, a pool can be queried for the total number of reserved bytes by the PoolQuerySpaceReservationMessage.PoolSpaceReservationMessage query = new PoolQuerySpaceReservationMessage( poolname ) ; CellMessage msg = new CellMessage( new CellPath(poolName) , query ) ; msg = sendAndWait( msg , 30000L ) ; if( msg == null ) ... timeout ... query = (PoolSpaceReservationMessage)msg.getMessageObject() ; if( query.getReturnCode() != 0 ) .... error .... long restOfReservedSpaceByThisPool = query.getReservedSpace() ;
The space reservation module (sr) within the repository module of the Pool allows some manipulation of reserved space for debugging purposes.
- rep sr ls reports the total number of reserved bytes for this pool. The generic pool 'info' command as well reports this number.
- rep sr reserve <BytesToReserve> reserves the specified number of bytes.
- rep sr free <BytesToFree> frees the specified number of bytes from the reservation pool
- rep sr apply <BytesToApply> converts the specified number of bytes from the reservation pool into the 'used' pool. This is for debugging purposes only. It will confuse the pool if used during regular pool operation.
All reserve space operations are persistent. The number of reserved bytes will stay with the pool even after a pool restart.