Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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

             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