A few observations on this: On 6/23/2012 12:47 AM, Sam Varshavchik wrote: > ... > > Now, for this discussion, I've been looking at the solid state disk > industry, and its slow, but steady, progress. With the prevalence of > SSDs, there's going to come a point where the platter speed and > average seek times become less, and less important.
I think it will still be a few years before they reach the $/GB mark of magnetic storage, but it might be just 2 to 5 years into the future. > > When that happens, the winner's going to be whoever gets out of the > way faster, and doesn't diddle around too long, before sending your > bytes to the disk, and doesn't waste its time getting them back to > you. Because, diddling around, and trying to optimize your file > layout, and making sure stuff isn't fragmented on disk; all of that, > is not going to be as important as it's used to be, that's where I > think we'll end up soon. While the SSD industry is currently using "translation layers" that diddle around to hide the fundamental principles of SSD by emulating the interfaces of rotating platters, best performance from SSDs would need to work on the real world properties of such, and possibly some "inverse diddling" to compensate for inefficiencies in the "translation layers" on devices that cannot turn them off. Linux JFFS2 was a good early solution but may be optimized/limited to smaller capacities. Linux ext4 over translation layers may be the currently most common "cop out" solution, but consists of 3 layers, each optimized for a different situation. > > And I have to think that there's going to be a point at which the same > thing is going to apply at the higher levels in the stack. Meaning > that, if you're keeping index files around some sorts, and, trying to > optimize your calls into the filesystem, then there has to be a point > at which you're spending more time doing that, than what you actually > end up saving. In general yes, but one factor that remains is the need to compensate for lower layers that refuse to get out of the way, such as slow file systems, bus/network contention etc. Basic caching of stuff that happens to be slow to access on a given system (configurable or detected by measurement) is still a good technique, as long as you keep the cache much smaller than the full data set. Here the idea (allegedly in Dovecot) of caching the message and UID lists locally on each node rather than reconstructing it from the off-node maildir on each request seems a sane solution, regardless of file storage technology. > > But, that's just where I think the wind is blowing. I had no way of > knowing the emergence of SSDss, of course, a decade ago. It's a > relatively recent phenomenon. > -- Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 <call:+4531131610> This message is only for its intended recipient, delete if misaddressed. WiseMo - Remote Service Management for PCs, Phones and Embedded ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Courier-imap mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
