All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.