Sync XFS tuning with DirectPV #1369
Conversation
| @@ -314,8 +314,11 @@ Storage | |||
| deviceName="$(basename $i)" | |||
| echo "Modifying xfs max_retries and retry_timeout_seconds for drive $i mounted at $mountPath" | |||
| echo 0 > /sys/fs/xfs/$deviceName/error/metadata/EIO/max_retries | |||
| echo 5 > /sys/fs/xfs/$deviceName/error/metadata/EIO/retry_timeout_seconds | |||
There was a problem hiding this comment.
@balamurugana any reason we shouldn't pull this over to our general guidance? e.g. something specific directpv is doing where it might cause an issue on other xfs drives?
There was a problem hiding this comment.
Actually it feels somewhat extraneous - if max_retries is 0, then there's no point in setting retry_timeout_seconds right?
There was a problem hiding this comment.
I can do a PR in directpv then.
There was a problem hiding this comment.
@ravindk89 I couldn't able to understand the question. What is other xfs drives? DirectPV mounts device with those tunings automatically. Refer https://github.com/minio/directpv/blob/master/pkg/xfs/mount_linux.go#L30
These tunings were suggested by @harshavardhana
There was a problem hiding this comment.
My logic here is
- we set
max_retriesto 0 - We also set
retry_timeout_secondsto 5 - but the first setting means we never retry
- So why do we need to set a retry timeout at all
redhat docs say "/sys/fs/xfs/device/error/metadata/condition/retry_timeout_seconds: the time limit in seconds after which XFS will stop retrying the operation " - unless this applies also to the original operation (e.g. return an error if we don't get success in 5 seconds).
As far as other xfs drives, the docs above would update our public-facing guidance on xfs tunings. If we are confident that these are generally 'safe', then there is no harm in adding it.
See https://github.com/minio/directpv/blob/c269093ab0a536cfffd26faafb3102f2508395e4/pkg/xfs/mount_linux.go#L45