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

RFE: Automatically set nodatacow on $pooldir when on btrfs #4679

Open
cmurf opened this issue May 30, 2022 · 7 comments
Open

RFE: Automatically set nodatacow on $pooldir when on btrfs #4679

cmurf opened this issue May 30, 2022 · 7 comments
Labels

Comments

@cmurf
Copy link

cmurf commented May 30, 2022

Summary: Btrfs upstream advises VM images use nodatacow, therefore make sure chattr +C is set on the openqa directory (at create time).

Background: On (open)SUSE, /var has nodatacow file attribute C set at installation time. But most other distros don't do this, including Fedora. Meanwhile, libvirt now checks if a dir pool is on btrfs and by default sets the nodatacow file attribute.
https://listman.redhat.com/archives/libvir-list/2020-July/205982.html

Since libvirt isn't being used here, I think it's reasonable to just unconditionally set nodatacow file attribute on btrfs whenever creating a new parent directory to be used for openqa. Any new dirs and files, including qcow2, will inherit this file attribute.

@stale
Copy link

stale bot commented Sep 9, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Sep 9, 2022
@stale
Copy link

stale bot commented Sep 21, 2022

This Pull Request has been automatically closed as it did not have any activity in the last 97 days. Thank you.

@stale stale bot closed this as completed Sep 21, 2022
@okurz
Copy link
Member

okurz commented Sep 23, 2022

Reopening as likely still valid. Also I created https://progress.opensuse.org/issues/117136 to prevent the stale bot to close issues which are still valid.

@okurz okurz reopened this Sep 23, 2022
@stale stale bot removed the stale label Sep 23, 2022
@stale
Copy link

stale bot commented Dec 23, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Dec 23, 2022
@kalikiana
Copy link
Member

Reopening as likely still valid. Also I created https://progress.opensuse.org/issues/117136 to prevent the stale bot to close issues which are still valid.

It doesn't look like this worked. At least this issue was still marked as stale. 🤔

@stale stale bot removed the stale label Jan 2, 2023
@okurz
Copy link
Member

okurz commented Jan 2, 2023

yes, but the PR is only marked as stale, not closed. That's what we wanted.

@stale
Copy link

stale bot commented Apr 2, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Apr 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants