public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Marcus Sundman <marcus@hibox.fi>
Cc: Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org
Subject: Re: Debugging system freezes on filesystem writes
Date: Tue, 26 Feb 2013 17:17:23 -0500	[thread overview]
Message-ID: <20130226221723.GC27235@thunk.org> (raw)
In-Reply-To: <512D01E0.7010009@hibox.fi>

On Tue, Feb 26, 2013 at 08:41:36PM +0200, Marcus Sundman wrote:
> 
> So, after reading up a bit on this trimming I'm thinking maybe my
> filesystem's block sizes don't match up with my SSD's blocks (or
> whatever its write unit is called). Then writing a FS block would
> always write to multiple SSD blocks, causing multiple
> read-erase-write sequences, right? So how can I check this, and how
> can I make the FS blocks match the SSD blocks?

The erase block size for SSD's is typically in the area of 2MB (that's
megabytes), with a page size of typically 4k, 8k, or 16k.  So that
means that erases take place with a granularity of 2 megabytes, and
writes take place in chunks of the page size.  It's up to the Flash
Translation Layer to take the writes and map them to the NAND flash in
an efficient way.  This is the difference between high quality SSD's
and really crappy SSD's.  One of the best ways of measuring how good
your SSD is to do random 4k write test, and see how well it handles a
random write workload.  I'm guessing you have a SSD which is really
terrible at this.

In general you don't need to worry about alignment for most SSD's
(eMMC/SD devices are a different story) since historically, Windows
systems had partition offset by 63 (512 byte) sectors, which is the
worst possible alignment.  So SSD's in general can handle misaligned
writes without any problems, or otherwise on Windows XP systems, their
performance would be really crappy.  SD card or eMMC devices don't
deal with this well, so you need to worry about aligning your
partitions appropriately.  If your SSD is sensitive to partition
alrignment, then it truly is a really crappy SSD.  My suggestion to
you is that the next time you buy an SSD, take a look at the reviews
at web sites such as Anandtech, and in particular take a look at the
4k random write benchmark numbers and see how they compare with the
competition.

As far as what you should do with your current SSD, if it's really
that bad, I'm not sure I'd trust precious data on it, and I'd
seriously consider simply getting a new SSD if budget allows this.
Intel has historically does a really good job with their QA.  They
spent several months qual'ing the Sandforce controller, and so they
were late to the market as a result, and their SSDs are generally a
bit more expensive.  However, the agreement they signed with Sandforce
meant that the reliability/performance fixes in the Sandforce firmware
which were the result of Intel's extended QA period would remain
exclusive to Intel SSD's for some period of time and hence wouldn't be
available to their competition.  Guess which manufacturer's SSDs I
generally tend to buy?  :-)

Regards,

						- Ted

  reply	other threads:[~2013-02-26 22:18 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-28 22:39 Debugging system freezes on filesystem writes Marcus Sundman
2012-11-01 19:01 ` Jan Kara
2012-11-02  2:19   ` Marcus Sundman
2012-11-07 16:17     ` Jan Kara
2012-11-08 23:41       ` Marcus Sundman
2012-11-09 13:12         ` Marcus Sundman
2012-11-13 13:51           ` Jan Kara
2012-11-16  1:11             ` Marcus Sundman
2012-11-21 23:30               ` Jan Kara
2012-11-27 16:14                 ` Marcus Sundman
2012-12-05 15:32                   ` Jan Kara
2013-02-20  8:42                     ` Marcus Sundman
2013-02-20 11:40                       ` Marcus Sundman
2013-02-22 20:51                         ` Jan Kara
2013-02-22 23:27                           ` Marcus Sundman
2013-02-24  0:12                             ` Dave Chinner
2013-02-24  1:20                               ` Theodore Ts'o
2013-02-26 18:41                                 ` Marcus Sundman
2013-02-26 22:17                                   ` Theodore Ts'o [this message]
2013-02-26 23:17                                   ` Jan Kara
2013-09-12 12:57                                     ` Marcus Sundman
2013-09-12 13:10                                       ` Jan Kara
2013-09-12 13:47                                         ` Marcus Sundman
2013-09-12 14:39                                           ` Jan Kara
2013-09-12 15:08                                             ` Marcus Sundman
2013-09-12 16:35                                               ` Jan Kara
2013-09-12 17:59                                                 ` Marcus Sundman
2013-09-12 20:46                                                   ` Jan Kara
2013-09-13  6:35                                                     ` Marcus Sundman
2013-09-13 20:54                                                       ` Jan Kara
2013-09-14  2:41                                                   ` Theodore Ts'o
2013-09-15 19:19                                                     ` Marcus Sundman
2013-09-16  0:06                                                       ` Theodore Ts'o
2013-02-25 13:05                             ` Jan Kara

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=20130226221723.GC27235@thunk.org \
    --to=tytso@mit.edu \
    --cc=david@fromorbit.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcus@hibox.fi \
    /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