Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Chris Murphy <lists@colorremedies.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Btrfs on LUKS on loopback mounted image on Btrfs
Date: Thu, 22 Aug 2019 01:12:19 +0500	[thread overview]
Message-ID: <20190822011219.77d2d8bf@natsu> (raw)
In-Reply-To: <CAJCQCtRYFtPGn2drNxrcuYFTTvmvRD7iuDNG=i1cDvSu=zcF6A@mail.gmail.com>

On Wed, 21 Aug 2019 13:42:53 -0600
Chris Murphy <lists@colorremedies.com> wrote:

> Why do this? a) compression for home, b) encryption for home, c) home
> is portable because it's a file, d) I still get btrfs snapshots
> anywhere (I tend to snapshot subvolumes inside of cryptohome; but

Storing Btrfs on Btrfs really feels suboptimal, good that at least you are
using NOCOW; of course it still will be CoW'ed in case of snapshots. Also you
are likely to run into the space wasting issue as discussed in
https://www.spinics.net/lists/linux-btrfs/msg90352.html

I'd strongly suggest that you look into deploying LVM Thin instead. There you
can specify an arbitrary CoW chunk size, and a value such as 1MB or more will
reduce management overhead and fragmentation dramatically.

Or if the partition size in question is just 4GB, with today's SSD sizes, just
store it as a regular LV and save on quite a bit of complexity and brittleness.

> I could "snapshot" outside of it by reflink copying the backing file.

Pretty sure "cp -a is not atomic, so beware, you cannot safely do this while
the /home is open and mounted. On the other hand if you keep this file inside
a subvolume and then snapshot it, then it is safe(r).

> sysroot mkfs options: -dsingle -msingle

This is asking for trouble, even if you said you power-cut it constantly,
there is little reason to run with "single" metadata, not even on SSDs where
some insinuate that "DUP" is always magically 100% deduped internally by the
SSD during writes at speeds of 600-2500 MB/sec; even though we can't see the
internals and SSD firmware is proprietary to reliably confirm or deny, this
seems very unlikely, and more importantly there are other places where one
(and in your case the only) copy of metadata might get corrupted: RAM, storage
controller, cabling. Even a sudden poweroff has more chances to finally do its
thing when there's no possible "other copy of metadata" to refer to, and the
broken one is all you get.

-- 
With respect,
Roman

  reply	other threads:[~2019-08-21 20:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21 19:42 Btrfs on LUKS on loopback mounted image on Btrfs Chris Murphy
2019-08-21 20:12 ` Roman Mamedov [this message]
2019-08-22 21:21   ` Chris Murphy

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=20190822011219.77d2d8bf@natsu \
    --to=rm@romanrm.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.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