Unfortunately the snapshotting process used by the is really slow, as you&#39;ve noticed, and there&#39;s not much we can do to make that faster.  We&#39;ve discussed other methods for growing the filesystem but haven&#39;t finished it yet.<div>

<br></div><div>For working with S3, instead of s3fs you&#39;re more than welcome to give Galaxy&#39;s S3ObjectStore a shot.  There isn&#39;t much documentation available for it right now, and I&#39;d still say it&#39;s a beta feature in need of more testing and optimization, but to enable it define the following options in your universe_wsgi.ini:</div>
<div><br></div><div><div># Object store mode (valid options are: disk, s3, distributed, hierarchical)</div><div>#object_store = s3</div><div>#aws_access_key = &lt;your access key&gt;</div><div>#aws_secret_key = &lt;your secret key&gt;</div>
<div>#s3_bucket = &lt;a bucket name for all your files&gt;</div><div>#use_reduced_redundancy = True</div><div><br></div><div># Size (in GB) that the cache used by object store should be limited to.</div><div># If the value is not specified, the cache size will be limited only by the file</div>
<div># system size.</div><div>object_store_cache_size = &lt;decide based on the size of the EBS volume you want to use as scratch&gt;</div></div><div><div><br></div><div>What this will do is use the EBS volume for working, exactly like galaxy does currently.  Additionally, it&#39;ll push datasets to S3 and delete them from local disk as necessary (last touched deleted first) to stay beneath object_store_cache_size.  If something swaps out, it&#39;s just fetched back from S3 as needed, but most of the time you&#39;ll be working on disk directly and pushing to S3 in the background.</div>
<div><br></div><div>I&#39;d be more than happy to work with you if you run into any issues trying this out, this is something we&#39;ve wanted to firm up for a while now and having a real live test case would be useful!</div>
<div><br></div><div>-Dannon</div><div><br><br><div class="gmail_quote">On Tue, Feb 26, 2013 at 7:24 PM, Scooter Willis <span dir="ltr">&lt;<a href="mailto:HWillis@scripps.edu" target="_blank">HWillis@scripps.edu</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"><div>Used cloud man to create a new cluster on Feb 22 and picked 500GB as the initial size of the data drive. Working with TCGA exome DNA seq data didn&#39;t take long to fill that up. Used the cloud man admin interface to resize from 500GB to 1TB and the resize operation took 15 hours. Not sure if that is expected so wanted to give some heads up in case that is an area for optimization.</div>

<div><br></div><div>Since I now have a local storage problem as I need to work with more than 1TB of data I tried to go the route of setting a S3 bucket using Fuse. Ran into a problem where the first s3fs software I tried to install had a version issue with Ubuntu 10. </div>

<div><br></div><div>I remember something in a support email that better support for Amazon S3 was in the works. Can you provide any guidance or thoughts on how to work with more than 1TB of data using cost effective S3 versus expensive EBS? The same applies for storing results at S3.</div>

<div><br></div><div>With s3fs the file system can hide many of the complexities of moving files back and forth with caching where working with 30GB+ files isn&#39;t going to be fun.</div><div><br></div><div>Thanks</div><span><font color="#888888"><div>

<br></div><div>Scooter</div><div><br></div><div><br></div></font></span></div>
<br>___________________________________________________________<br>
Please keep all replies on the list by using &quot;reply all&quot;<br>
in your mail client.  To manage your subscriptions to this<br>
and other Galaxy lists, please use the interface at:<br>
<br>
  <a href="http://lists.bx.psu.edu/" target="_blank">http://lists.bx.psu.edu/</a><br></blockquote></div><br></div></div>