Directions on Draining then Removing a Pool

Set pool readonly. Can start drain right away, but will likely miss a few files

ssh to admin domain

\c PoolManager
\c <the pool, eg, umfs03_4>
migration move -target=pgroup -exclude=umfs03_4 -concurrency=10 aglt2UMPools
migration info <id of move>

An alternative is to designate a particular set of pools to receive files from those being drained

\c PoolManager
\c umfs16_1
migration move -concurrency=10 -target=pgroup -include=umfs11_7,umfs11_8,umfs11_9,umfs11_10,umfs11_11,umfs11_12 aglt2UMPools
# Repeat for other pools being drained with these same targets

When complete, look 2 places

• ls -l /dcache3/pool/data

and in the pool itself above

• rep ls

Make sure that no files show up

When empty, do these things:

• update poolmanager.conf in cf3 and run cf-agent on head01
• in the PoolManager do "reload -yes"
• On the pool machine, "dcache stop umfs03Domain_4"
• umount /dcache3
• rmdir /dcache3
• Remove mount from /etc/fstab
• omconfig storage vdisk action=deletevdisk controller=0 vdisk=0
• cf-agent -Kf failsafe.cf; cf-agent -K

Potential problems

It may happen that some files will not migrate, and these would then show up in the "rep ls -l" and "ls" commands above. Also, in the "migration info" command you might see
09:16:10 [95816] 00007F4EF1A49A474311A98BFF58877D657D: PnfsManager failed (path [00007F4EF1A49A474311A98BFF58877D657D] does not exist)
"rep ls -l" shows info about these, for example
00005C8696FB9AF6410596E15B2FC9785A95 <C-------X--L(0)[0]> 635523828 si={usatlas:aglt2}
The output of this command can be interpreted using this web page. In this instance, the file is a "locked", cached, and pinned file, but with an open count of zero and a lock-time of zero. Such files can be deleted from within the cell itself (as above, from where the migration command was run) using "rep rm -force <pnfsid>". Once this is done, for all remaining files, the storage will be empty and the final steps can then be followed.

-- BobBall - 12 Jan 2017