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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ff3dcb6.6000...@hardwarefreak.com