Andrea Cucciarre'

One more really odd behavior of gluster related to seek_data (see below). This issue appears suddenly, after that any file that is renamed in "test3" fails the seek_data ``` #...

I can't say for sure, but currently on my test system the seek_data fails on any file named test3. I have also recreated the gluster volume (stop, delete, create, start)...

> And as @xhernandez pointed it - looks like #3373 . Indeed my logs seems top confirm it: ``` [2022-09-06 13:06:47.928358 +0000] T [MSGID: 0] [utime-autogen-fops.c:140:gf_utime_open] 0-stack-trace: stack-address: 0x7f8e6c01d638, winding...

My understanding is that the issue appears when you have more subvolume, so ti shoudln't be present when you have only one brick per volume. If it so I could...

Debug logs: ``` [2023-12-15 17:30:38,414] DEBUG [controllerserver - 100:CreateVolume] - Create Volume request request=name: "pvc-f3a76282-c6e0-42ab-8009-07985e51ed82" capacity_range { required_bytes: 21474836480 } volume_capabilities { mount { } access_mode { mode: MULTI_NODE_MULTI_WRITER }...

Same issue is present in Kadalu 1.2.0 Issue is not present in Kadalu 0.8.14, though in this release command `kubectl-kadalu storage-list --status` doesn't work `# kubectl exec -it deploy/operator -n...

If the logic in "expansion" should be the same as in "create" then the update_free_size() should't be called for PV_TYPE_SUBVOL even during "expansion", while currently for PV_TYPE_SUBVOL it's not called...

Before doing a PR I guess we have to establish whether Kadalu support over-provisioning for External native mode or not. That's not clear to me cause the code doesn't call...

[nfs-ganesha.log](https://github.com/nfs-ganesha/nfs-ganesha/files/13068526/nfs-ganesha.log)

I have same issue even when NFS Ganesha run in the host (instead of K3s container)