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

RPC endpoint for syncing filesystem #2698

Open
v6ak opened this issue Mar 12, 2017 · 6 comments
Open

RPC endpoint for syncing filesystem #2698

v6ak opened this issue Mar 12, 2017 · 6 comments
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.

Comments

@v6ak
Copy link

v6ak commented Mar 12, 2017

I'd appreciate a synchronous endpoint for flushing all FS changes. Currently, I can run qvm-run -p vm_name sync (from dom0). It will work on Linux. But its behavior on other systems is generally not defined (it will most likely be an undefined command).

Why? Because of syncing a running VMs: v6ak/qubes-incremental-backup-poc#46

@jpouellet
Copy link
Contributor

I cannot possibly imagine any way to implement this in a race-free way (with fs state flushed & return from RPC (& block-level snapshot taking affect) being atomic).

It seems to me that the only way to really guarantee consistency would be vfs-layer snapshot capability and to do syncing from that at that layer, or to be happy with backups only between vm shutdowns.

This is quite unfortunate, but I do not see any way around it other than crossing your fingers and hoping that journaling has reasonable outcome.

@jpouellet
Copy link
Contributor

There is also the question of application state (consider a database that has a file open and locked). From OS/kernel view, all pending things are synced. In reality (with respect to data user cares about) that is not the case.

Consistency is hard :(

Personally, I'm totally fine with backups requiring rebooting. For the uptime of typical Qubes use case (laptop/workstation) IMHO this is reasonable.

@jpouellet
Copy link
Contributor

Don't let my ramblings be discouraging though. I'm just happy someone is continuing the effort to improve backups :)

@v6ak
Copy link
Author

v6ak commented Mar 13, 2017 via email

@jpouellet
Copy link
Contributor

[...] but it does not mean that syncing is totally pointless

Fair enough

@andrewdavidwong andrewdavidwong added C: core T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. labels Mar 14, 2017
@andrewdavidwong andrewdavidwong added this to the Release 4.1 milestone Mar 14, 2017
@iamahuman
Copy link

Ideally a sync() system call inside a VM should propagate to hardware, and finish only after the actual sync is done. This might already be the case.

@andrewdavidwong andrewdavidwong added the P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. label Feb 8, 2021
@andrewdavidwong andrewdavidwong removed this from the Release 4.2 milestone Aug 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
Projects
None yet
Development

No branches or pull requests

4 participants