Derek Su
Derek Su
@mgoltzsche Thanks for your quick update. We will investigate the root cause of the hang of termination. https://github.com/mgoltzsche/local-path-provisioner/commit/f608165f75168ba41d6667f88dba2f0f40b1d14d can be a workaround.
Can you check the log and the error messages in the help pod?
@samstride Can you show the pods in your system by `k get pods -A | grep local-path-provisioner`? BTW, k3s has already embedded the `local-path-provisioner`, so you can use it directly.
@tgfree7 Not see any issue before the fix. Can you provide an example for reproducing the error you encountered? Thank you.
We will change the block size of the iSCSI LUN to 4096 to avoid the data corruption caused by the read-modify-write's race condition. There are some tasks we need to...
**Use the solution [Using specific block size in Longhorn volume’s filesystem](https://github.com/longhorn/longhorn/issues/4594), instead.** For the newly created LH filesystem-mode volume, the filesystem data/metadata block size will be 4096 rather than 512....
> @derekbit Could you please update the template [#4599 (comment)](https://github.com/longhorn/longhorn/issues/4599#issuecomment-1260373378) to reflect the final selected PRs for this issue? Thank you very much Ah, thank you for the reminder.
@yangchiu Updated the method https://github.com/longhorn/longhorn/issues/4599#issuecomment-1260373378
Not really sure if there is a bug in xfs. I think user can switch to use ext4 first and see if it still happens in ext4.
> I didn't see any failures noted for the backup or restoration; just that after reverting to the backup, I still received the same I/O error from the pod trying...