From: "Swâmi Petaramesh" <swami@petaramesh.org>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: BTRFS, SSD and single metadata
Date: Mon, 16 Jun 2014 14:26:59 +0200 [thread overview]
Message-ID: <5397989.Rnm13cYs7v@vajra> (raw)
In-Reply-To: <pan$5075b$6568c7ca$c4158fb1$b65edba2@cox.net>
Le lundi 16 juin 2014, 12:16:33 Duncan a écrit :
> Does btrfs automatically add the ssd mount option or do you have to add
> it? If you have to add it, that means btrfs isn't detecting the ssd,
First time I mounted the freshly created filesystem, it actually added the
"ssd" option by itself. Thus indeed, it could see this was a SSD...
> However, it occurs to me that with the LUKS encryption layer, I'm not
> entirely sure if duplication at the btrfs level would end up as the same
> encrypted stream headed to the hardware in any case. If it would encrypt
> the two copies of the dup-mode metadata as different, then the hardware
> dedup/compression wouldn't work on it anyway. OTOH, if it encrypts them
> as the same stream headed to hardware, then again, it would matter.
That makes an excellent point. 2 copies of the same binary data in different
filesystem sectors, process thru LUKS, will create entirely different binary
ciphertext, so for sure both metadata copies will always be different and
cannot be "deduped" by SSD firmware...
Kind regards.
--
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E
Les êtres humains, cernés par leurs besoins, s'agitent sans but comme des
lapins pris au piège. Ainsi, moine, détourne-toi de ces besoins et trouve
la liberté.
-- Buddha Shakyamuni
prev parent reply other threads:[~2014-06-16 12:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 7:54 BTRFS, SSD and single metadata Swâmi Petaramesh
2014-06-16 11:09 ` Austin S Hemmelgarn
2014-06-16 11:18 ` Swâmi Petaramesh
2014-06-16 11:23 ` Austin S Hemmelgarn
2014-06-16 12:01 ` Russell Coker
2014-06-16 12:16 ` Duncan
2014-06-16 12:26 ` Swâmi Petaramesh [this message]
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=5397989.Rnm13cYs7v@vajra \
--to=swami@petaramesh.org \
--cc=1i5t5.duncan@cox.net \
--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