SNAP Virtio-fs Service Release Notes

–

Description: Due to the lack of recovery support, it is not possible to perform any negative/resilience operations during IO traffic (e.g., destroy and restore).

Workaround: N/A

Keywords: Recovery; negative/resilience operations

Discovered in version: 1.0.0-doca2.8.0

–

Description: The following FUSE commands are unsupported: BMAP, SETUPMAPPING, REMOVEMAPPING

Workaround: N/A

Keywords: FUSE

Discovered in version: 1.0.0-doca2.8.0

–

Description: Application restart is not allowed if the application controller has processed FUSE commands.

Workaround: Unload the virtio-fs driver on the host, then restart the application.

Keywords: FUSE

Discovered in version: 1.0.0-doca2.8.0

–

Description: The total number of virtio queues the application can create is limited to 2,000.

Workaround: N/A.

Keywords: Virtio queues

Discovered in version: 1.0.0-doca2.8.0

–

Description: The following operations are not supported when using Linux's virtio-fs inbox/upstream kernel driver: FLR and the virtio-fs notification queue.

Workaround: N/A

Keywords: FLR; virtio-fs; inbox/upstream kernel driver

Discovered in version: 1.0.0-doca2.8.0

–

Description: I/O with size greater than 255 KB is not supported due to the data pool size restriction of 255 KB in the VirtioFS process running on the DPU.

Workaround: Set the max_xfer_size in the fsdev_aio_create RPC to a value less than 255 KB. This value is used as max_write in the FUSE layer of the host kernel.

If the I/O size exceeds max_xfer_size , the FUSE layer in the host kernel will split the I/O into smaller chunks.

The default max_xfer_size value in fsdev_aio_create RPC is 128KB. For example, if you attempt an I/O operation of 1MB while max_xfer_size is set to 64KB, the FUSE layer on the host will split the request into 64KB chunks. As a result, the VirtioFS process on the DPU will receive 16 separate I/O requests (1MB ÷ 64KB).

Keywords: IO error, host error, io_size

Discovered in version: 1.2.0-doca2.10.0

-

Description: You cannot modify num_request_queues on a hotplug device that is in the POWER_ON state and an unloaded host driver.

Workaround: Unplug the device using virtio_fs_doca_device_hotunplug and then change num_request_queues

Keywords: hotplug, num_request_queues

Discovered in version: 1.3.0-doca3.0.0

-

Description: Virtio-blk max supported scale is 218 virtio-blk controllers

Workaround: N/A

Keywords: Virtio-blk

Discovered in version: 1.3.0-doca3.0.0

-

Description: When calling virtio_fs_device_get_stat rpc , this rpc may timeout or wait for traffic to end on some of the devices at high scale (four or more hotplug devices) and high traffic.

Workaround: N/A

Keywords: virtio_fs_device_get_stat , stat

Discovered in version: 1.3.0-doca3.0.0

-

Description: Invoking the virtio_fs_device_hotunplug RPC while the device is still actively mounted on the host, and subsequently calling virtio_fs_device_hotplug will lead to I/O errors on the mount point.

Workaround: Before invoking the virtio_fs_device_hotunplug RPC, ensure that there is no active mount point on the host associated with the device — specifically, the emulated file path should be unmounted using the unmount command.

Keywords: hotunplug, mount

Discovered in version: 1.3.0-doca3.0.0

-

Description: Under high scale, virtio_fs_doca_manager_destroy RPC can timeout

Workaround: Run rpc with custom timeout of 120 seconds. For example, rpc.py -t 120 virtio_fs_doca_manager_destroy -m mlx5_0

Keywords: timeout

Discovered in version: 1.3.0-doca3.0.0

-

Description: Linux Kernel NFS RDMA server is known to handle incoming connection very slowly. It may cause connection timeouts at high scale (multiple hotplug functions).

Workaround: Add a delay between mounts of different hotplug functions on the host.

Keywords: timeout, hotplug, mount

Discovered in version: 1.3.0-doca3.0.0

–

Description: If the FLR is initiated from the host by writing 1 to the reset file under /sys/bus/pci/devices/bdf/ using the echo 1 > /sys/bus/pci/devices/0000\:29\:00.2/reset command, the host driver does not create virtqueues, causing the mount point to remain stuck indefinitely.

Workaround: Only perform FLR without any mount over virtio-fs on the host. To run IO after FLR, reload the virtio-fs host driver.

Keywords: Driver; FLR

Discovered in version: 1.0.0-doca2.8.0

–

Description: On the host, when the virtio-fs mount is idle (that is, no I/O operations), dmesg logs are filled with repeated AppArmor DENIED messages. These messages indicate that the ntpd service is being denied access to specific files by AppArmor. The ntpd service is trying to access /snap/bin/ and /etc/ssl/openssl.cnf, but the AppArmor profile for ntpd does not permit these operations, resulting in denied requests.

Workaround: Modify the AppArmor profile for ntpd to grant the required read permissions.

1. Locate the AppArmor profile for ntpd. It is typically located in /etc/apparmor.d/ and named usr.sbin.ntpd.

2. Edit the profile and add the permissions using a text editor. For example:

   1. Run:

      Copy

      Copied!

                  
      
                  
      sudo nano /etc/apparmor.d/usr.sbin.ntpd
              

   2. Add the following lines to allow ntpd to read the necessary files:

      Copy

      Copied!

                  
      
                  
      /snap/bin/ r,
      /etc/ssl/openssl.cnf r`
              

3. Apply the changes by reloading the AppArmor profile:

   Copy

   Copied!

               
   
               
   sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.ntpd
           

Keywords: AppArmor, ntpd

Discovered in version: 1.0.0-doca2.8.0

–

Description: With a kernel version older than 6.10, continuously stress loading and unloading the virtio_pci and virtiofs drivers, or mounting and unmounting the drivers might cause the driver to hang or become unresponsive.

Workaround: Wait at least 1 second before loading and then unloading the drivers.

Keywords: virtio_pci; virtiofs

Discovered in version: 1.0.0-doca2.8.0