Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: "Swâmi Petaramesh" <swami@petaramesh.org>,
	"Linux BTRFS" <linux-btrfs@vger.kernel.org>
Subject: Re: BTRFS, SSD and single metadata
Date: Mon, 16 Jun 2014 07:09:55 -0400	[thread overview]
Message-ID: <539ED083.5050705@gmail.com> (raw)
In-Reply-To: <1723493.aXdklhDgAK@vajra>

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

On 2014-06-16 03:54, Swâmi Petaramesh wrote:
> Hi,
> 
> I created a BTRFS filesytem over LVM over LUKS encryption on an SSD [yes, I 
> know...], and I noticed that the FS got created with metadata in "DUP" mode, 
> contrary to what "man mkfs.btrfs" says for SSDs -> it would be supposed to be 
> "SINGLE"...
> 
> Well I don't know if my system didn't identify the SSD because of the LVM+LUKS 
> stack (however it mounts well by itself with the "ssd" flag and accepts the 
> "discard" option [yes, I know...]), or if the manpage is obsolete or if this 
> feature just doesn't work...?
> 
> The SSD being a Micron RealSSD C400
> 
> For both SSD preservation and data integrity, would it be advisable to change 
> metadata to "SINGLE" using a rebalance, or if I'd better just leave things the 
> way they are...?
> 
> TIA for any insight.
> 
What mkfs.btrfs looks at is
/sys/block/<whatever-device>/queue/rotational, if that is 1 it knows
that the device isn't a SSD.  I believe that LVM passes through whatever
the next lower layer's value is, but dmcrypt (and by extension LUKS)
always force it to a 1 (possibly to prevent programs from using
heuristics for enabling discard)


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]

  reply	other threads:[~2014-06-16 11:10 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 [this message]
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

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=539ED083.5050705@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=swami@petaramesh.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