From 993d05a42e9556efed104e7471f3df3883b7089e Mon Sep 17 00:00:00 2001 From: Jason Zhang <zhanghj.lc@inspur.com> Date: Tue, 22 Nov 2022 14:25:57 +0800 Subject: [PATCH] docs: change mount-info.json to mountInfo.json mount-info.json should be mountInfo.json according to the description in the doc. Fixes: #5716 Signed-off-by: Jason Zhang <zhanghj.lc@inspur.com> --- docs/design/direct-blk-device-assignment.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/design/direct-blk-device-assignment.md b/docs/design/direct-blk-device-assignment.md index 9997d0e7a6..0703140f16 100644 --- a/docs/design/direct-blk-device-assignment.md +++ b/docs/design/direct-blk-device-assignment.md @@ -81,7 +81,7 @@ Notes: given that the `mountInfo` is persisted to the disk by the Kata runtime, Instead of the CSI node driver writing the mount info into a `csiPlugin.json` file under the volume root, as described in the original proposal, here we propose that the CSI node driver passes the mount information to the Kata Containers runtime through a new `kata-runtime` commandline command. The `kata-runtime` then writes the mount -information to a `mount-info.json` file in a predefined location (`/run/kata-containers/shared/direct-volumes/[volume_path]/`). +information to a `mountInfo.json` file in a predefined location (`/run/kata-containers/shared/direct-volumes/[volume_path]/`). When the Kata Containers runtime starts a container, it verifies whether a volume mount is a direct-assigned volume by checking whether there is a `mountInfo` file under the computed Kata `direct-volumes` directory. If it is, the runtime parses the `mountInfo` file,