From: Christoph Anton Mitterer <calestyo@scientia.net>
To: Roman Mamedov <rm@romanrm.net>
Cc: Adam Borowski <kilobyte@angband.pl>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: zerofree btrfs support?
Date: Sat, 10 Mar 2018 17:55:48 +0100 [thread overview]
Message-ID: <1520700948.24363.28.camel@scientia.net> (raw)
In-Reply-To: <20180310193722.2d6b494a@natsu>
On Sat, 2018-03-10 at 19:37 +0500, Roman Mamedov wrote:
> Note you can use it on HDDs too, even without QEMU and the like: via
> using LVM
> "thin" volumes. I use that on a number of machines, the benefit is
> that since
> TRIMed areas are "stored nowhere", those partitions allow for
> incredibly fast
> block-level backups, as it doesn't have to physically read in all the
> free
> space, let alone any stale data in there. LVM snapshots are also way
> more
> efficient with thin volumes, which helps during backup.
I was thinking about using those... but then I'd have to use loop
device files I guess... which I also want to avoid.
> > dm-crypt per default blocks discard.
>
> Out of misguided paranoia. If your crypto is any good (and last I
> checked AES
> was good enough), there's really not a lot to gain for the "attacker"
> knowing
> which areas of the disk are used and which are not.
I'm not an expert here... but a) I think it would be independent of AES
and rather the encryption mode (e.g. XTS) which protects here or not...
and b) we've seen too many attacks on crypto based on smart statistics
and knowing which blocks on a medium are actually data or just "random
crypto noise" (and you know that when using TRIM) can already tell a
lot.
At least it could tell an attacker how much data there is on a fs.
> It works, just not with some of the QEMU virtualized disk device
> drivers.
> You don't need to use qemu-img to manually dig holes either, it's all
> automatic.
You're right... seems like in older version one needed to set virtio-
scsi as device driver (which I possible missed), but nowadays it even
seems to work with sata.
> QEMU deallocates parts of its raw images for those areas which have
> been
> TRIM'ed by the guest. In fact I never use qcow2, always raw images
> only.
> Yet, boot a guest, issue fstrim, and see the raw file while still
> having the
> same size, show much lower actual disk usage in "du".
Works with qcow2 as well... heck even Windows can do it (though it has
no fstrim and it seems one needs to run defrag (which probably does
next to defragmentation also what fstrim does).
Fine for me,... though non qemu users may still be interested in having
zerofree.
Cheers,
Chris.
next prev parent reply other threads:[~2018-03-10 16:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-10 2:55 zerofree btrfs support? Christoph Anton Mitterer
2018-03-10 8:16 ` Adam Borowski
2018-03-10 14:19 ` Christoph Anton Mitterer
2018-03-10 14:37 ` Roman Mamedov
2018-03-10 15:50 ` Adam Borowski
2018-03-10 16:58 ` Christoph Anton Mitterer
2018-03-10 18:31 ` Roman Mamedov
2018-03-10 18:39 ` Christoph Anton Mitterer
2018-03-10 16:55 ` Christoph Anton Mitterer [this message]
2018-03-14 19:38 ` David Sterba
2018-03-15 2:54 ` Christoph Anton Mitterer
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=1520700948.24363.28.camel@scientia.net \
--to=calestyo@scientia.net \
--cc=kilobyte@angband.pl \
--cc=linux-btrfs@vger.kernel.org \
--cc=rm@romanrm.net \
/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;
as well as URLs for NNTP newsgroup(s).