From: Joshua Huber via pve-devel <pve-devel@lists.proxmox.com>
To: PVE Devel <pve-devel@lists.proxmox.com>
Cc: Joshua Huber <jhuber@blockbridge.com>
Subject: [pve-devel] orphaned cfs lock when interrupting qm disk import
Date: Mon, 26 Aug 2024 16:46:10 -0400 [thread overview]
Message-ID: <mailman.425.1724705222.302.pve-devel@lists.proxmox.com> (raw)
[-- Attachment #1: Type: message/rfc822, Size: 5603 bytes --]
From: Joshua Huber <jhuber@blockbridge.com>
To: PVE Devel <pve-devel@lists.proxmox.com>
Subject: orphaned cfs lock when interrupting qm disk import
Date: Mon, 26 Aug 2024 16:46:10 -0400
Message-ID: <CA+uqL00=49RuhJjjsJZfwZURWYBqf_TdkqCGtB6PM1055pO0yQ@mail.gmail.com>
Hi everyone,
Say you've just kicked off a long-running "qm disk import ..." command and
notice that an incorrect flag was specified. Ok, cancel the operation with
control-C, fix the flag and re-execute the import command...
However, when using shared storage you'll (at least for the next 120
seconds) bump up against an orphaned cfs lock directory. One could manually
remove the directory from /etc/pve/priv/locks, but it seems a little risky.
(and a bad habit to get into)
So this got me thinking... could we trap SIGINT and more gracefully fail
the operation? It seems like this would allow the cfs_lock function to
clean up after itself. This seems like it'd be a nice CLI QOL improvement.
However, I'm not familiar with the history of the cfs-lock mechanism, why
it's used for shared storage backends, and what other invalid PVE states
might be avoided as a side-effect of serializing storage operations.
Allowing concurrent operations could result in disk numbering collisions,
but I'm not sure what else. (apart from storage-specific limitations.)
The README in the pve-cluster repo was helpful but a bit limited in scope.
Could anyone shed some more light on this for me?
Thanks in advance,
Josh
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next reply other threads:[~2024-08-26 20:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-26 20:46 Joshua Huber via pve-devel [this message]
[not found] <CA+uqL00=49RuhJjjsJZfwZURWYBqf_TdkqCGtB6PM1055pO0yQ@mail.gmail.com>
2024-09-06 17:38 ` Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mailman.425.1724705222.302.pve-devel@lists.proxmox.com \
--to=pve-devel@lists.proxmox.com \
--cc=jhuber@blockbridge.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox