docs: fix markdown linting issues

- Capitalize 'Mount Pod' and 'Mount Pods' consistently per enhanced-proper-names rule
- Fix all occurrences in daemonset-mount.md and mount-pod-configuration.md
- Comply with .markdownlint-cli2.jsonc configuration

Author: elijah-rou

.markdownlint-cli2.jsonc

@@ -47,6 +47,7 @@
     },
     "link-fragments": false,
     "no-trailing-slash-in-links": true,
+    "MD029": false,
     "enhanced-proper-names": {
       "code_blocks": false,
       "html_elements": false,

docs/en/guide/daemonset-mount.md

@@ -1,22 +1,22 @@
 # DaemonSet Mount for StorageClass
 
-This feature allows JuiceFS CSI Driver to deploy mount pods as DaemonSets instead of individual pods when using StorageClass with mount sharing enabled. This provides better resource management and control over which nodes run mount pods.
+This feature allows JuiceFS CSI Driver to deploy Mount Pods as DaemonSets instead of individual Pods when using StorageClass with mount sharing enabled. This provides better resource management and control over which nodes run Mount Pods.
 
 ## Overview
 
-When `STORAGE_CLASS_SHARE_MOUNT` is enabled, JuiceFS CSI Driver shares mount pods across multiple PVCs that use the same StorageClass. By default, these are created as individual pods. With the DaemonSet option, mount pods are deployed as DaemonSets, providing:
+When `STORAGE_CLASS_SHARE_MOUNT` is enabled, JuiceFS CSI Driver shares Mount Pods across multiple PVCs that use the same StorageClass. By default, these are created as individual Pods. With the DaemonSet option, Mount Pods are deployed as DaemonSets, providing:
 
-- **Better resource control**: DaemonSets ensure one mount pod per selected node
-- **Node affinity support**: Control which nodes run mount pods using nodeAffinity
-- **Automatic lifecycle management**: DaemonSets handle pod creation/deletion automatically
-- **Simplified operations**: Easier to manage and monitor mount pods
+- **Better resource control**: DaemonSets ensure one Mount Pod per selected node
+- **Node affinity support**: Control which nodes run Mount Pods using nodeAffinity
+- **Automatic lifecycle management**: DaemonSets handle Pod creation/deletion automatically
+- **Simplified operations**: Easier to manage and monitor Mount Pods
 - **Works with existing StorageClasses**: No need to modify or recreate StorageClasses
 
 ## Configuration
 
 ### Enable DaemonSet Mount
 
-To enable DaemonSet mount for StorageClass, set these environment variables in the CSI driver deployment:
+To enable DaemonSet mount for StorageClass, set these environment variables in the CSI Driver deployment:
 
 ```yaml
 env:
@@ -28,7 +28,7 @@ env:
 
 ### Configure Node Affinity
 
-There are two ways to configure node affinity for DaemonSet mount pods:
+There are two ways to configure node affinity for DaemonSet Mount Pods:
 
 #### Method 1: ConfigMap (Recommended for existing StorageClasses)
 
@@ -77,7 +77,7 @@ provisioner: csi.juicefs.com
 parameters:
   # ... other parameters ...
   
-  # Node affinity configuration for DaemonSet mount pods
+  # Node affinity configuration for DaemonSet Mount Pods
   nodeAffinity: |
     requiredDuringSchedulingIgnoredDuringExecution:
       nodeSelectorTerms:
@@ -91,14 +91,14 @@ parameters:
 ## How It Works
 
 1. When a PVC is created using a StorageClass with DaemonSet mount enabled:
-   - The CSI driver checks if a DaemonSet for this StorageClass already exists
+   - The CSI Driver checks if a DaemonSet for this StorageClass already exists
    - If not, it looks for node affinity configuration:
      - First checks the ConfigMap for StorageClass-specific or default configuration
      - Falls back to StorageClass parameters if specified
    - Creates a new DaemonSet with the configured node affinity
    - If DaemonSet exists, it adds a reference to the existing DaemonSet
 
-2. The DaemonSet ensures mount pods are running on selected nodes:
+2. The DaemonSet ensures Mount Pods are running on selected nodes:
    - Pods are automatically created on nodes matching the affinity rules
    - Mount paths are shared across PVCs using the same StorageClass
 
@@ -109,6 +109,7 @@ parameters:
 ## Priority Order
 
 The system checks for node affinity configuration in this order:
+
 1. **StorageClass parameters** (if `nodeAffinity` is specified)
 2. **ConfigMap with StorageClass name** as key
 3. **ConfigMap default** configuration
@@ -118,7 +119,7 @@ The system checks for node affinity configuration in this order:
 
 ### Dedicated Mount Nodes
 
-Label specific nodes for running mount pods:
+Label specific nodes for running Mount Pods:
 
 ```bash
 kubectl label nodes node1 node2 node3 juicefs/mount-node=true
@@ -128,7 +129,7 @@ Then use nodeAffinity in StorageClass to target these nodes.
 
 ### High-Performance Nodes
 
-Prefer nodes with better resources for mount pods:
+Prefer nodes with better resources for Mount Pods:
 
 ```yaml
 nodeAffinity: |
@@ -145,7 +146,7 @@ nodeAffinity: |
 
 ### Exclude Control Plane
 
-Prevent mount pods from running on control plane nodes:
+Prevent Mount Pods from running on control plane nodes:
 
 ```yaml
 nodeAffinity: |
@@ -158,7 +159,7 @@ nodeAffinity: |
 
 ## Monitoring
 
-You can monitor DaemonSet mount pods using standard Kubernetes commands:
+You can monitor DaemonSet Mount Pods using standard Kubernetes commands:
 
 ```bash
 # List all mount DaemonSets
@@ -179,24 +180,24 @@ kubectl get pods -n kube-system -l juicefs.com/mount-by=juicefs-csi-driver
 
 ## Migration
 
-To migrate from pod-based mounts to DaemonSet mounts:
+To migrate from Pod-based mounts to DaemonSet mounts:
 
-1. Enable the feature flags in CSI driver
+1. Enable the feature flags in CSI Driver
 2. Create a new StorageClass with desired node affinity
 3. Migrate PVCs to the new StorageClass
-4. Old mount pods will be replaced by DaemonSet pods
+4. Old Mount Pods will be replaced by DaemonSet Pods
 
 ## Troubleshooting
 
-### DaemonSet pods not created
+### DaemonSet Pods not created
 
 Check if nodes match the affinity rules:
 
 ```bash
 kubectl get nodes --show-labels | grep <your-label>
 ```
 
-### Mount pods on unexpected nodes
+### Mount Pods on unexpected nodes
 
 Verify the nodeAffinity configuration:
 
@@ -210,4 +211,4 @@ Check DaemonSet annotations:
 
 ```bash
 kubectl get daemonset <name> -n kube-system -o jsonpath='{.metadata.annotations}'
-```
+```

docs/en/guide/mount-pod-configuration.md

@@ -1,20 +1,20 @@
 # Mount Pod Configuration Guide
 
-JuiceFS CSI Driver provides flexible mount pod deployment options that can be configured per StorageClass. This allows you to optimize resource usage and performance based on your specific needs.
+JuiceFS CSI Driver provides flexible Mount Pod deployment options that can be configured per StorageClass. This allows you to optimize resource usage and performance based on your specific needs.
 
 ## Overview
 
-JuiceFS CSI Driver supports three mount pod deployment modes:
+JuiceFS CSI Driver supports three Mount Pod deployment modes:
 
-1. **Per-PVC Mode** (`per-pvc`): Creates a separate mount pod for each PVC
-2. **Shared Pod Mode** (`shared-pod`): Shares mount pods across PVCs using the same StorageClass
-3. **DaemonSet Mode** (`daemonset`): Deploys mount pods as DaemonSets with node affinity support
+1. **Per-PVC Mode** (`per-pvc`): Creates a separate Mount Pod for each PVC
+2. **Shared Pod Mode** (`shared-pod`): Shares Mount Pods across PVCs using the same StorageClass
+3. **DaemonSet Mode** (`daemonset`): Deploys Mount Pods as DaemonSets with node affinity support
 
 ## Configuration Methods
 
 ### Global Defaults (Environment Variables)
 
-Set default behavior for all StorageClasses via environment variables in the CSI driver:
+Set default behavior for all StorageClasses via environment variables in the CSI Driver:
 
 ```yaml
 env:
@@ -61,59 +61,68 @@ data:
 
 ### Per-PVC Mode
 
-Each PVC gets its own dedicated mount pod.
+Each PVC gets its own dedicated Mount Pod.
 
 **Advantages:**
+
 - Complete isolation between PVCs
 - Simple troubleshooting
 - Independent lifecycle management
 
 **Use Cases:**
+
 - Development environments
 - Multi-tenant scenarios requiring strict isolation
 - Applications with specific mount configurations
 
 **Configuration:**
+
 ```yaml
 mode: per-pvc
 ```
 
 ### Shared Pod Mode
 
-Multiple PVCs using the same StorageClass share mount pods.
+Multiple PVCs using the same StorageClass share Mount Pods.
 
 **Advantages:**
+
 - Reduced resource consumption
-- Fewer pods to manage
+- Fewer Pods to manage
 - Shared cache benefits
 
 **Use Cases:**
+
 - Production environments with many PVCs
 - Clusters with resource constraints
 - Applications with similar access patterns
 
 **Configuration:**
+
 ```yaml
 mode: shared-pod
 ```
 
 ### DaemonSet Mode
 
-Mount pods are deployed as DaemonSets across selected nodes.
+Mount Pods are deployed as DaemonSets across selected nodes.
 
 **Advantages:**
-- Predictable pod placement
+
+- Predictable Pod placement
 - Node-level resource optimization
 - Automatic scaling with node additions
 - Centralized node affinity control
 
 **Use Cases:**
+
 - High-performance computing
-- Dedicated mount nodes
+- Dedicated Mount nodes
 - GPU workloads
 - Large-scale deployments
 
 **Configuration:**
+
 ```yaml
 mode: daemonset
 nodeAffinity:
@@ -140,7 +149,7 @@ The ConfigMap approach allows you to change mount behavior **without modifying e
 
 1. Create the ConfigMap with desired configuration
 2. New PVCs will use the new mount mode
-3. Existing PVCs continue using their current mount pods
+3. Existing PVCs continue using their current Mount Pods
 
 ## Examples
 
@@ -202,7 +211,7 @@ data:
 
 ### Example 3: Node-Specific DaemonSets
 
-Deploy mount pods on specific node types:
+Deploy Mount Pods on specific node types:
 
 ```yaml
 apiVersion: v1
@@ -264,7 +273,7 @@ kubectl get configmap juicefs-mount-config -n kube-system -o jsonpath='{.data.my
 
 ## Best Practices
 
-1. **Start with shared-pod mode** for most workloads
+1. **Start with shared-Pod mode** for most workloads
 2. **Use DaemonSet mode** for:
    - High-performance requirements
    - Predictable resource allocation
@@ -279,39 +288,44 @@ kubectl get configmap juicefs-mount-config -n kube-system -o jsonpath='{.data.my
 
 ## Troubleshooting
 
-### Mount pods not created as expected
+### Mount Pods not created as expected
 
 1. Check ConfigMap exists and is valid:
+
 ```bash
 kubectl get configmap juicefs-mount-config -n kube-system
 ```
 
-2. Verify CSI driver can read ConfigMap:
+2. Verify CSI Driver can read ConfigMap:
+
 ```bash
 kubectl logs -n kube-system daemonset/juicefs-csi-node | grep "mount-config"
 ```
 
 3. Check for syntax errors in ConfigMap:
+
 ```bash
 kubectl get configmap juicefs-mount-config -n kube-system -o yaml | \
   yq eval '.data.default' - | kubectl create --dry-run=client -f -
 ```
 
-### DaemonSet pods not scheduled
+### DaemonSet Pods not scheduled
 
 1. Verify node affinity matches existing nodes:
+
 ```bash
 kubectl get nodes --show-labels
 ```
 
 2. Check DaemonSet status:
+
 ```bash
 kubectl describe daemonset -n kube-system juicefs-<uniqueid>-mount-ds
 ```
 
 ### Switching modes for existing PVCs
 
-Existing PVCs continue using their current mount pods. To switch modes:
+Existing PVCs continue using their current Mount Pods. To switch modes:
 
 1. Update ConfigMap with new configuration
 2. Delete existing PVCs (ensure data is backed up)
@@ -322,6 +336,7 @@ Existing PVCs continue using their current mount pods. To switch modes:
 ### From Environment Variables to ConfigMap
 
 1. Create ConfigMap with current behavior:
+
 ```yaml
 apiVersion: v1
 kind: ConfigMap
@@ -334,27 +349,28 @@ data:
 ```
 
 2. Deploy ConfigMap:
+
 ```bash
 kubectl apply -f juicefs-mount-config.yaml
 ```
 
 3. New PVCs will use ConfigMap configuration
-4. Optionally remove environment variables from CSI driver
+4. Optionally remove environment variables from CSI Driver
 
 ### From Per-PVC to Shared/DaemonSet
 
 1. Update ConfigMap for specific StorageClasses
 2. New PVCs use new mode automatically
-3. Optionally migrate existing PVCs during maintenance windows
+3. Optionally migrate existing PVCs during maintenance Windows
 
 ## Summary
 
-The mount pod configuration system provides:
+The Mount Pod configuration system provides:
 
 - **Flexibility**: Different modes for different workloads
 - **Compatibility**: Works with existing StorageClasses
 - **Simplicity**: Centralized configuration via ConfigMap
 - **Power**: Fine-grained control with node affinity
 - **Safety**: Non-disruptive to existing workloads
 
-Choose the appropriate mode based on your workload requirements, resource constraints, and operational preferences.
+Choose the appropriate mode based on your workload requirements, resource constraints, and operational preferences.