[LU-9680] Improve the user land to kernel space interface for lustre Created: 18/Jun/17 Updated: 02/Feb/24 |
|
| Status: | In Progress |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.11.0 |
| Fix Version/s: | Upstream |
| Type: | Improvement | Priority: | Major |
| Reporter: | James A Simmons | Assignee: | James A Simmons |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Lustre currently has a complex assortment of ioctls for both the file system component and the LNet layer. Many of the those ioctls are no longer used or can be replaced with accessing files in the sysfs or debugfs file systems. With the initial review of lustre in the upstream kernel two topics on how ioctls are managed to brought to our attention. One is the dislike of the ioctl redirection that is done in lustre. The seconds is the request that we use the netlink userland API, in particular with the LNet layer. The netlink API could also be used for lustre. |
| Comments |
| Comment by Amir Shehata (Inactive) [ 19/Jun/17 ] |
|
James, we already started working on a project to access module parameters and stats from sysfs. So we should coordinate that effort so we don't over write each other. I attached a requirements document I wrote that outlines what we plan to do for sysfs. Please take a look at it and provide feedback. My opinion is to use that as a starting point to plan out what needs to be done. thoughts? |
| Comment by James A Simmons [ 20/Aug/18 ] |
|
The first candidate for netlink usage has shown up from ticket LU-7659. First it would be good to go over why I'm pushing Lustre to move toward netlink to fill in people like Yohn. The major reason is the data size limitation with ioctls. Some of the data reported by lustre overflows the size limitation such as stats. In the past the way around this was using proc which by using kernel seq_files allowing virtual unlimited size. With the move away from proc we end up in debugfs which only root is suppose to access. Second benefit is for I/O forwarding system which tend not to like ioctls. So the areas I was hoping to tackle with netlink are as follows: 1) LNet seftest (LU-8915) which currently pass in kernel link list which is bad in many ways. 2) lustre stats like md_stats so non-root users can collect stats. 3) Replace the generic lustre ioctl interface we have. (LU-6202) 4) Use it to replace the HSM communication infrastructure. (LU-7659) --------------------------------------------------------------------------------------------------------- In the linux kernel their is only a limited number of core netlink services available. 32 to be exact and 22 have been taken. So lustre would need 2 since LNet is its own separate entity. It would be really hard press to get 2. What the kernel has done to get around this limitation is create a 'generic' netlink service. I would suggest we move to the interface. This way we don't need one netlink server in obdclass as well. |
| Comment by James A Simmons [ 20/Sep/18 ] |
|
Adding LU-7659 since the first implementation of netlink is being done. |
| Comment by Gerrit Updater [ 12/Feb/19 ] |
|
James Simmons (uja.ornl@yahoo.com) uploaded a new patch: https://review.whamcloud.com/34230 |
| Comment by James A Simmons [ 26/Jun/19 ] |
|
Discussing with Amir and Olaf Weber the decision was to present all network collected data in YAML format. With this approach we can actually piece together complex trees. One of things to come out of this is listing obd devices. With YAML output I have currently: devices:
Would anyone want a different format? For me I think replacing index as the first field with the actual device name. |
| Comment by Olaf Weber [ 26/Jun/19 ] |
|
Including the device name makes sense to me. Whether index as a separate field is worth retaining at that point is a different question. It depends on what consumers of this data will want to use it for. |
| Comment by James A Simmons [ 26/Jun/19 ] |
|
That is the beauty of netlink. You can transmit only what you want. This leads me to the idea of creating templates. I was planning on using this concept for stats and you gave me the idea that the template the user provide could take the ordering literally. So the ordering of the template fields that the user asked for can be used to create an YAML output tree in the same exact order. The other idea with this template approach is to also added filters so only under certain conditions will the data set be returned. For example we have the ioctl OBD_IOC_NAME2DEV. Here the filter would be the obd device name and the template would only request the obd index. |
| Comment by Gerrit Updater [ 30/Jun/21 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/34230/ |
| Comment by James A Simmons [ 30/Jun/21 ] |
|
Their is another patch outstanding. |
| Comment by Steve Crusan [ 16/Jul/21 ] |
|
> Would anyone want a different format? For me I think replacing index as the first field with the actual device name. One comment I do have, is that with with YAML (this is a problem with JSON too), is that it would be great if the actual key names were fixed, i.e. 'name', 'index', 'target', etc. Just nothing dynamic! good
devices:
- name: osc.testfs2-OST0000
status: UP
uuid: dog
- name: osc.testfs2-OST0001
status: UP
uuid: cat
bad:
devices:
- osc.testfs2-OST0000:
status: UP
uuid: dog
- osc.testfs2-OST0001:
status: UP
uuid: cat
bad2:
devices:
osc.testfs2-OST0000:
status: UP
uuid: dog
osc.testfs2-OST0001:
status: UP
uuid: cat
it makes it much, much easier to unmarshal this type of data with fixed keys, i.e: https://zhwt.github.io/yaml-to-go/ I've had to deal with this with REST APIs before that had dynamic keys (w/ JSON), and it's sadness. |
| Comment by Gerrit Updater [ 20/Jul/21 ] |
|
James Simmons (jsimmons@infradead.org) uploaded a new patch: https://review.whamcloud.com/44358 |
| Comment by Gerrit Updater [ 21/Nov/21 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/44358/ |
| Comment by James A Simmons [ 21/Nov/21 ] |
|
More work is left. |
| Comment by Gerrit Updater [ 28/Jun/22 ] |
|
"James Simmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/47802 |
| Comment by Gerrit Updater [ 08/Aug/22 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/47802/ |
| Comment by Gerrit Updater [ 10/Oct/22 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/31618/ |
| Comment by James A Simmons [ 10/Oct/22 ] |
|
much more coming |
| Comment by Alex Zhuravlev [ 13/Oct/22 ] |
|
sanity/104d fails constantly on a local setup: == sanity test 104d: runas -u 500 -g 500 lctl dl test ==== 03:25:28 (1665631528) running as uid/gid/euid/egid 500/500/500/500, groups: [/mnt/build/lustre/tests/../utils/lctl] [dl] running as uid/gid/euid/egid 500/500/500/500, groups: [/mnt/build/lustre/tests/../utils/lctl] [dl] sanity test_104d: @@@@@@ FAIL: lctl dl reports wrong number of OST devices possible fix:
@@ -11990,11 +11990,12 @@ test_104d() {
[ "$($RUNAS $LCTL dl | wc -l)" -ge 3 ] ||
error "lctl dl doesn't work for non root"
- ost_count="$($RUNAS $LCTL dl | grep $FSNAME-OST* | wc -l)"
+ ost_count="$($RUNAS $LCTL dl | grep "obdfilter $FSNAME-OST*" | wc -l)"
+ $RUNAS $LCTL dl | grep obdfilter*$FSNAME-OST*
[ "$ost_count" -eq $OSTCOUNT ] ||
error "lctl dl reports wrong number of OST devices"
- mdt_count="$($RUNAS $LCTL dl | grep $FSNAME-MDT* | wc -l)"
+ mdt_count="$($RUNAS $LCTL dl | grep "mdt $FSNAME-MDT*" | wc -l)"
[ "$mdt_count" -eq $MDSCOUNT ] ||
error "lctl dl reports wrong number of MDT devices"
}
|
| Comment by Gerrit Updater [ 10/Nov/22 ] |
|
"Jian Yu <yujian@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49091 |
| Comment by Gerrit Updater [ 10/Dec/22 ] |
|
"James Simmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49361 |
| Comment by Gerrit Updater [ 22/Dec/22 ] |
|
"James Simmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49491 |
| Comment by Gerrit Updater [ 26/Dec/22 ] |
|
"James Simmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49516 |
| Comment by Gerrit Updater [ 26/Jan/23 ] |
|
"Jian Yu <yujian@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49775 |
| Comment by Gerrit Updater [ 27/Jan/23 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49491/ |
| Comment by Alex Zhuravlev [ 27/Jan/23 ] |
|
with LU-9680 utils: new llapi_param_display_value() landed I'm hitting number of failures, especially in sanity-quota. and it seems the patch breaks lctl dl's output: 31 UP mdc lustre-MDT0000-mdc-ffff8d0a1a124000 43e60cbe-0f7e-4f8d-8b45-020bcdd4b297 4 32 UP mdc lustre-MDT0001-mdc-ffff8d0a1a124000 43e60cbe-0f7e-4f8d-8b45-020bcdd4b297 4 33 UP osc lustre 34 UP osc lustre-OST0001-osc-ffff8d0a1a124000 43e60cbe-0f7e-4f8d-8b45-020bcdd4b297 4 notice line 33 UP ... |
| Comment by Gerrit Updater [ 31/Jan/23 ] |
|
"jsimmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/49839 |
| Comment by Gerrit Updater [ 16/Feb/23 ] |
|
"jsimmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/50026 |
| Comment by Gerrit Updater [ 08/Mar/23 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49091/ |
| Comment by Gerrit Updater [ 28/Mar/23 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/50026/ |
| Comment by Gerrit Updater [ 31/May/23 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49839/ |
| Comment by Gerrit Updater [ 29/Jun/23 ] |
|
"James Simmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/51508 |
| Comment by Gerrit Updater [ 19/Jul/23 ] |
|
"James Simmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/51715 |
| Comment by Gerrit Updater [ 01/Aug/23 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/51508/ |
| Comment by Gerrit Updater [ 01/Aug/23 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/51715/ |
| Comment by Gerrit Updater [ 25/Oct/23 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/49516/ |
| Comment by Gerrit Updater [ 06/Nov/23 ] |
|
"James Simmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/53004 |
| Comment by Gerrit Updater [ 07/Dec/23 ] |
|
"Chris Horn <chris.horn@hpe.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/53366 |
| Comment by Gerrit Updater [ 03/Jan/24 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/53366/ |
| Comment by Gerrit Updater [ 18/Jan/24 ] |
|
"Chris Horn <chris.horn@hpe.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/53731 |
| Comment by Gerrit Updater [ 18/Jan/24 ] |
|
"Chris Horn <chris.horn@hpe.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/53732 |
| Comment by Gerrit Updater [ 18/Jan/24 ] |
|
"Chris Horn <chris.horn@hpe.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/53733 |
| Comment by Gerrit Updater [ 18/Jan/24 ] |
|
"Chris Horn <chris.horn@hpe.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/53734 |
| Comment by Gerrit Updater [ 02/Feb/24 ] |
|
"James Simmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/53889 |