All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imran Geriskovan <imran.geriskovan@gmail.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs on whole disk (no partitions)
Date: Thu, 26 Jun 2014 22:46:57 +0200	[thread overview]
Message-ID: <CAK5rZE5VEKJbt7JJpOPD48sZMZPwLgiQC869+hy3toU+0HCKCA@mail.gmail.com> (raw)
In-Reply-To: <56CE0D0C-EE96-4CBC-B7CB-FC42CA1B01DF@colorremedies.com>

On 6/26/14, Chris Murphy <lists@colorremedies.com> wrote:
> On Jun 25, 2014, at 7:01 AM, Imran Geriskovan <imran.geriskovan@gmail.com>
>> There are SSDs with 4K, 8K block/page sizes and
>> 512K, 1M, 1.5M Erase block sizes.
>> Partitions should be aligned with Erase blocks.

> That sounds plausible, but the FTL in the consumer SSD's most all of us are
> buying isn't going to give you any assurance it's actually writing with such
> boundaries in mind. You may have partition 1 start on LBA 2048, which is 1MB
> aligned, but as soon as you're writing data to LBA 2048 through say LBA
> 2560, for all you know that write actually ends up in pages that are located
> in the first and second erase blocks; or maybe all of it's in the 8th erase
> block. The OS side of things we don't have insight or control over this.

8 Logical blocks (Not 8 Erase blocks) makes a 4K Physical block.

(a) Basic principle is to align with "Physical blocks" ("Pages" for SSDs).
(b) For SSDs, aligning with Erase blocks (512K, 1M, 1.5M) also satisfy (a)

Regards, Imran

  reply	other threads:[~2014-06-26 20:46 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18 19:29 btrfs on whole disk (no partitions) Daniel Cegiełka
2014-06-18 20:10 ` Chris Murphy
2014-06-19 11:15   ` Austin S Hemmelgarn
2014-06-18 21:19 ` Imran Geriskovan
2014-06-19  0:07 ` Russell Coker
2014-06-19  8:58   ` Imran Geriskovan
2014-06-19  9:11     ` Imran Geriskovan
2014-06-21 19:19       ` Daniel Cegiełka
2014-06-22  1:36         ` Chris Murphy
2014-06-21 19:12   ` Daniel Cegiełka
2014-06-22  1:34     ` Chris Murphy
2014-06-22  7:49       ` Imran Geriskovan
2014-06-22 13:44         ` George Mitchell
2014-06-22 14:11           ` Roman Mamedov
2014-06-22 14:41             ` George Mitchell
2014-06-22 14:46             ` George Mitchell
2014-06-22 18:56               ` Chris Murphy
2014-06-22 18:47           ` Chris Murphy
2014-06-23  2:10             ` Duncan
2014-06-23 12:24               ` Martin K. Petersen
2014-06-24  5:37                 ` Duncan
2014-06-25 13:01                 ` Imran Geriskovan
2014-06-25 16:01                   ` Duncan
2014-06-26 18:26                     ` Imran Geriskovan
2014-06-26 18:41                   ` Chris Murphy
2014-06-26 20:46                     ` Imran Geriskovan [this message]
2014-06-22 18:31         ` Chris Murphy
2014-06-23 11:34           ` Martin K. Petersen
2014-06-19  1:01 ` George Mitchell
2014-06-19  4:52   ` Russell Coker

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=CAK5rZE5VEKJbt7JJpOPD48sZMZPwLgiQC869+hy3toU+0HCKCA@mail.gmail.com \
    --to=imran.geriskovan@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    /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.