[LU-11743] lctl pool operations cannot be run on separate MGS system Created: 09/Dec/18 Updated: 24/Mar/22 Resolved: 28/Sep/19 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.12.0, Lustre 2.10.5 |
| Fix Version/s: | Lustre 2.13.0, Lustre 2.12.3, Lustre 2.12.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Andreas Dilger | Assignee: | Emoly Liu |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| Severity: | 3 | ||||||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||||||
| Description |
|
The "lctl pool_new", "lctl pool_add", and related commands cannot properly be run on a system where the the MGS is separate from the MDS. The pool commands must be run on the MGS in order to modify the configuration, but the pool configuration is not instantiated on the MGS so it does not have corresponding /proc/fs/lustre/lov/*/pool/ files that lctl uses to verify whether the pool and OSTs exist or not. Rather than using the /proc or /sys file existence to verify the pool commands on the MGS, it would be possible to instead parse the filesystem configuration directly from the YAML filesystem configuration output of "lctl llog_print <fsname>-client". This would also avoid the need for lctl to wait for the pool files to appear in /proc after the command is run, which can often take a few seconds. |
| Comments |
| Comment by Andreas Dilger [ 10/Dec/18 ] |
|
As a workaround until lctl is fixed, it is possible to mount a client on the MGS node temporarily while the "lctl pool_*" commands are run, so that it can verify the filesystem-specific configuration. The client should be unmounted when it is no longer needed. |
| Comment by Gerrit Updater [ 25/Jan/19 ] |
|
Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/34110 |
| Comment by Andreas Dilger [ 13/Jul/19 ] |
|
The second patch needs to register a callback to iterate over the records in the client configuration llog to find the pool or OSTs being added or removed. This should be wrapped in a common function that can be used with either the local llog operator or with the client /proc traversal so that it works consistently with either interface. |
| Comment by Emoly Liu [ 18/Jul/19 ] |
|
The code is almost done. Once it passes my local ost-pool.sh test, I will upload it to the Gerrit. My implementation is to read the llog records from the last index, match the pool command keywords in the callback function to see if the pool and OSTs exist, and keep the return value consistent with lapi_search_ost() interface. |
| Comment by Gerrit Updater [ 15/Aug/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/34110/ |
| Comment by Peter Jones [ 15/Aug/19 ] |
|
Landed for 2.13 |
| Comment by Gerrit Updater [ 15/Aug/19 ] |
|
Minh Diep (mdiep@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/35804 |
| Comment by Gerrit Updater [ 23/Aug/19 ] |
|
Emoly Liu (emoly@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/35895 |
| Comment by Andreas Dilger [ 09/Sep/19 ] |
|
Still one patch to land. |
| Comment by Gerrit Updater [ 27/Sep/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/35895/ |
| Comment by Peter Jones [ 28/Sep/19 ] |
|
Everything landed now |
| Comment by Gerrit Updater [ 28/Sep/19 ] |
|
Minh Diep (mdiep@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36314 |
| Comment by Gerrit Updater [ 04/Oct/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/35804/ |
| Comment by Gerrit Updater [ 21/Nov/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36314/ |