Re: Current SSD setup recommendations for laptop with Debian
On 7/3/2012 10:22 PM, T o n g wrote:
> On Tue, 03 Jul 2012 18:32:45 -0500, Stan Hoeppner wrote:
>
>> If you fall into camp #2, well,
>> you'll continue wasting massive amounts of time trying to figure out how
>> to "perfectly" setup your SSD.
>
> That's kind of harsh.
Look around. The world isn't coated with sugar.
> On the other hand, I found your replied info very helpful.
People often need to be presented with a healthy dose of realism--what
you call "harsh".
Once the OP asked about "alignment" I knew he needed a dose. This
refers to "erase block alignment". I'll not bother to explain it here
as many articles have been written on the subject. I will simply state
that attempting to achieve it is a massive waste of time, and only hard
core tweakers bother with it. The same goes for using TRIM.
Why is it a waste of time? Because manufacturers don't publish their
erase block size, for one, nor a whole host of other internal parameters
that dictate the functioning of the device. Add the fact that some
controllers (e.g. Indilinx vs SandForce) behave differently in the way
they stripe, or don't stripe, data across the individual flash chips in
the device.
To do "alignment" correctly one must know how many flash chips are in
the device and how the controller stripes writes, of what size, to each
chip. With an 8 chip SSD, one controller may have a shared bus for each
set of two chips, striping to 4 chips simultaneously. Another
controller may have 8 buses, striping all 8 simultaneously. A very fast
SSD may have 16 chips and 16 buses. No manufacturer makes this type of
data available to the customer. Thus you have to read reviews of your
SSD device at places like Anandtech, to do proper alignment.
Again, at the end of the day, the OP in this thread will notice ZERO
performance difference whether he wastes his time on things like erase
block alignment and TRIM, which is another can of worms. Real time TRIM
or batch TRIM? The XFS devs recommend batch TRIM with a cron job,
because real time TRIM kills performance, with the current Linux
implementation of real time TRIM support. So we've come full circle.
Camp #1 or camp #2?
My original "harsh" response got the point across with about 1000 less
characters. Replace harsh with "direct" or "no bullshit".
--
Stan
Reply to: