public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Christian Ebner <c.ebner@proxmox.com>
To: "Proxmox Backup Server development discussion"
	<pbs-devel@lists.proxmox.com>,
	"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup 2/2] fix #5982: garbage collection: check atime updates are honored
Date: Mon, 17 Feb 2025 16:57:08 +0100	[thread overview]
Message-ID: <a47be8b8-33d1-45c7-aff0-7b0621d51118@proxmox.com> (raw)
In-Reply-To: <1739806100.hejephfmgd.astroid@yuna.none>

On 2/17/25 16:36, Fabian Grünbichler wrote:
> On February 17, 2025 2:12 pm, Christian Ebner wrote:
>> Check if the filesystem the chunk store is located on actually
>> updates the atime when performing the marking of the chunks in
>> phase 1 of the garbage collection. Since it is not enough to check if
>> a single/first chunks atime is updated, since the filesystem can be
>> mounted via the `relatime` option, find the first chunk which is'
>> outside the relatime's 24 hour cutoff window and check the update on
>> that chunk only.
> 
> given that our touching should punch through relatime (and does so on
> all filesystems we tested so far), couldn't we just
> 
> - stat the first chunk
> - touch the first chunk
> - check if timestamps have been updated
> - print a warning about the filesystem being potentially broken, and
> - if the option is enabled, suggest the user report the details to us
> - only continue if the option is explicitly disabled
> 
> that way we should get a real world survey of broken file systems that
> could inform our decision to drop the 24h window (or keep it).. if we
> introduce an option (defaulting to yes for now) conditionalizing the 24h
> window, we could even tell users with semi-broken storages (see below)
> to explicitly set that option in case we later switch the default,
> although I am not sure whether such storages exist for real.

Hmm, that is a good idea!

> the only downside would be a potential slew of reports if we missed some
> prominent filesystem that applies relatime to explicit timestamp updates
> (any prominent storage ignoring explicit timestamp updates altogether
> would have already cropped up in our support channels after causing
> fatal data loss, and we only had a handful such reports so far, usually
> involving proprietary storage appliances).

Of course not ideal, but to big of an issue if this check is implemented 
to be opt-out. Giving the user a way to disable such a check and 
generating data to potentially drop the 24h grace period altogether in 
the future sound good to me!

Will adapt the patches accordingly in version 2, thanks!


_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel

  reply	other threads:[~2025-02-17 15:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-17 13:12 [pbs-devel] [PATCH proxmox proxmox-backup 0/2] fix #5892: check atime update is honored Christian Ebner
2025-02-17 13:12 ` [pbs-devel] [PATCH proxmox 1/2] pbs api types: Add check garbage collection atime updates flag Christian Ebner
2025-02-17 13:12 ` [pbs-devel] [PATCH proxmox-backup 2/2] fix #5982: garbage collection: check atime updates are honored Christian Ebner
2025-02-17 15:36   ` Fabian Grünbichler
2025-02-17 15:57     ` Christian Ebner [this message]
2025-02-18 11:53     ` Thomas Lamprecht
2025-02-18 12:39       ` Christian Ebner
2025-02-18 13:17         ` Christian Ebner
2025-02-18 13:31         ` Thomas Lamprecht
2025-02-18 13:38           ` Christian Ebner
2025-02-19 16:54 ` [pbs-devel] [PATCH proxmox proxmox-backup 0/2] fix #5892: check atime update is honored Christian Ebner

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=a47be8b8-33d1-45c7-aff0-7b0621d51118@proxmox.com \
    --to=c.ebner@proxmox.com \
    --cc=f.gruenbichler@proxmox.com \
    --cc=pbs-devel@lists.proxmox.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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal