From: Gordan Bobic <gordan@bobich.net>
To: <linux-btrfs@vger.kernel.org>
Subject: Re: SSD Optimizations
Date: Thu, 11 Mar 2010 11:59:32 +0000 [thread overview]
Message-ID: <f8e55948796fc6d3de67e18eb3b06807@localhost> (raw)
In-Reply-To: <20100311073853.GA26129@attic.humilis.net>
On Thu, 11 Mar 2010 08:38:53 +0100, Sander <sander@humilis.net> wrote:
>> >>Are there options available comparable to ext2/ext3 to help reduce
>> >>wear and improve performance?
>
> With SSDs you don't have to worry about wear.
And if you believe that you clearly swallowed the marketing spiel hook
line and sinker without enough real world exprience to show you otherwise.
But I'm not going to go off on a tangent now enumerating various victories
of marketing over mathematics and empirical evidence relating to currently
popular technologies.
In short - I have several dead SSDs of various denominations that
demonstrate otherwise - and all within their warranty period, and not
having been used in pathologically write-heavy environments. You do have to
worry about wear. Operations that increase wear also reduce speed (erasing
a block is slow, and if the disk is fully tainted you cannot write without
erasing), so you doubly have to worry about it.
Also remember that hardware sectors are 512 bytes, and FS blocks tend to
be 4096 bytes. It is thus entirely plausible that if you aren't careful
you'll end up with blocks straddling two erase block boundaries. If that
happens, you'll make wear twice as bad because you are facing a situation
where you may need to erase and write two blocks rather than one. Half the
performance, twice the wear.
>> And while I appreciate hopeful remarks along the lines of "I think
>> you'll get more out of btrfs", I am really after specifics of what
>> the ssd mount option does, and what features comparable to the
>> optimizations that can be done with ext2/3/4 (e.g. the mentioned
>> stripe-width option) are available to get the best possible
>> alignment of data and metadata to increase both performance and life
>> expectancy of a SSD.
>
> Alignment is about the partition, not the fs, and thus taken care of
> with fdisk and the like.
>
> If you don't create a partition, the fs is aligned with the SSD.
I'm talking about internal FS data structures, not the partition
alignment.
>> Also, for drives that don't support TRIM, is there a way to make the
>> FS apply aggressive re-use of erased space (in order to help the
>> drive's internal wear-leveling)?
>
> TRIM has nothing to do with wear-leveling (although it helps reducing
> wear).
That's self contradictory. If it helps reduce wear it has something to do
with wear leveling.
> TRIM lets the OS tell the disk which blocks are not in use anymore, and
> thus don't have to be copied during a rewrite of the blocks.
> Wear-leveling is the SSD making sure all blocks are more or less equally
> written to avoid continuous load on the same blocks.
And thus it is impossible to do wear leveling when all blocks have been
written to once without TRIM. So I'd say that in the long term, without
TRIM there is no wear leveling. That makes them pretty related.
So considering that there are various nuggets of opinion floating around
(correct or otherwise) saying that ext4 has support for TRIM, I'd like to
know whether there similar support in BTRFS at the moment?
Gordan
next prev parent reply other threads:[~2010-03-11 11:59 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-10 19:49 SSD Optimizations Gordan Bobic
2010-03-10 21:14 ` Marcus Fritzsch
2010-03-10 21:22 ` Marcus Fritzsch
2010-03-10 23:13 ` Gordan Bobic
2010-03-11 10:35 ` Daniel J Blueman
2010-03-11 12:03 ` Gordan Bobic
2010-03-10 23:12 ` Mike Fedyk
2010-03-10 23:22 ` Gordan Bobic
2010-03-11 7:38 ` Sander
2010-03-11 10:59 ` Hubert Kario
2010-03-11 11:31 ` Stephan von Krawczynski
2010-03-11 12:17 ` Gordan Bobic
2010-03-11 12:59 ` Stephan von Krawczynski
2010-03-11 13:20 ` Gordan Bobic
2010-03-11 14:01 ` Hubert Kario
2010-03-11 15:35 ` Stephan von Krawczynski
2010-03-11 16:03 ` Gordan Bobic
2010-03-11 16:19 ` Chris Mason
2010-03-12 1:07 ` Hubert Kario
2010-03-12 1:42 ` Chris Mason
2010-03-12 9:15 ` Stephan von Krawczynski
2010-03-12 16:00 ` Hubert Kario
2010-03-13 17:02 ` Stephan von Krawczynski
2010-03-13 19:01 ` Hubert Kario
2010-03-11 16:48 ` Martin K. Petersen
2010-03-11 14:39 ` Sander
2010-03-11 17:35 ` Stephan von Krawczynski
2010-03-11 18:00 ` Chris Mason
2010-03-13 16:43 ` Stephan von Krawczynski
2010-03-13 19:41 ` Hubert Kario
2010-03-13 21:48 ` Chris Mason
2010-03-14 3:19 ` Jeremy Fitzhardinge
2010-03-11 12:09 ` Gordan Bobic
2010-03-11 16:22 ` Martin K. Petersen
2010-03-11 11:59 ` Gordan Bobic [this message]
2010-03-11 15:59 ` Asdo
[not found] ` <4B98F350.6080804@shiftmail.org>
2010-03-11 16:15 ` Gordan Bobic
2010-03-11 14:21 ` Chris Mason
2010-03-11 16:18 ` Gordan Bobic
2010-03-11 16:29 ` Chris Mason
-- strict thread matches above, loose matches on Subject: below --
2010-12-12 17:24 SSD optimizations Paddy Steed
2010-12-13 0:04 ` Gordan Bobic
2010-12-13 5:11 ` Sander
2010-12-13 9:25 ` Gordan Bobic
2010-12-13 14:33 ` Peter Harris
2010-12-13 15:04 ` Gordan Bobic
2010-12-13 15:17 ` cwillu
2010-12-13 16:48 ` Gordan Bobic
2010-12-13 17:17 ` Paddy Steed
2010-12-13 17:47 ` Gordan Bobic
2010-12-13 18:20 ` Tomasz Torcz
2010-12-13 19:34 ` Ric Wheeler
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=f8e55948796fc6d3de67e18eb3b06807@localhost \
--to=gordan@bobich.net \
--cc=linux-btrfs@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).