All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: "Swâmi Petaramesh" <swami@petaramesh.org>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Is there a "nossd" option ?
Date: Sun, 21 Jun 2015 22:31:21 +0500	[thread overview]
Message-ID: <20150621223121.617b8894@natsu> (raw)
In-Reply-To: <1586648.BNplRrhkhg@zafu>

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

On Sun, 21 Jun 2015 19:13:10 +0200
Swâmi Petaramesh <swami@petaramesh.org> wrote:

> Hi,
> 
> Running a 3.19 Ubuntu kernel,
> 
> I'm currently budling a RAID-1 BTRFS set for which every underlying device is 
> a LUKS-encrypted device itself built out of a bcache device comprised of a 
> mechanical HD partition + an SSD cache partition.
> 
> Looks like it's working.
> 
> BUT I see that BTRFS decides by itself to mount with the "ssd" option as  
> bcache makes it think the device is not "rotational".
> 
> However I feel that a mechanical HD plus SSD bcache should probably not be 
> "SSD-optimized" as the underlying storage is indeed mechanical and bcache 
> already manages the SSD part optimization by itself - and I'm afraid the "SSD 
> optimization" could actually cause the mechanical storage to end up being much 
> more fragmented than it should...
> 
> So the question is : Is there a mount option such as "nossd" that I could use 
> to inhibit the automatic SSD "choice" that BTRFS makes ?

Yes the "nossd" option (written literally like that) does in fact exist.
It would have taken you less time to try if it works, than to write this
long-winded message. :)


-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2015-06-21 17:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-21 17:13 Is there a "nossd" option ? Swâmi Petaramesh
2015-06-21 17:31 ` Roman Mamedov [this message]
2015-06-21 18:11   ` Swâmi Petaramesh
2015-06-21 18:18     ` Eric Sandeen
2015-06-21 18:22     ` Roman Mamedov

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=20150621223121.617b8894@natsu \
    --to=rm@romanrm.net \
    --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.