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,