From: alexino@cobios.de
To: linux-btrfs@vger.kernel.org
Subject: performance implications of btrfs filesystem sync vs btrfs subvolume snaphot
Date: Sat, 23 Jan 2021 12:22:11 +0000 [thread overview]
Message-ID: <50f51b01788af83b1bf542f2089a56fe@cobios.de> (raw)
Hello everybody :)
first time participant on linux-btrfs@vger.kernel.org mailinglist,
hence please excuse (yet tell me about) any problems. thank you.
My question/topic is:
Wanting to generate backups of a btrfs filesystems on a running system
it seems that using `btrfs subvolume snapshot` would be a possible way
to make certain that data kept in RAM (i.e. buffer/cache) would be
synced to the disk.
Reading this mailing list I stumpled upon this:
>> Subject: Re: freezes during snapshot creation/deletion -- to be expected? (Was: Re: btrfs based backup?)
>> From: Zygo Blaxell <ce3g8jdj () umail ! furryterror ! org>
>>
>> [..]
>>
>> Snapshot create has unbounded running time on 5.0 kernels. The creation
>> process has to flush dirty buffers to the filesystem to get a clean
>> snapshot state. Any process that is writing data while the flush is
>> running gets its data included in the snapshot flush, so in the worst
>> possible case, the snapshot flush never ends (unless you run out of disk
>> space, or whatever was writing new data stops, whichever comes first).
>> [..]
Now I wonder that if `btrfs filesystem sync` would be a viable alternative
to `btrfs subvolume snapshot`, with respect of not having to risk a
"snapshot flush never ends" situation?
My layman perception is that.
1) "btrfs on-disk-persistet data is ideally alway non-corrupted". Since
changes are commited via COW and hence in a atomic fashion, meaning that
at worst data on disk is outdated, but never corrupt. (unless hardware or
blockdevice issues )
2) btrfs filesystem sync or sync(1) should flush data out from memory
to disk - which would once finished - lead to a "more recent" consistent
data on disk.
3) btrfs subvolume snapshot implies a sync
Are those perceptions roughly correct?
If so I am unsure if the issue with a "neverending flush" is related to
the btrfs filesystem sync and consequently relying on btrfs filesystem
sync as alternative to btrfs snapshot to prevent "a neverending flush"
is not a possibility.
Tahnk yo and best regards,
Alexander Mahr
next reply other threads:[~2021-01-23 12:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-23 12:22 alexino [this message]
2021-01-23 17:13 ` performance implications of btrfs filesystem sync vs btrfs subvolume snaphot Zygo Blaxell
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=50f51b01788af83b1bf542f2089a56fe@cobios.de \
--to=alexino@cobios.de \
--cc=linux-btrfs@vger.kernel.org \
/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