@blackhawk192 - unfortunately it's clear you're a Linux supporter, as well that you don't have a full understanding of the underlying technology in today's x86/64 systems.
Sorry, do be a Linux supporter, I am too, there's nothing wrong with that.
But understand thoroughly before trying to defend your beloved OS.
http://ubuntuforums.org/showthread.php?t=1368737
http://forums.fedoraforum.org/showthread.php?t=232773
^2 very common builds of Linux talking about steps in how to defragment your EXT4 OS volume. You are absolutely correct that EXT4 prevents fragmentation much better than NTFS (as you say, "
EXT4 is a better librarian). But it's the nature of the beast (HDD) that fragmentation is going to exist and hinder performance, no matter what file system you place on that antiquated medium (HDD).
Secondly, fragmentation on an SSD is not a "good" thing or "bad" thing. It simply does not matter. All the cells are accessed at the same rate and time
This is how I could tell you don't understand the underlying technology - SSD Fragmentation is done by design in the controller (same with DRAM and its counterpart the memory controller). I wasn't terribly clear in my earlier post, but will clarify here. All NAND chips in an SSD are absolutely NOT accessed at the same time, the controller isn't that powerful (yet). The very first SSDs were 4 channels, today 8/10 channels are common in the fastest of SSDs, with 16 being seen in about ~12mo from now. All of these channels can be accessed simultaneously, but each channel has 2 - 8 NAND chips daisy chained to it in order to achieve the 100's of GB seen today as well as give you the throughput to now out pace HDDs (your higher end drives are using 128Gbit (16GB) NAND devices (more than 1 die)... e.g., a 320GB drive will have at least 20 NAND devices on it - but most likely there will be extra GB for "wearleveling overhead").
Intel's 200GB 710 torn down. You can think of these channels as a quazi-RAID, as the controller is going to break-up files into pages in order to stripe them across all available channels. But when the controller needs to switch between chip A and chip B in a given channel you will see a couple ns lag. However this lag pales in comparison to the several ms of lag a HDD experiences when it needs to shift locations. This principle applies when talking about DRAM modules, and why it's always advised to only populate the first socket of each channel, and populating the second & third socket of the channels reduces performance ever so slightly.
My point, DRAM and NAND controllers split pages across different chips (fragmentation), in a RAID-0-esque fashion to increase/optimize performance. If this didn't happen, your SSD might pull off a whopping 30-50MB/s R/W.
So, fragmentation, in it's basic sense, is a good thing for everything except HDDs.
In addition, RAID with SSD's does not improve access times. It only helps sequential read and write speeds as far as I know (which can be achieved extremely high if you have enough HDD's). An SSD's access time is so miniscule that the overhead of a raid controller and two SSD's which just slow down access times.
Correct and incorrect.
Correct: 2 drives in a RAID result in minuscule performance increases. But this statement applies to HDD and SSD alike. Most performance gains in a 2 drive HDD RAID is the access time, but those gains are questionable in it's worthiness given all the headaches associated with RAIDs.
Incorrect: Because SSDs and HDDs scale similarly in RAID environments. This is demonstrated in enterprise grade tiered storage solutions which explicitly use SSDs for a newly created "Tier 0". It's access and throughput performance scales incredibly when you throw a whole mess of SSDs in a RAID10/5/50/6/60. The scaleability trend of SSD mimics that of HDDs in RAID configurations, but the end results of an SSD vs HDD resembles Tesla motors racing a Model-T in the Nuremberg Trials.