Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow FSGroup recursive permission changes . Is there an optimization method? #130192

Open
wwthw opened this issue Feb 15, 2025 · 6 comments
Open
Labels
kind/support Categorizes issue or PR as a support question. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. sig/storage Categorizes an issue or PR as relevant to SIG Storage.

Comments

@wwthw
Copy link

wwthw commented Feb 15, 2025

What happened?

The fsgroup setting may take a long time to create a pod,as it can take hours or days to recursively change permissions on multi-terabyte servers.Is there a better optimization method for recursively modifying permissions?

What did you expect to happen?

The fsgroup setting may take a long time to create a pod

How can we reproduce it (as minimally and precisely as possible)?

There are a lot of files on the server.Permissions need to be modified.

Anything else we need to know?

No response

Kubernetes version

$ kubectl version
# paste output here

Cloud provider

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

@wwthw wwthw added the kind/bug Categorizes issue or PR as related to a bug. label Feb 15, 2025
@k8s-ci-robot k8s-ci-robot added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Feb 15, 2025
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Feb 15, 2025
@wwthw
Copy link
Author

wwthw commented Feb 15, 2025 via email

@wwthw wwthw changed the title Slow FSGroup recursive permission changes ,Is there an optimization method? Slow FSGroup recursive permission changes . Is there an optimization method? Feb 15, 2025
@hkttty2009
Copy link

Maybe what you need is fsGroupChangePolicy: "OnRootMismatch".
Link: configure-volume-permission-and-ownership-change-policy-for-pods

@novahe
Copy link
Contributor

novahe commented Feb 15, 2025

/kind support
/remove-kind bug

@k8s-ci-robot k8s-ci-robot added kind/support Categorizes issue or PR as a support question. and removed kind/bug Categorizes issue or PR as related to a bug. labels Feb 15, 2025
@Ruchi1499
Copy link

/sig storage

@k8s-ci-robot k8s-ci-robot added sig/storage Categorizes an issue or PR as relevant to SIG Storage. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Feb 15, 2025
@Ruchi1499
Copy link

In addition to using fsGroupChangePolicy: "OnRootMismatch" to optimize recursive permission changes, you may also consider pre-setting the ownership and group on the volume manually before mounting. This can further reduce the overhead of chown and chmod operations during pod startup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/support Categorizes issue or PR as a support question. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. sig/storage Categorizes an issue or PR as relevant to SIG Storage.
Projects
None yet
Development

No branches or pull requests

5 participants