FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 08-26-2012, 11:53 AM
Volker Armin Hemmann
 
Default SSD performance tweaking

Am Sonntag, 26. August 2012, 13:41:09 schrieb Alex Schuster:
> Frank Steinmetzger writes:
> > On Thu, Aug 23, 2012 at 12:15:20PM +0200, Alex Schuster wrote:
> >> The size of an erasable block of SSDs is even larger, usually 512K, it
> >> would be best to align to that, too. A partition offset of 512K or 1M
> >> would avoid this.
> >
> > Unless the filesystem knows this and starts bigger files at those 512 k
> > boundaries (so really only one erase cycle is needed for files <=512 k),
> > isn't this fairly superfluous?
>
> Yes, I think it is. When you search for SSD alignment, you read about
> this alignment all the time, even on the German Wikipedia, and many
> resources say that this can have a big impact on performance. But I
> could not find a real explanation at all.
>
> Besides that, it's not so easy to do the alignment, at least when using
> LVM. I read that LVM adds 192K header information, so even if you align
> the partition start to an erasable block size of 512K, the actual
> content is not aligned. See[*] for information how to overcome this.
> That is, if you believe the alignment to erasable blocks is important,
> personally I do not know what to think now. It wouldn't hurt, so why not
> apply it, but it seems like snake oil to me now.
>
> Wonko
>
> http://tytso.livejournal.com/2009/02/20/

because erasing is slow. You can not overwrite data on a ssd. you have to
erase first, then reprogramm. Also, erasing shortens lifetime.

--
#163933
 
Old 08-26-2012, 12:49 PM
Alex Schuster
 
Default SSD performance tweaking

Volker Armin Hemmann writes:


Am Sonntag, 26. August 2012, 13:41:09 schrieb Alex Schuster:

Frank Steinmetzger writes:



Unless the filesystem knows this and starts bigger files at those 512 k
boundaries (so really only one erase cycle is needed for files <=512 k),
isn't this fairly superfluous?


Yes, I think it is. When you search for SSD alignment, you read about
this alignment all the time, even on the German Wikipedia, and many
resources say that this can have a big impact on performance. But I
could not find a real explanation at all.

Besides that, it's not so easy to do the alignment, at least when using
LVM. I read that LVM adds 192K header information, so even if you align
the partition start to an erasable block size of 512K, the actual
content is not aligned. See[*] for information how to overcome this.
That is, if you believe the alignment to erasable blocks is important,
personally I do not know what to think now. It wouldn't hurt, so why not
apply it, but it seems like snake oil to me now.

Wonko

http://tytso.livejournal.com/2009/02/20/


because erasing is slow. You can not overwrite data on a ssd. you have to
erase first, then reprogramm. Also, erasing shortens lifetime.


Yes, I know that. But why exactly does it help to align a partition to
the erasable block size? I don't get it. Why isn't it sufficient to
align to the usual 4K block size, so that a block never spans over two
erasable blocks?


Wonko
 
Old 08-26-2012, 12:54 PM
Allan Gottlieb
 
Default SSD performance tweaking

On Sat, Aug 25 2012, Frank Steinmetzger wrote:

> On Sun, Aug 26, 2012 at 12:22:47AM +0200, Volker Armin Hemmann wrote:
>
>> > > The size of an erasable block of SSDs is even larger, usually 512K, it
>> > > would be best to align to that, too. A partition offset of 512K or 1M
>> > > would avoid this.
>> >
>> > Unless the filesystem knows this and starts bigger files at those 512 k
>> > boundaries (so really only one erase cycle is needed for files <=512 k),
>> > isn't this fairly superfluous?
>>
>> no, if you misalign, a lot of 4k blocks might span into two erase blocks.
>> Which is bad. If you align correctly, you will never cross them unnecessary,
>> sparing your SSD some unnecessary writes and improving overall performance.
>
> I don’t quite follow. If you align to 4k, then you are also aligned to 512k,
> because 512 % 4 = 0.

Backwards. Consider starting at 8K. This is a multiple of 4K but is
not a multiple of 512K.

If you align to 512k than you are also aligned to 4k because 512 % 4 =
0.

allan
 
Old 08-26-2012, 02:21 PM
Volker Armin Hemmann
 
Default SSD performance tweaking

Am Sonntag, 26. August 2012, 14:49:08 schrieb Alex Schuster:
> Volker Armin Hemmann writes:
> > Am Sonntag, 26. August 2012, 13:41:09 schrieb Alex Schuster:
> >> Frank Steinmetzger writes:
> >>> Unless the filesystem knows this and starts bigger files at those 512 k
> >>> boundaries (so really only one erase cycle is needed for files <=512 k),
> >>> isn't this fairly superfluous?
> >>
> >> Yes, I think it is. When you search for SSD alignment, you read about
> >> this alignment all the time, even on the German Wikipedia, and many
> >> resources say that this can have a big impact on performance. But I
> >> could not find a real explanation at all.
> >>
> >> Besides that, it's not so easy to do the alignment, at least when using
> >> LVM. I read that LVM adds 192K header information, so even if you align
> >> the partition start to an erasable block size of 512K, the actual
> >> content is not aligned. See[*] for information how to overcome this.
> >> That is, if you believe the alignment to erasable blocks is important,
> >> personally I do not know what to think now. It wouldn't hurt, so why not
> >> apply it, but it seems like snake oil to me now.
> >>
> >> Wonko
> >>
> >> http://tytso.livejournal.com/2009/02/20/
> >
> > because erasing is slow. You can not overwrite data on a ssd. you have to
> > erase first, then reprogramm. Also, erasing shortens lifetime.
>
> Yes, I know that. But why exactly does it help to align a partition to
> the erasable block size? I don't get it. Why isn't it sufficient to
> align to the usual 4K block size, so that a block never spans over two
> erasable blocks?

