Add mount-point inode and read-only operational state leaves

[Verma-Anukul]

This change introduces new mount-point operational state leaves inodes-total, inodes-available, inodes-utilized, and read-only under /system/mount-points/mount-point/state. These complement the existing storage space leaves (size, available, utilized) by exposing inode capacity/utilization and mount mode for filesystem monitoring and troubleshooting.
The version has been bumped to 3.2.0 in openconfig-system.yang.

Change-Id: Ia25932ff09415b97d0960384579a37a4013d8183

Change Scope

• Description: This PR adds operational state leaves to the mount-point-state grouping in openconfig-system.yang for inode total/free/used counts and read-only mount status. inodes-total refers to total inode capacity; inodes-available refers to free/unused inodes; inodes-utilized mirrors the existing storage utilized leaf for used inode count.
• Backwards Compatibility: This change is fully backward compatible as it only adds new operational state leaves to an existing grouping.

Use case

Filesystem exhaustion is a common cause of control-plane and application failures on network devices. While existing mount-point leaves report block storage (size, available, utilized), operators also need inode utilization to detect cases where free space remains but file creation fails due to inode exhaustion. The read-only leaf surfaces mount mode changes that can silently block writes during disk pressure or maintenance events.

Platform Implementations

• POSIX statfs(2) / df provide inode total and free counts on Linux-based NOS platforms.
  https://man7.org/linux/man-pages/man1/df.1.html
  https://man7.org/linux/man-pages/man2/statfs.2.html

https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-system-inventory-hardware-storage.html
https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/system-management/b-system-management/m-utility-commands.html#wp8767566250
https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-514/Monitoring-and-Troubleshooting/Monitoring-Best-Practices/

Tree View

module: openconfig-system
  +--rw system
     ...
     +--rw mount-points
        +--rw mount-point* [name]
           ...
           +--ro state
              ...
              +--ro size?                uint64
              +--ro available?           uint64
              +--ro utilized?            uint64
              +--ro type?                 union
+             +--ro inodes-available?     uint64
+             +--ro inodes-total?         uint64
+             +--ro inodes-utilized?      uint64
+             +--ro read-only?             boolean

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request updates the openconfig-system.yang model to version 3.2.0, introducing new operational leaves for filesystem mount-points: inodes-available, inodes-total, and read-only. The feedback suggests clarifying the description of inodes-total to avoid ambiguity with inodes-available and recommends adding an inodes-utilized leaf to maintain consistency with existing storage metrics.

[Verma-Anukul]

Thanks for the review.

Addressed both points in the latest update:

1. inodes-total — description now refers to total inode capacity (The total number of inodes on the filesystem.) rather than using "available", which is reserved for free/unused inodes in inodes-available.

2. inodes-utilized — added for parity with the existing storage space leaves (size, available, utilized).

SONiC currently publishes inode free/total counts from statfs; utilized can be derived as inodes-total - inodes-available until platforms populate the leaf directly.

[Verma-Anukul]

/azp run

[navaneethyv]

OC review Jul 21.

@Verma-Anukul we need 2 reference implementations from vendors for us to take this request in.
Can you please get the references from SONIC distributions from such 2 vendors so that this can move forward?

[navaneethyv]

OC Review 28th.

@Verma-Anukul we would need 2 supporting vendor implementation references to take this forward.

@nokia1adam @earies can you please add your comments on this ?

[navaneethyv]

OC review August 4th:

Need input on the reference implementations.

[Verma-Anukul]

https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/system-management/b-system-management/m-utility-commands.html#wp8767566250
https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-514/Monitoring-and-Troubleshooting/Monitoring-Best-Practices/

I have added a few references in the PR description for context.

Both the standard Linux df utility and the statfs API expose these filesystem attributes along with the existing capacity information:

• https://man7.org/linux/man-pages/man1/df.1.html
• https://man7.org/linux/man-pages/man2/statfs.2.html

Most network operating systems also provide access to these standard utilities through their underlying Linux/Unix shell. For example:

• Cisco IOS XR utility commands: https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/system-management/b-system-management/m-utility-commands.html#wp8767566250
• NVIDIA Cumulus Linux monitoring guide: https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-514/Monitoring-and-Troubleshooting/Monitoring-Best-Practices/

Additionally, SONiC's STATE_DB has been extended to expose these filesystem attributes:

admin@TestSwitch:~$ redis-cli -n 6
127.0.0.1:6379[6]> keys MOUNT*
1) "MOUNT_POINTS|/host"
2) "MOUNT_POINTS|LastUpdateTime"

127.0.0.1:6379[6]> hgetall "MOUNT_POINTS|/host"
 1) "1K-blocks"
 2) "16206120"
 3) "Available"
 4) "7746016"
 5) "Filesystem"
 6) "/dev/sda3"
 7) "InodeAvailable"
 8) "892827"
 9) "InodeTotal"
10) "1040384"
11) "ReadOnly"
12) "false"
13) "Type"
14) "ext4"
15) "Used"
16) "8443720"

The proposed OpenConfig augmentation is intended to expose these already available filesystem attributes (InodeTotal, InodeAvailable, and ReadOnly) through the management interface in addition to the existing mount-point information.

[earies]

@nokia1adam @earies can you please add your comments on this ?

LGTM