<?xml version="1.0" encoding="utf-8" ?>
<?xml-stylesheet href="" type="text/css"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:dcterms="http://purl.org/dc/terms/"
         xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
         xmlns:rss="http://purl.org/rss/1.0/"
         xmlns:content="http://purl.org/rss/1.0/modules/content/">

    <rss:channel rdf:about="http://www.cleversafe.org/cs-weblog">

        <rss:title>Blog</rss:title>
        <rss:link>http://www.cleversafe.org/cs-weblog</rss:link>

        
        <rss:description>Blog RSS 1.0 feed.</rss:description>

        <rss:image rdf:resource="http://www.cleversafe.org/logo.png"/>

        <sy:updatePeriod>daily</sy:updatePeriod>
        <sy:updateFrequency>1</sy:updateFrequency>

        <rss:items>
            <rdf:Seq>
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2008/08/04/ideas-for-new-dispersed-storage-capabilities"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2008/06/03/how-201cwide201d-will-dsnets-get"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2008/05/06/release-candidate-1.0-into-open-source"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2008/04/22/solid-state-drives-and-dispersed-storage"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2008/03/03/cleversafe-open-source-vs.-commercial"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2008/02/17/increasing-network-performance"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2008/01/24/even-faster-actual-performance"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2007/12/28/information-dispersal-performance"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2007/12/14/are-hard-drives-getting-slower"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2007/11/20/re-writing-vs.-modifying-software"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2007/11/01/out-of-the-box"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2007/10/19/what-would-you-do-with-a-five-hundred-million"/>
                
                
                <rdf:li rdf:resource="http://www.cleversafe.org/cs-weblog/2007/10/15/the-cleversafe-idea-1"/>
                
            </rdf:Seq>
        </rss:items>
    </rss:channel>

    <rss:image rdf:about="http://www.cleversafe.org/logo.png">
        <rss:title>Blog</rss:title>
        <rss:link>http://www.cleversafe.org/cs-weblog</rss:link>
        <rss:url>http://www.cleversafe.org/logo.png</rss:url>
    </rss:image>

    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2008/08/04/ideas-for-new-dispersed-storage-capabilities">

        <rss:title>Ideas for new Dispersed Storage Capabilities?</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2008/08/04/ideas-for-new-dispersed-storage-capabilities</rss:link>       

        <rss:description>If you have an idea for a new Dispersed Storage features, please let us know</rss:description>

        <content:encoded>
          <![CDATA[
          
<p>&nbsp;</p>
<p>With the completion of the 1.0.1 release, we have pretty
good code foundation on which to add additional features.&nbsp; We also have a 1.1.0 open source release
coming up which will address a number of issues – particularly performance on
globally dispersed (i.e. high latency) networks.</p>
<p>&nbsp;</p>
<p>As we continue add new features, I wanted to open up the
conversation for suggestions.&nbsp; So, let us
know if you have any ideas or suggestions for new capabilities to add to the
Dispersed Storage software.&nbsp; We’re
currently in the midst of a lot of future release planning, so the timing is
good for input.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>Chris</p>

          ]]>
        </content:encoded>        

        <dc:date>2008-08-04T16:02:13-04:00</dc:date>

        <dcterms:modified>2008-08-12T23:45:19-04:00</dcterms:modified>

        <dc:creator>cgladwin</dc:creator>

        

        
            <dc:subject>To Do List</dc:subject>
        
        
            <dc:subject>Dispersed Storage</dc:subject>
        
        
            <dc:subject>Software</dc:subject>
        
        
            <dc:subject>Participate</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2008/06/03/how-201cwide201d-will-dsnets-get">

        <rss:title>How “Wide” will dsNets get?</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2008/06/03/how-201cwide201d-will-dsnets-get</rss:link>       

        <rss:description>As the size of Dispersed Storage Networks in operation grow larger, what is the optimum maximum number of Slices for each data element stored on the dsNet?</rss:description>

        <content:encoded>
          <![CDATA[
          
<p><strong>&nbsp;As the size of Dispersed Storage Networks in operation grow larger, what is the optimum maximum number of Slices for each data element stored on the dsNet?</strong></p>
<p>The <a title="Glossary" class="internal-link" href="/documentation/glossary#W">“Width” </a>of a <a title="Glossary" class="internal-link" href="/documentation/glossary#V">“Vault” </a>on a dsNet determines the number of
dispersed <a title="Glossary" class="internal-link" href="/documentation/glossary#S">Slices</a> that are physically stored for each data element in that vault.&nbsp; For example, a typical block interface
typically uses 4K blocks, so the dsNet block interface presents an interface
that stores and retrieves 4K blocks.&nbsp; (The<a title="Interfaces" class="internal-link" href="/dispersed-storage/interfaces#W">
dsNet iSCSI target </a>uses this block interface.)</p>
<p>When storing a 4K block, the dsNet creates a number of
slices equal to the width set for the associated vault on the dsNet.&nbsp; Each of these slices are then typically
stored on different <a class="external-link" href="http://www.cleversafe.com/products/slicestor">Slicestors</a>.&nbsp; Most of
the initial dsNets used 8 Slicestors and set the width of each vault to 8.&nbsp; Although <a title="Information Dispersal Algorithms" class="internal-link" href="/dispersed-storage/idas#T">the information dispersal algorithms
we use</a> can mathematically support any width (and our implementation can be
configured with widths up to 256), the initial commercial release only
supported 8 as the width since that was a width for which we had completed
comprehensive testing.&nbsp; We’re now
beginning comprehensive testing with 16 wide dsNets and then expect to test
wider widths: &nbsp;32, 64, maybe 128 or
higher.</p>
<p>In smaller dsNets, it is common for the width of the vault(s)
on the dsNet to equal the number of Slicestors, but as dsNets grow the number
of Slicestors will exceed the width of any vault on that dsNet.</p>
<p>Many dsNets will store and distribute at least Petabytes of
data using more thousands or more Slicestors and will often use different
widths (and <a title="Glossary" class="internal-link" href="/documentation/glossary#T">threshold </a>settings) for various vaults stored on those dsNets.&nbsp; We expect that the widths for those vaults
will vary from 8 to 64 or perhaps 128, but will be significantly less than the
total number of Slicestors on the dsNet.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>Chris</p>

          ]]>
        </content:encoded>        

        <dc:date>2008-06-03T14:30:00-04:00</dc:date>

        <dcterms:modified>2008-08-04T16:08:25-04:00</dcterms:modified>

        <dc:creator>cgladwin</dc:creator>

        

        
            <dc:subject>Information Dispersal Algorithm</dc:subject>
        
        
            <dc:subject>Vaults</dc:subject>
        
        
            <dc:subject>Scalability</dc:subject>
        
        
            <dc:subject>Slices</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2008/05/06/release-candidate-1.0-into-open-source">

        <rss:title>Release Candidate 1.0 into Open Source</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2008/05/06/release-candidate-1.0-into-open-source</rss:link>       

        

        <content:encoded>
          <![CDATA[
          
<p>Wow it’s been a long time since our last release, and as you can imagine, we’ve been busy. With our release candidate 1.0, you should experience stable software. The core software comes from our commercial release, which has been tested extensively. We mainly tested a dsNet with a width of 8, and a threshold of 6, meaning, you can experience 2 simultaneous unavailable Slicestors, and still bit-perfectly recreate your data.<br /><br />Two areas that are improved:</p>
<ul><li>iSCSI target stabilization.&nbsp; We now have windows support as well.</li></ul>
<ul><li>Adverse network handling. Your network is up, your network is down. We’ve worked diligently to elegantly handle unavailability scenarios while still providing seamless access to your data.</li></ul>
<p>Personally, and someone who’s been here from the start (January 2005), it is very exciting to see our technology stabilize and become available through open source.</p>
<p>We recommend you try this release for yourself. Please let us know how it works for you.</p>
<p>Thanks!<br /><br /><br /><br /></p>

          ]]>
        </content:encoded>        

        <dc:date>2008-05-06T18:58:01-04:00</dc:date>

        <dcterms:modified>2008-05-06T18:58:01-04:00</dcterms:modified>

        <dc:creator>jbellanca</dc:creator>

        

        
            <dc:subject>Release</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2008/04/22/solid-state-drives-and-dispersed-storage">

        <rss:title>Solid State Drives and Dispersed Storage</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2008/04/22/solid-state-drives-and-dispersed-storage</rss:link>       

        <rss:description>The combination of Solid State Drives and Dispersed Storage could enable the first mainstream storage architecture shift since the PC introduced the one drive per computer per person architecture.</rss:description>

        <content:encoded>
          <![CDATA[
          
<p>&nbsp;</p>
<p>As a comment to my <a title="Are Hard Drives Getting Slower?" class="internal-link" href="/cs-weblog/are-hard-drives-getting-slower">post last month about hard drive speeds</a>,
Waldo made a comment about the potential impact of Solid State Drives (SSDs) to
change the mainstream data storage paradigm.&nbsp;
I agree that SSDs have significant potential and will become
increasingly important.&nbsp; As computers
become more ubiquitous:&nbsp; more
transportable, more hold-able, more wearable, etc., the benefits of solid state
storage – lighter, smaller, more durable – will become more relevant.&nbsp; In addition, SSDs are much faster that hard
drives.</p>
<p>&nbsp;</p>
<p>However, at the same time people will are using more and
more data which will further expose the weakness of SSD:&nbsp; their cost per unit storage is significantly
higher that hard drives.</p>
<p>&nbsp;</p>
<p>So how can you have the best of both worlds?&nbsp; Imagine a mobile device, like a mobile phone
or a laptop, with a SSD (or just a lot of solid state storage).&nbsp; Now imagine that mobile device also has a
high speed wireless data connection to a Dispersed Storage network.&nbsp; In this approach, the SSD is a fast, huge
storage cache while the dsNet provides massive, reliable secondary storage.&nbsp; With this approach, you get fast access in a
small, light and durable device while having access to unlimited storage on a
dsNet.&nbsp; And if you lost your mobile
device, you could connect a new mobile device (or two or five) to you data on
the dsNet and never lose a bit.</p>
<p>&nbsp;</p>
<p>The pieces to put this together will all be available this
year.&nbsp; Anyone want to port the dsNet
client to their phone?</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
Chris

          ]]>
        </content:encoded>        

        <dc:date>2008-04-22T20:45:00-04:00</dc:date>

        <dcterms:modified>2008-08-04T16:03:00-04:00</dcterms:modified>

        <dc:creator>cgladwin</dc:creator>

        

        
            <dc:subject>Software Integrations</dc:subject>
        
        
            <dc:subject>Reliability</dc:subject>
        
        
            <dc:subject>Data Storage</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2008/03/03/cleversafe-open-source-vs.-commercial">

        <rss:title>Cleversafe Open Source vs. Commercial</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2008/03/03/cleversafe-open-source-vs.-commercial</rss:link>       

        <rss:description>Cleversafe is bringing an “Internet model” to data storage by mixing open source protocols with commercial products.</rss:description>

        <content:encoded>
          <![CDATA[
          
<p>&nbsp;</p>
<p>Now that Cleversafe has <a class="external-link" href="http://www.cleversafe.com/news-reviews/press-releases/r08-1">announced its upcoming commercial
products</a>, we can talk more clearly about the relationship between the Dispersed
Storage open source project (here at <a href="../../">www.cleversafe.org</a>)
and Cleversafe’s commercial products.&nbsp;</p>
<p>&nbsp;</p>
<p>As we are doing with our technical approach, we are
utilizing the outstanding and proven approach taken by the Internet for our
business ecosystem model.&nbsp;</p>
<p>&nbsp;</p>
<p>The key protocols that power the Internet:&nbsp; TCP, IP, UDP, LDAP, DNS, etc are genuinely
open protocols in that they are in the public domain and available as open
source.&nbsp; As a result, the Internet really
is an interoperable internetwork.&nbsp; Way
back in the 80’s, I was in the IT department of a large aerospace company
responsible for setting networking standards and I remember when other networking
protocols – such as <a class="external-link" href="http://en.wikipedia.org/wiki/Systems_Network_Architecture">IBM’s SNA</a>, DECNET and Novell’s SPX/IPX – were more popular
than TCP/IP.&nbsp; Each of these proprietary
protocols were driven by well-funded and capable R&amp;D organizations;
whereas, the R&amp;D behind TCP/IP was not fueled by a large, well-funded
technology company.&nbsp; However 20 years
later, TCP/IP has pretty much completely taken over as the networking and
internetworking protocol of choice and the Internet absolutely dominates any
networks still using these previously popular proprietary protocols (P4’s).</p>
<p>&nbsp;</p>
<p>Yes, TCP/IP is a great protocol, but the P4’s protocols were
pretty great, too.&nbsp; I believe part of the
reason that TCP/IP and the Internet emerged as the world’s network is based on
human nature.&nbsp; Simply put, most people
didn’t want the world’s network to be owned or controlled by one company, so as
the world built its internetwork, a genuinely open protocol had an inherent
advantage and was ultimately propelled to become the protocol behind the
Internet, the world’s network.</p>
<p>&nbsp;</p>
<p>When we began to develop Dispersed Storage, we realized the
technology had significant potential, namely to store the world’s data.&nbsp; We also realized, based on the lesson of the
Internet, that the protocols of a Storage Internet ultimately must also be open
source, so we created the Dispersed Storage project&nbsp; in
order to develop and publish the Dispersed Storage protocol as open
source.&nbsp; In order to do this, we also created
a lot of new open source code and incorporated a lot of open source code from
other projects.</p>
<p>&nbsp;</p>
<p>Even though the Dispersed Storage protocol stack and core
features are available as open source, plenty of great opportunities exist for
creating commercial products and services.&nbsp;
To use the Internet analogy again, network equipment companies, like
Cisco and Juniper create commercial products (switches, routers, gateways,
etc.) by taking the open TCP/IP protocol, adding proprietary features like
management systems, integrating onto optimized hardware with an optimized OS
and then selling those products through a trained channel that provides
services like support and installation.&nbsp;
Cleversafe is using that same approach for its commercial products, so
once again we are standing on the shoulders of the giants who build the
technology and the business models for the Internet.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>Chris</p>

          ]]>
        </content:encoded>        

        <dc:date>2008-03-03T12:40:00-05:00</dc:date>

        <dcterms:modified>2008-08-04T16:09:04-04:00</dcterms:modified>

        <dc:creator>cgladwin</dc:creator>

        

        
            <dc:subject>Dispersed Storage</dc:subject>
        
        
            <dc:subject>About Cleversafe.org</dc:subject>
        
        
            <dc:subject>Data Storage</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2008/02/17/increasing-network-performance">

        <rss:title>Why Networks are Getting Relatively Faster</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2008/02/17/increasing-network-performance</rss:link>       

        <rss:description>The communications bandwidth of fiber has been increasing faster that Moore's Law which ultimately will enable huge increases in networking speeds.</rss:description>

        <content:encoded>
          <![CDATA[
          
<p>&nbsp;</p>
<p>I previously wrote a blog <a title="Are Hard Drives Getting Slower?" class="internal-link" href="/cs-weblog/are-hard-drives-getting-slower">post about how hard drive performance has been increasing slower</a> than the rate of change of Moore's law which means that hard drives have become relatively much slower over the past 15 years.</p>
<p>&nbsp;</p>
<p>Another related and potentially more significant trend is that fiber bandwidth speeds have been increasing faster than Moore's Law over the past several years.&nbsp; Although the data on this trend is much harder to find, I did find this reference at the <a title="external-link" href="http://en.wikipedia.org/wiki/Moore%27s_law">Moore's Law article on Wikipedia:<br /></a></p>
<blockquote>
<p><strong>Data per optical fiber.</strong> According to Gerry/Gerald Butters,<sup id="_ref-11" class="reference"><a href="http://en.wikipedia.org/wiki/Moore%27s_law#_note-11">[15]</a></sup><sup id="_ref-12" class="reference"><a href="http://en.wikipedia.org/wiki/Moore%27s_law#_note-12">[16]</a></sup> the former head of Lucent's Optical Networking Group at <a title="Bell Labs" href="http://en.wikipedia.org/wiki/Bell_Labs">Bell Labs</a>, there is another version, called Butter's Law of Photonics,<sup id="_ref-13" class="reference"><a href="http://en.wikipedia.org/wiki/Moore%27s_law#_note-13">[17]</a></sup> a formulation which deliberately parallels <a title="Moore's law" class="mw-redirect" href="http://en.wikipedia.org/wiki/Moore%27s_law">Moore's law</a>. Butter's Law <sup id="_ref-14" class="reference"><a href="http://en.wikipedia.org/wiki/Moore%27s_law#_note-14">[18]</a></sup>
says that the amount of data coming out of an optical fiber is doubling
every nine months. Thus, the cost of transmitting a bit over an optical
network decreases by half every nine months. The availability of <a title="Wavelength-division multiplexing" href="http://en.wikipedia.org/wiki/Wavelength-division_multiplexing">wavelength-division multiplexing</a>
(sometimes called "WDM") increased the capacity that could be placed on
a single fiber by as much as a factor of 100. Optical networking and <a title="DWDM" class="mw-redirect" href="http://en.wikipedia.org/wiki/DWDM">DWDM</a>
is rapidly bringing down the cost of networking, and further progress
seems assured. As a result, the wholesale price of data traffic
collapsed in the <a title="Dot-com bubble" href="http://en.wikipedia.org/wiki/Dot-com_bubble">dot-com bubble</a></p>
</blockquote>
<p>&nbsp;</p>
<p>I ran into <a title="external-link" href="http://aprius.com/index_files/team.htm">Marc Verdiell </a>who is a world-class fiber data communication expert and was able to ask him whether he was seeing such a dramatic shift in fiber bandwidth and he confirmed that the bandwidth potential for fiber is effectively unlimited as there are many, many colors of light that you can theoretically transmit down a piece of fiber.&nbsp; (Of course, the technology to make this happen gets extremely complex which will keep experts like Marc busy for many years.)</p>
<p>&nbsp;</p>
<p>I am seeking to understand this further, but these initial pieces of information suggest that we are in for continued, dramatic increases in network bandwidth in the coming years -- at a rate faster than the doubling-every-two-years realized pace of Moore's law.&nbsp;</p>
<p>&nbsp;</p>
<p>When combined with the long term trend that hard drive performance is increasing at a rate slower than Moore's Law, the clear result is that high performance and large scale data storage systems will evolve to designs based on reading to and writing from large numbers of hard drives simultaneously over high speed network connections.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>Chris</p>
<p>&nbsp;</p>

          ]]>
        </content:encoded>        

        <dc:date>2008-02-17T00:20:00-05:00</dc:date>

        <dcterms:modified>2008-08-04T16:06:32-04:00</dcterms:modified>

        <dc:creator>cgladwin</dc:creator>

        

        
            <dc:subject>Performance</dc:subject>
        
        
            <dc:subject>Scalability</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2008/01/24/even-faster-actual-performance">

        <rss:title>Even Faster Actual Performance</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2008/01/24/even-faster-actual-performance</rss:link>       

        <rss:description>Our recent perrmance tests show that Dispered Storage performance has gone up by 2x again.  We're now seeing actual performance equivalent to a hard drive.</rss:description>

        <content:encoded>
          <![CDATA[
          
<p>Performance benchmarks with the latest internal release (0.8.0)&nbsp; show that the read/write performance of Dispersed Storage went up by 2x (again!).&nbsp; We're now generally seeing realized throughput rates in the 20-30 MBps range (equal to 160-320 Mpbs) though a single Accesser (client) on a dsNet.&nbsp; This level of performance is well beyond the theoretical maximum that we thought&nbsp;we'd get to in this initial release.&nbsp; (So it is a good thing that our developers are better at performance improvements than they predicting the theotical maximum for performance!)</p>
<p>To put that in perspective, we ran some apple-to-apples comparisons between a dsNet and a local hard drive.&nbsp; The test we ran was reading and writing a 1 GB file on both a local (desktop PC) hard drive and a dsNet over a 1 Gbps connection.&nbsp; It turns out that the dsNet was a bit faster for the write and a bit slower for the the read vs. a local hard drive.&nbsp; The results are in this chart:</p>
<dl class="image-inline captioned">
<dt><img src="http://www.cleversafe.org/cs-weblog/topic_images/Performanceclear.png/image" alt="Performance-better-quality" title="Performance-better-quality" height="258" width="476" /></dt>
 <dd class="image-caption" style="width:476px"> </dd>
</dl>

<p>&nbsp;</p>
<p>Overall, this is a huge deal.&nbsp;&nbsp;This level of performance is about 100x where we thought we'd end up for this release.&nbsp;&nbsp;Because we are now providing hard drive level performance through&nbsp;regular&nbsp;hard drive interfaces (Block, iSCSI, etc.), we really are optomisic about the potential for Dispersed Storage.</p>
<p>Going forward, we are confident that we'll be able to increase the performance of dsNets even further and ultimately consistently exceed hard drive performance.</p>
<p>&nbsp;</p>
<p>Chris</p>

          ]]>
        </content:encoded>        

        <dc:date>2008-01-24T14:00:00-05:00</dc:date>

        <dcterms:modified>2008-08-04T16:05:53-04:00</dcterms:modified>

        <dc:creator>cgladwin</dc:creator>

        

        
            <dc:subject>Performance</dc:subject>
        
        
            <dc:subject>Interfaces</dc:subject>
        
        
            <dc:subject>Dispersed Storage Network</dc:subject>
        
        
            <dc:subject>Storage</dc:subject>
        
        
            <dc:subject>iSCSI</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2007/12/28/information-dispersal-performance">

        <rss:title>Information Dispersal Performance</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2007/12/28/information-dispersal-performance</rss:link>       

        <rss:description>Preliminary test results indicate that Information Dispersal Algorithms are faster than compression or encryption.</rss:description>

        <content:encoded>
          <![CDATA[
          
<p>Our focus for Dispersed Storage performance has been overall system performance – which in a Dispersed Storage Network is driven by how quickly bytes travel up and down the client stack.&nbsp; This stack performance is basically what determines the speed of getting data on or off the dsNet, i.e. the speed of reads and writes.&nbsp; The sequence of events when going down the stack -- “writing” data is:</p>
<p>&nbsp;</p>
<p>1. Source data integrity check</p>
<p>2. Compression</p>
<p>3. Encryption</p>
<p>4. Dispersal</p>
<p>5. Slice integrity check</p>
<p>6. Packetizing</p>
<p>7. Network transmission</p>
<p>&nbsp;</p>
<p>When “reading” the data flow is the opposite – you just go up the stack.&nbsp; Also, note that compression and encryption are optional.</p>
<p>&nbsp;</p>
<p>So, our thinking about performance revolves around the overall throughput which means that the slowest layer has the greatest affect on throughput.&nbsp; Our goal for the performance of the dispersal algorithms is to make sure they are not the slow link in the performance chain required to get data through the performance stack.</p>
<p>&nbsp;</p>
<p>We’ve been running a variety of performance tests – reads, writes, different files sizes, etc. and are consistently seeing that the dispersal algorithms are now exceeding our goal for performance in this release.&nbsp; Specifically, on a Xeon 5300 Quad Core running at 2.33 GHz, we are getting data through the Dispersed Storage stack (with compression and encryption turned off, so that we are mainly exercising the dispersal algorithms) generally around 100 Mbps (or 12 MBps) for reads or writes.&nbsp;</p>
<p>&nbsp;</p>
<p>We’ll have more test data in the future, but we’re very pleased that these results are looking so good so far. &nbsp;And we still expect to realize further performance gains over time with further optimization.</p>
<p>&nbsp;</p>
<p>In our previous tests of compression and encryption performance, we saw that either of these two functions are much more CPU-intensive than dispersal.&nbsp; So, we are confident that our implementation of information dispersal algorithms won’t be the slow layer in the stack.&nbsp; We are now re-testing with compression and/or encryption turned to confirm these prior results.</p>
<p>&nbsp;</p>
<p>For even higher performance, you can run the Dispersed Storage stack on multiple machines or front-end the dispersal stack with other processes, like compression or de-duplication to increased the realized data throughput. &nbsp;For example, if you had a process running on another server that provided 10:1 compression and you dispersed the compressed data, you could realize source data throughputs of 1+ Gbps through a single quad core box running the Dispersed Storage stack.&nbsp; And if you ran the compression and Dispersal stacks processes on multiple servers in parallel, then overall performance just scales up. &nbsp;I think you see where this is headed.</p>
<p>&nbsp;</p>
<p>The summary idea is that performance in a Dispersed Storage network doesn’t have an inherent limitation – just like a packet switched network doesn’t have an inherent performance limitation. &nbsp;We have a lot of work to do to fully realize this vision, but asking “how fast is a Dispersed Storage Network” should be like asking “how fast is packet switching.”</p>
<p>&nbsp;</p>
<p>Chris</p>
<p>&nbsp;</p>

          ]]>
        </content:encoded>        

        <dc:date>2007-12-28T14:25:00-05:00</dc:date>

        <dcterms:modified>2008-08-04T16:07:07-04:00</dcterms:modified>

        <dc:creator>cgladwin</dc:creator>

        

        
            <dc:subject>Performance</dc:subject>
        
        
            <dc:subject>Cauchy Reed-Solomon</dc:subject>
        
        
            <dc:subject>Dispersed Storage Network</dc:subject>
        
        
            <dc:subject>IDA</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2007/12/14/are-hard-drives-getting-slower">

        <rss:title>Are Hard Drives Getting Slower?</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2007/12/14/are-hard-drives-getting-slower</rss:link>       

        <rss:description>Because disk drive performance increases haven’t been keeping pace with disk drive capacity increases, disk drive performance has been getting slower on an “technology adjusted” basis.

