SSD format/mount parameters questions

SSD format/mount parameters questions

[Martin]

For using SSDs:

Are there any format/mount parameters that should be set for using btrfs
on SSDs (other than the "ssd" mount option)?


General questions:

How long is the 'delay' for the delayed alloc?

Are file allocations aligned to 4kiB boundaries, or larger?

What byte value is used to pad unused space?

(Aside: For some, the erased state reads all 0x00, and for others the
erased state reads all 0xff.)


Background:

I've got a mix of various 120/128GB SSDs to newly set up. I will be
using ext4 on the critical ones, but also wish to compare with btrfs...

The mix includes some SSDs with the Sandforce controller that implements
its own data compression and data deduplication. How well does btrfs fit
with those compared to other non-data-compression controllers?


Regards,
Martin

Re: SSD format/mount parameters questions

[Sander]

Martin wrote (ao):
> Are there any format/mount parameters that should be set for using
> btrfs on SSDs (other than the "ssd" mount option)?

If possible, format the whole device, do not partition the ssd. This
will guarantee proper allignment.

The kernel will detect the ssd, and apply the ssd mount option
automatically.

> I've got a mix of various 120/128GB SSDs to newly set up. I will be
> using ext4 on the critical ones, but also wish to compare with
> btrfs...

I would use btrfs on the critical ones, as btrfs has checksums to detect
datacorruption.

> The mix includes some SSDs with the Sandforce controller that implements
> its own data compression and data deduplication. How well does btrfs fit
> with those compared to other non-data-compression controllers?

Since you have them both, you might want to find out yourself, and let
us know ;-)

FWIW (not much, as you already have them), I would not buy anything else
than intel. I have about 26 of them for years now (both in servers and
workstations, several series), and never had an issue. Two of my
colleagues have OCZ, and both had to RMA them.

	Sander

Re: SSD format/mount parameters questions

[Clemens Eisserer]

> I would not buy anything else
> than intel. I have about 26 of them for years now (both in servers and
> workstations, several series), and never had an issue. Two of my
> colleagues have OCZ, and both had to RMA them.

I guess it boils down wether you want intel also to rule the SSD
market in the long term, as they do with PC processors...

Comparing intel SSDs with OCZ is not that fair, as OCZ has always been
low-priced bleeding edge stuff.
Usually ratings at Amazon are a good indicator how reliable the
product in question is.

Re: SSD format/mount parameters questions

[Tomasz Torcz]

On Fri, May 18, 2012 at 05:08:33PM +0200, Clemens Eisserer wrote:
> > I would not buy anything else
> > than intel. I have about 26 of them for years now (both in servers and
> > workstations, several series), and never had an issue. Two of my
> > colleagues have OCZ, and both had to RMA them.
> 
> I guess it boils down wether you want intel also to rule the SSD
> market in the long term, as they do with PC processors...
> 
> Comparing intel SSDs with OCZ is not that fair, as OCZ has always been
> low-priced bleeding edge stuff.

  Looking into the controllers...
  first there were bunch of different ones; Intel had it own design with
SSD 320.
  Then come Sandforce; it got broadly used, despite sucking when used
with FDE. Even Intel started to used Sandforce - SSD 520. How's
reliabilty of Intel differs?
  Latest fad is Marvell controller; again Intel joins the pack with SSD510.

  So, Intel is not that different anymore.

-- 
Tomasz Torcz                 "God, root, what's the difference?"
xmpp: zdzichubg@chrome.pl         "God is more forgiving."

Re: SSD format/mount parameters questions

[Calvin Walton]