well, for one, there are lots of ssd which have 8k pages. Not 4k.


--
#163933
 
Old 08-26-2012, 04:14 PM
Alex Schuster
 
Default SSD performance tweaking

Am 26.08.2012 16:21, schrieb Volker Armin Hemmann:

Am Sonntag, 26. August 2012, 14:49:08 schrieb Alex Schuster:

Volker Armin Hemmann writes:

Am Sonntag, 26. August 2012, 13:41:09 schrieb Alex Schuster:



Yes, I know that. But why exactly does it help to align a partition to
the erasable block size? I don't get it. Why isn't it sufficient to
align to the usual 4K block size, so that a block never spans over two
erasable blocks?


well, for one, there are lots of ssd which have 8k pages. Not 4k.


Whatever. Then align to 8K instead. But what does this have to do with
the erasable page size?


Wonko
 
Old 08-26-2012, 04:35 PM
Volker Armin Hemmann
 
Default SSD performance tweaking

Am Sonntag, 26. August 2012, 18:14:51 schrieb Alex Schuster:
> Am 26.08.2012 16:21, schrieb Volker Armin Hemmann:
> > Am Sonntag, 26. August 2012, 14:49:08 schrieb Alex Schuster:
> >> Volker Armin Hemmann writes:
> >>> Am Sonntag, 26. August 2012, 13:41:09 schrieb Alex Schuster:
> >> Yes, I know that. But why exactly does it help to align a partition to
> >> the erasable block size? I don't get it. Why isn't it sufficient to
> >> align to the usual 4K block size, so that a block never spans over two
> >> erasable blocks?
> >
> > well, for one, there are lots of ssd which have 8k pages. Not 4k.
>
> Whatever. Then align to 8K instead. But what does this have to do with
> the erasable page size?
>

erasable BLOCK size is the imporant think. PAGE size (4 or 8K) not so much.
Because every write comes down to ERASE-WRITE.

So you want to align to ERASE BLOCKS and not so much pages.

--
#163933
 
Old 08-26-2012, 08:49 PM
Neil Bothwick
 
Default SSD performance tweaking

On Sun, 26 Aug 2012 13:41:09 +0200, Alex Schuster wrote:

> Besides that, it's not so easy to do the alignment, at least when using
> LVM. I read that LVM adds 192K header information, so even if you align
> the partition start to an erasable block size of 512K, the actual
> content is not aligned. See[*] for information how to overcome this.
> That is, if you believe the alignment to erasable blocks is important,
> personally I do not know what to think now. It wouldn't hurt, so why
> not apply it, but it seems like snake oil to me now.
>
> Wonko
>
> http://tytso.livejournal.com/2009/02/20/

I think that may be out of date. I read that but then found somewhere
that LVM now uses MiB alignment.


--
Neil Bothwick

When there's a will, I want to be in it.
 
Old 08-27-2012, 03:58 PM
Paul Hartman
 
Default SSD performance tweaking

On Sun, Aug 26, 2012 at 11:14 AM, Alex Schuster <wonko@wonkology.org> wrote:
> Whatever. Then align to 8K instead. But what does this have to do with the
> erasable page size?

Short answer: Any page written to a block already containing data, the
whole block must be erased. This is the "erase block size" people talk
about. Block size is always divisible by page size. So if you align to
the erase block size, you will always be okay.

Long answer: NAND flash cells do not operate like a normal HDD
storage, they can only be written to when they are empty. Empty
meaning null, devoid of data, unallocated, not just "filled with
zeroes" or "ignored by filesystem". So, any time you want to write to
a block that already contains data, it must be erased and re-written
by the drive controller.

On most current-generation SSD the block size is 512k and contains 128
pages (4k each page). In older/slower SSD, or other kind of flash
devices like CompactFlash or SD cards, often the erase block is
larger, usually 4M or sometimes even up to 16M. (Definitely check the
specs for your specific model of SSD to find the correct values.)

SSD can write at page-size chunks of data, which is very fast, but
only in an empty block. So if the block has data, that data must be
relocated or erased and rewritten. TRIM feature tells the SSD that
these pages are not used anymore, and allows it to do better garbage
collection and combine pages/deallocate those unused blocks. Next time
you write to one of those blocks, it will be very fast because erase
already happened at TRIM time and these unused blocks are available
for writing.

This is why SSD without TRIM feature become slower once they have
filled up. The drive controller has no knowledge of your filesystem,
erase overhead is added to every write once the internal NAND free
space is used up. So instead of writing a 4k page now it's potentially
erasing 512k data then writing 512k data. 256 times more data touched
for the same 4k write! (For a case where you have no TRIM support the
only possible way to improve performance once a full drive worth of
data has been written is to backup, perform ATA Secure Erase, which
will clear the SSD allocation metadata, then restore your backup.)

Now imagine if the alignment is not correct for both page size and
erase block size, then when you write data it could overlap, causing
two blocks to be erased and written instead of only one. In the
example from the previous paragraph you can see now how the
performance degrades even worse, as well as causing extra erases and
writes which will potentially reduce the lifetime of your drive.

Additional complexity is added by any further layers, filesystem block
size, filesystem alignment (I'm looking at you, FAT32), LVM, RAID
stripe size, etc...

A good article giving more information about the subject is in the
English version of Wikipedia:
https://en.wikipedia.org/wiki/Write_amplification

(disclaimer: all above info is AFAIK, please correct me if I got any
facts or advice wrong)
 

Thread Tools




All times are GMT. The time now is 02:33 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org