</rss:description>

        <content:encoded>
          <![CDATA[
          
<p>In preparing a presentation recently on long term trends in data storage, I was talking with Russ Kennedy and he mentioned that it was a known fact within the data storage industry that hard drive performance has been lagging.&nbsp; So mentioned this to Dennis Roberson and he connected me with <a title="external-link" href="http://www.tomshardware.com/2006/11/27/15-years-of-hard-drive-history/">this article at Tom’s Hardware </a>which I found very enlightening.</p>
<p>&nbsp;</p>
<p>It turns out that increases in <a title="external-link" href="http://en.wikipedia.org/wiki/Image:Hard_drive_capacity_over_time.png">hard drive capacities have been keeping pace with Moore’s law</a> (as observed) by doubling every 24 months.&nbsp; But hard drive performance (reads and writes) hasn’t been keeping pace.&nbsp; Even though hard drive performance has been increasing, it hasn’t been increasing as fast as hard drive capacities have been increasing.&nbsp;</p>
<p>&nbsp;</p>
<p>So if the amount of data that people want to read from and write to hard drives has been increasing with the rate of increase of CPU performance and hard drive capacities, then the realized performance of hard drives (on this “technology adjusted” basis) has been getting SLOWER!&nbsp; This is a big part of why Windows never seems to load any faster.</p>
<p>&nbsp;</p>
<p>The article at Tom’s Hardware really brought these diverging trends together in a compelling way by measuring the speed to read a single platter against the year when the hard drive was manufactured.&nbsp; <a title="external-link" href="http://www.tomshardware.com/2006/11/27/15-years-of-hard-drive-history/page8.html">This chart </a>shows that the speed to read a single platter of data has decreased by almost 10X over the past 15 years.&nbsp; Wow.&nbsp;</p>
<p>&nbsp;</p>
<p>If these trends continue, hard drive speeds will become an increasingly limiting factor which will further limit the approach of a local hard drive as the primary data storage system. &nbsp;Especially for high performance environments, the solution to lagging drive performance will be architectures like Dispersed Storage that write to or read from multiple drives in parallel.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>Chris</p>

          ]]>
        </content:encoded>        

        <dc:date>2007-12-14T00:05:00-05:00</dc:date>

        <dcterms:modified>2008-08-04T16:03:43-04:00</dcterms:modified>

        <dc:creator>cgladwin</dc:creator>

        

        
            <dc:subject>Dispersed Storage</dc:subject>
        
        
            <dc:subject>Storage</dc:subject>
        
        
            <dc:subject>Data Storage</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2007/11/20/re-writing-vs.-modifying-software">

        <rss:title>Re-writing vs. Modifying Software</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2007/11/20/re-writing-vs.-modifying-software</rss:link>       

        <rss:description>Early in 2007, the Dispersed Storage software development team decided to re-architect and re-write the dsNet software instead of modifying the previous code base.</rss:description>

        <content:encoded>
          <![CDATA[
          
<p>You may have noticed that the open source release we posted last month was a complete re-write of the code based we published last year.&nbsp; Not a single line of code was unchanged.&nbsp; This change wasn’t just due to the change from C++ to Java, but was a result of a decision to completely re-architect, re-design and re-write the Dispersed Storage software.&nbsp;</p>
<p>&nbsp;</p>
<p>I’ve spoken a few times with Joe Jablonski of <a title="external-link" href="http://acumence.com/">Acumence </a>and others about the merits of re-writing software vs. enhancing an existing code base and Joe and I agree that software development organizations too often make the mistake of continuing to enhance weakening code base vs. re-writing from scratch.</p>
<p>&nbsp;</p>
<p>I think this misjudgment comes from a fundamental misunderstanding of the nature of modern software development.&nbsp; Modern software development tools in the hands of capable developers can quickly produce complex software.&nbsp; (We are using <a title="external-link" href="http://en.wikipedia.org/wiki/Scrum_%28development%29">SCRUM</a> as our development methodology, by the way, and have been quite pleased with the results.)&nbsp; But software development does not just mean the act of writing software.&nbsp; And the time required to write complex software is not just the time required to type the code.&nbsp; Completing a complex software development project requires dynamic coordination of requirements definition, architecture, design, development, testing, validation, tuning, and enhancement.&nbsp; If done correctly, the act of writing code is only a portion of the time and effort required for software development, especially for complex software and especially for a new type of complex software.</p>
<p>&nbsp;</p>
<p>Our goal in the initial production release of Dispersed Storage software is to create an outstanding software foundation on which we and others can build Dispersed Storage solutions.&nbsp; The work we did in 2005 and 2006 provided many insights in how to build a Dispersed Storage system and that know-how enabled us around the beginning of this year to know that we needed to re-write our software.&nbsp; That know-how also included knowing how to proceed toward an outstanding initial production release.</p>
<p>&nbsp;</p>
<p>Whether we realize that goal will ultimately be determined by market acceptance of our software and specifically whether it provides the reliability, security, performance, scalability, longevity and cost-effectiveness benefits we envision.&nbsp; But the preliminary results we are seeing now from our re-write over the past year so far exceed last year’s results that we know that re-writing was a necessary step.</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>Chris</p>
<p>&nbsp;</p>

          ]]>
        </content:encoded>        

        <dc:date>2007-11-20T12:10:00-05:00</dc:date>

        <dcterms:modified>2008-08-04T16:07:45-04:00</dcterms:modified>

        <dc:creator>cgladwin</dc:creator>

        

        
            <dc:subject>Release</dc:subject>
        
        
            <dc:subject>News</dc:subject>
        
        
            <dc:subject>Redesign Notes</dc:subject>
        
        
            <dc:subject>Software</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2007/11/01/out-of-the-box">

        <rss:title>Out of the Box</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2007/11/01/out-of-the-box</rss:link>       

        <rss:description>What do you think will be the next revolutions in storage?  </rss:description>

        <content:encoded>
          <![CDATA[
          
<p>Don’t get me wrong, getting old is not fun, but it does afford a certain perspective that only comes with being around for a while.<span>&nbsp; </span>That’s sort of a good thing, I guess.<span>&nbsp; </span>Being in one industry for a while you can definitely see innovation and progression, however, there are relatively few times when you get to witness revolutionary change.<span>&nbsp; </span>Most of the time things tend to evolve…evolutionary change.</p>
<p>&nbsp;</p>
<p>It would be hard to argue that the Information Technology and Data Processing has experienced significant change in the last 30 years.<span>&nbsp; </span>There are countless examples of things we take for granted today that weren’t even conceived of a generation ago.<span>&nbsp; </span></p>
<p>&nbsp;</p>
<p>The face of the IT industry has changed and changed again in that time frame.<span>&nbsp; </span>When I entered the work force, all computing and data processing was performed by expansive systems that took up rooms of floor space, had to be cooled by water flow and had about the same processing capacity and memory as the laptop that I’m using today.<span>&nbsp; </span>You had large expansive mainframe boxes that performed batch oriented jobs and very few humans interacted with computers at all.<span>&nbsp; </span></p>
<p>&nbsp;</p>
<p>With the invention of the personal computer and client-server computing, IT and data processing broke out of the “glass house” and became the prevue of every human.<span>&nbsp; </span>Networking advances connected all this computing power together and placed information, entertainment, and just about everything in our lives at our fingertips.<span>&nbsp; </span>That’s revolutionary, it’s changed the world.</p>
<p>&nbsp;</p>
<p>In storage, there have been significant changes as well, but one could argue again, that most of the changes have been evolutionary, not revolutionary.<span>&nbsp; </span>Driven by areal densities, speed and recording capabilities of magnetic material and manufacturing efficiencies, the storage industry has seen its share of improvements but not at the level of other core elements of IT.</p>
<p>&nbsp;</p>
<p>Look at today’s choices in the storage system market!<span>&nbsp; </span>Probably the most significant invention in storage was RAID technology at the end of the last century.<span>&nbsp; </span>Since then, most of the invention you’ve seen from the storage manufacturers is in the area of connectivity, capacity and performance.<span>&nbsp; </span>Every storage vendor basically solves the problem the same way.<span>&nbsp; </span>They build a box (an array) that is a collection of heads/controllers with interfaces (where most of the intelligence lies), a set of drives that operate collectively to provide capacity, performance and recovery from failure and some form of management software that is essential to operate and manage this stuff.<span>&nbsp; </span>It’s not very exciting and not much invention - except some of the management techniques.</p>
<p>&nbsp;</p>
<p>What we need is some revolutionary thinking, <strong>“outside the box”</strong> thinking similar to the days when data processing escaped the monolithic compute platforms and became accessible and usable by the majority.<span>&nbsp; </span>Why should all critical information assets be stored on one box in one location, even if it’s copied to another box or tape cartridge for safe-keeping?<span>&nbsp; </span>Why shouldn’t information be stored in such a way that it’s not only private and protected without replication but it’s easily accessible and distributable to humans that want to use it?</p>
<p>&nbsp;</p>

          ]]>
        </content:encoded>        

        <dc:date>2007-11-01T19:51:40-04:00</dc:date>

        <dcterms:modified>2007-11-01T19:51:40-04:00</dcterms:modified>

        <dc:creator>rkennedy</dc:creator>

        

        
            <dc:subject>Security</dc:subject>
        
        
            <dc:subject>Reliability</dc:subject>
        
        
            <dc:subject>Scalability</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2007/10/19/what-would-you-do-with-a-five-hundred-million">

        <rss:title>What would you do with a 500,000,000,000 Gigabyte hard drive?</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2007/10/19/what-would-you-do-with-a-five-hundred-million</rss:link>       

        <rss:description>If previous trends continue, our grandchildren will own a hard drive bigger that the capacity of ALL hard drive currently on the planet – what will they do with that amount of storage?</rss:description>

        <content:encoded>
          <![CDATA[
          
<p>Hitachi recently announced that they will be <a title="external-link" href="http://www.news.com/To-advance-drives%2C-Hitachi-changes-the-head/2100-1041_3-6213386.html?part=rss&amp;tag=2547-1_3-0-20&amp;subj=news">shipping a 4 terabyte hard drive</a> in 2011.&nbsp; One terabyte hard drives are now available for $320, so it you can expect 4 terabyte drives will be in this same price range within a short number of years.&nbsp; (4 terabytes = 4,000 gigabytes = 4,000,000 megabytes.)</p>
<p>&nbsp;</p>
<p>Recently one of my friends sent me <a title="external-link" href="http://www.littletechshoppe.com/ns1625/winchest.html">this link </a>that tracks hard drive pricing over time.&nbsp; In 1956, IBM was selling 5 megabytes for $50,000 which equates to $10,000 per megabyte.&nbsp; So in 1956, four terabytes of hard drive storage would have cost $40 billion dollars.&nbsp; Yes, $40 billion dollars for the storage that will be on a single hard drive in 2011.&nbsp; ($10,000 x 1,000 x 1,000 x 4)</p>
<p>&nbsp;</p>
<p>So if this rate of decreasing cost per unit of hard drive storage continues at the same rate through 2066, would be able to buy a 500,000,000 terabyte (500 exabyte) hard drive for around $320 if fifty years or so.&nbsp; Five hundred million terabytes is a huge number when you think about it in 2007 – just like 4,000,000 megabytes (4 terabytes) seemed like a huge amount of storage in 1956.</p>
<p>&nbsp;</p>
<p>To put a five hundred million terabyte hard drive in perspective, consider how much storage is available on all hard drives currently in use today.&nbsp; According to Disk/Trend, hard drive factories produced between 450 million and 460 million hard drives in 2006.&nbsp; If you assume the average size of a hard drive manufactured in 2006 was 100 GB, that hard drive factories will produce about 40% more capacity in 2007 and produced about 40% less capacity in 2006 (following the rate of change of <a title="external-link" href="http://en.wikipedia.org/wiki/Moore's_law">Moore’s Law</a>) and that hard drives remain in use 3 years, then the total capacity of all hard drives in use on the planet at the end of 2007 will be about 140,000,000 terabytes (140 exabytes).</p>
<p>&nbsp;</p>
<p>So this means that if prior trends continue, a typical hard drive in 2066 would have a capacity equal to about 3 times all the storage capacity of all the hard drives in the world today. &nbsp;I may be off by an order of magnitude or more and/or a decade or more, but the point is that that previous trends suggest that your grandchildren’s hard drive will be as big as all the hard drives currently on the planet.&nbsp; What would you do with all this data storage?&nbsp; Or maybe a better question is what will our grandchildren do with all this storage?</p>
<p>&nbsp;</p>
<p>Chris</p>

          ]]>
        </content:encoded>        

        <dc:date>2007-10-19T18:25:00-04:00</dc:date>

        <dcterms:modified>2008-08-04T16:05:17-04:00</dcterms:modified>

        <dc:creator>cgladwin</dc:creator>

        

        
            <dc:subject>Cost-effective</dc:subject>
        
        
            <dc:subject>Infrastructure</dc:subject>
        
        
            <dc:subject>Data Storage</dc:subject>
        

    </rss:item>

    
    

    <rss:item rdf:about="http://www.cleversafe.org/cs-weblog/2007/10/15/the-cleversafe-idea-1">

        <rss:title>The Cleversafe Idea</rss:title>

        <rss:link>http://www.cleversafe.org/cs-weblog/2007/10/15/the-cleversafe-idea-1</rss:link>       

        <rss:description>The Story on the Ideas Behind the Founding of Cleversafe</rss:description>

        <content:encoded>
          <![CDATA[
          
<p class="documentDescription">“How did you get the initial idea for Cleversafe?” is a question I am asked fairly often possibly since I don’t have a long career background in data storage systems or in coding algorithms. What lead me to that idea of building a geographically distributed Dispersed Storage grids was that I was looking for a way to store my personal data and I had been reading a lot about the history of cryptography.</p>
<div class="plain">
<p>Prior to Cleversafe, I started a company called MusicNow which was a leading business-to-business provider of (legal) digital music services.&nbsp; We built and operated download stores, music subscription services and Internet radio services which were sold by companies including, Best Buy, Microsoft and Earthlink.&nbsp; In April, 2004 <a title="external-link" href="http://www.news.com/2110-1027_3-5182902.html" target="_new">we sold MusicNow to Circuit City </a>(who since sold it to AOL who then sold most of it to Napster).&nbsp; After the Circuit City acquisition, I took the summer and fall of 2004 off which was the first time in my adult life that I hadn’t worked.&nbsp; One of my projects was to organize all my stuff, so I digitized and organized all my financial records, pictures, correspondence, etc. which took several weeks.&nbsp; <br /><br />I ended up with 30 GB of data which I needed to store for the rest of my life since I knew that I would never again want to spend so much time going through that organization process.&nbsp; At MusicNow, we had built a system to store all the music in the world, so I was quite familiar with the state of the art in digital storage.&nbsp; I needed a cost-effective system that could store my data for the next 50 years and knew that existing storage methods could not meet those requirements.<br /><br />In 2004, I was also reading a lot about the history or cryptography.&nbsp; In particular, I was reading a lot about <a title="external-link" href="http://en.wikipedia.org/wiki/Operation_Fortitude">Operation Fortitude</a>:&nbsp; how the Allies in WWII we able to have the Nazis initially believe that the landings at Normany were just a diversion.&nbsp; It was the most ingenious setup I’ve ever heard of – and it worked!&nbsp; (For those interested in a fascinating and very detailed read in this area, I highly recommend Fortitude: The D-Day Deception Campaign by Roger Hesketh.)&nbsp; <br /><br />Inspired by the historical richness of cryptography, I moved on to directly explore cryptographic techniques and code breaking methods which lead me to read <a title="external-link" href="http://books.slashdot.org/article.pl?sid=01/02/06/130251">Code Breaking: A History and Explanation by Rudolph Kippenhahn</a>.&nbsp; As I was reading Code Breaking, I took the time to “do the homework exercises” which meant that when the book covered how to break a monoalphabetic substitution cipher, I took the time to break a couple monoalphabetic substitutions as well as many other forms of ciphers.&nbsp; In doing these exercises, I learned a lot about how to use pieces of coded information to derive original data.<br /><br />Reading about counter-intelligence and code breaking was not a part of a master plan to start a new business; I was just following my personal interests.&nbsp; But when I later started to think about how to build a system to store my personal data for 50 years, I had a good foundation in the mathematical techniques for coding and decoding information.&nbsp; With that foundation, I immediately had the strong intuition that you could create a system with the characteristics now found in Dispersed Storage.&nbsp; And so following that intuition, I wrote a very early prototype which was the first step in creating Cleversafe.</p>
<br />
<p>&nbsp;</p>
<p>Chris</p>
</div>

          ]]>
        </content:encoded>        

        <dc:date>2007-10-15T10:50:00-04:00</dc:date>

        <dcterms:modified>2008-08-04T16:04:35-04:00</dcterms:modified>

        <dc:creator>cgladwin</dc:creator>

        

        
            <dc:subject>Information Dispersal Algorithm</dc:subject>
        
        
            <dc:subject>Dispersed Storage</dc:subject>
        
        
            <dc:subject>About Cleversafe.org</dc:subject>
        
        
            <dc:subject>Cleversafe.org Contributors</dc:subject>
        

    </rss:item>

    

</rdf:RDF>
