On Tue, 2010-06-08 at 15:48 -0700, David Rees wrote: > On Mon, Jun 7, 2010 at 9:54 PM, Ian Dall <ian@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 2010-06-07 at 15:14 -0400, Bill Davidsen wrote: > >> Actually playing with that now. I got an Intel SATA 40GB SSD, and I am > >> trying various combinations of things to put on it. One thing which I > >> hoped would benefit was to put a f/s journal on SSD and then use the > >> option to push all through the journal (data=journal) in hopes that it > >> would then free the RAM needed for cache and thus speed operation. > >> > >> Since none of that has generated the performance I hoped, > > > > Interesting. If its the X25-V that you have, write performance is > > nothing to write home about even compared to a single hard drive, let > > alone a raid. By journaling data as well (as metadata), you just add > > extra write overhead, possibly even a new bottleneck. > > Depends on whether you are talking about small, seeky writes or large > writes. Even the X25-V will kill any rotating drive in small seeky > writes, Of course, low (almost 0) seek time it the forte of SSD disks, which is why, is seems to me, swap would be an ideal application. I may be wrong about that, but I imagine that paging is a kind of semi random pattern. > >> I also played with mirroring and write mostly, etc. Does provide a > >> general solution, at least in my tests. > > > > Do you mean "does NOT"? > > write-mostly DOES work well in my tests... Ah! My understanding of "write-mostly" it that it is used in a mirror (raid 0), which means that you need enough SSD to store your entire filesystem, and the rotating disk is just redundancy. So: capacity=capacity of SSD, speed ~= speed of SSD (until write behind queue is full), probability of failure ~= P(Fail SSD)*P(Fail rotating media). If the reliability of SSD is good enough (I don't know), is this much of a win? Regards, Ian -- Ian Dall <ian@xxxxxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
