On Sat, Dec 27, 2008 at 8:23 PM, Randall R Schulz
On Saturday 27 December 2008 16:03, James Knott wrote:
...
With that, you raise the question of how often you write vs read.
Well, it is a pattern observed in all information processing that reads outnumber writes at all levels (CPU registers, level-1 and level-2 cache, RAM and secondary storage), but that does not change the fact that flash-based secondary storage cannot sustain as many write cycles as rotating magnetic media. To date, fancy redundancy schemes are required to balance the read / write cycle limits in flash-RAM devices when used as secondary storage devices.
Finally read this thread. The subject was left far behind. First, the earlier parts of the discussion seemed to assume most hard drive failures are caused by head crashes. We do disk recovery as part of our services. Our experience is that most failures are in the electronics of the drive, not the mechanical part. If you read the Google whitepaper on disk drive reliability, they conclude that disk drives fail independent of disk usage, so I really think the conceptual idea of having a limited number of disks writes is a very minor issue compared with drives failing just because electronics routinely fail after a period of time. As to the SSD discussion: I find it really interesting and I do suspect it is where we are headed. The linux kernel now has SSD support built into some of the filesystems. (ext3?, others?) The way it works is really cool to me. First the hardware side: When a SSD is new, the onboard electronics knows that none of the sectors are in use. When a sector is written to, the onboard electronics note the fact by removing them from the "free" list. Not only is that tracked but the number of times a sector has been written is also tracked. So when you go to update a commonly used sector (ie. the filesystem superblock) the wear-leveling algorithm says, I'm going to remap that sector to a lesser used sector, lets see what I have in the free list that has the least number of writes. Thus when you write to a sector, you are always providing just a logical sector id and have no idea which physical sectors are really being written. That all happens in hardware and I don't think requires any kernel support, but as you think about it, you start to wonder how sectors that are freed at the filesystem level get freed at the SSD hardware level for reuse. In particular I had considered that case of doing a disk wipe. Once you do that, the SSD should see all the sectors as used, so the wear-leveling algorithm should quit working from that point forward. And that is where the kernel side kicks in: That answer is that the ATA spec has been extended to support a "discard" command. And the linux kernel is adding support in various filesystems to invoke discard on any sectors that become free due to file deletion, etc. The end result is that those limited write cycles get to be spread across all of the "free" SSD sectors. That also means you will not want to use a SSD in such a way that it stays mostly full, but that a small part of the data is constantly changing. Aiui, that would cause the SSD to churn through the small number of free sectors very quickly and use up their limited write-cycles. I don't know if strategies to address this are in place yet. And I don't think the actual wear-leveling algorithms are public knowledge, so it is just guess work how this all works in detail. FYI: For those saying, what is OpenSUSE 10.3 lacking that would cause me to upgrade. If you want to use SSD storage, I suspect you will need a newer kernel than 10.3 offers. In reality you will need to research when SSD discard support was added to your filesystem of choice and then be sure you have a kernel new enough to have it. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org