On Fri, 2012-05-18 at 17:32 +0200, Tomasz Torcz wrote:
> On Fri, May 18, 2012 at 05:08:33PM +0200, Clemens Eisserer wrote:
> > > I would not buy anything else
> > > than intel. I have about 26 of them for years now (both in servers and
> > > workstations, several series), and never had an issue. Two of my
> > > colleagues have OCZ, and both had to RMA them.
> > 
> > I guess it boils down wether you want intel also to rule the SSD
> > market in the long term, as they do with PC processors...
> > 
> > Comparing intel SSDs with OCZ is not that fair, as OCZ has always been
> > low-priced bleeding edge stuff.
> 
>   Looking into the controllers...
>   first there were bunch of different ones; Intel had it own design with
> SSD 320.
>   Then come Sandforce; it got broadly used, despite sucking when used
> with FDE. Even Intel started to used Sandforce - SSD 520. How's
> reliabilty of Intel differs?
>   Latest fad is Marvell controller; again Intel joins the pack with SSD510.
> 
>   So, Intel is not that different anymore.

The controllers themselves really aren't that interesting any more - an
SSD controller is really just an ARM or MIPS core with some flash
interfaces, a SATA interface, and some ram - running proprietary
firmware.

Several of the Marvell devices actually have completely different
firmwares (e.g. Intel's firmware for Marvell devices was reportedly
developed by them in-house), and Intel's Sandforce firmware has some
customizations for improved reliability, at the expense of some speed.

-- 
Calvin Walton <calvin.walton@kepstin.ca>

Re: SSD format/mount parameters questions

[Martin Steigerwald]

Am Freitag, 18. Mai 2012 schrieb Sander:
> Martin wrote (ao):
> > Are there any format/mount parameters that should be set for using
> > btrfs on SSDs (other than the "ssd" mount option)?
> 
> If possible, format the whole device, do not partition the ssd. This
> will guarantee proper allignment.

Current partitioning tools align at 1 MiB unless otherwise specified.

And then thats only the alignment of the start of the filesystem.

Not the granularity that the filesystem itself uses to align its writes.

And then its not clear to me what effect proper alignment will actually 
have given the intelligent nature of SSD firmwares.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: SSD format/mount parameters questions

[Martin]

On 19/05/12 18:36, Martin Steigerwald wrote:
> Am Freitag, 18. Mai 2012 schrieb Sander:
>> Martin wrote (ao):
>>> Are there any format/mount parameters that should be set for using
>>> btrfs on SSDs (other than the "ssd" mount option)?
>>
>> If possible, format the whole device, do not partition the ssd. This
>> will guarantee proper allignment.
> 
> Current partitioning tools align at 1 MiB unless otherwise specified.
> 
> And then thats only the alignment of the start of the filesystem.
> 
> Not the granularity that the filesystem itself uses to align its writes.
> 
> And then its not clear to me what effect proper alignment will actually 
> have given the intelligent nature of SSD firmwares.

That's what I'm trying to untangle rather than just trusting to "magic".
I'm also not so convinced about the "SSD firmwares" being quite so
"intelligent"...


So far, the only clear indications are that a number of SSDs have a
performance 'sweet spot' when you use 16kByte blocks for data transfer.

Practicalities for the SSD internal structure strongly suggest that they
work in chunks of data greater than 4kBytes.

4kByte operation is a strong driver for SSD manufacturers, but what
compromises do they make to accommodate that?


And for btrfs:

Extents are aligned to "sector size" boundaries (4kBytes default).

And there is a comment that setting larger sector sizes increases the
CPU overhead in btrfs due to the larger memory moves needed for making
inserts into the trees.

If the SSD is going to do a read-modify-write on anything smaller than
16kBytes in any case, might btrfs just as well use that chunk size to
good advantage in the first place?

So, what is most significant?


Also:

btrfs has a big advantage of using checksumming and COW. However, ext4
is more mature, similarly uses extents, and also allows specifying a
large "delayed allocation" time to merge multiple writes if you're happy
your system is safely on a UPS...


I'm not too worried about this for MLC SSDs, but it is something that is
of concern for the yet shorter modify-erase count lifespan of TLC SSDs.


Regards,
Martin