linux-kernel - Re: Debugging system freezes on filesystem writes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130226221723.GC27235@thunk.org>
Date:	Tue, 26 Feb 2013 17:17:23 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Marcus Sundman <marcus@...ox.fi>
Cc:	Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.cz>,
	linux-kernel@...r.kernel.org
Subject: Re: Debugging system freezes on filesystem writes

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/