Commit 46c572a0 authored by Robert Ricci's avatar Robert Ricci

Remove persistent storage from planned, we have it

parent 9c8cd8fd
......@@ -8,45 +8,6 @@ This chapter describes features that are planned for @(tb) or under development:
please @seclink["getting-help"]{contact us} if you have any feedback or
suggestions!
@section[#:tag "planned-persistent-storage"]{Persistent Storage}
For the time being, the contents of all disks in @(tb) are considered ephemeral:
the contents are lost whenever an experiment terminates. The only way to save
data is to copy it off or to @seclink["creating-profiles"]{create a profile}
using the disk.
We plan to change this by adding persistent storage that is hosted on storage
servers within @(tb). Users will be able to use the @(tb) web interface to create
and manage their persistent storage, and profiles will be able to reference
where these stores should be mounted in the experiment. When sharing profiles,
it will be possible to indicate that the persistent store may only be mounted
read-only---a common use case will be to put a dataset in a persistent store,
and allow other @(tb) users read-only access to the dataset.
There will be two types of persistent storage: @italic{block stores} which
are mounted using iSCSI, and which generally can only be mounted on one host
at a time, and @italic{file stores} which are mounted over NFS, and can be
mounted read/write by many nodes at the same time.
This feature will be based on Emulab's
@hyperlink["https://wiki.emulab.net/wiki/EmulabStorage"]{block storage system}.
Underlying this system is ZFS, which supports snapshots. We intend to expose
this snapshot functionality to users, and to allow profiles to mount specific
snapshots (eg. the version of a dataset used for a particular paper.)
It should be noted that performance of persistent stores will not be guaranteed
or isolated from other users, since it will be implemented using shared storage
servers that others may be accessing at the same time. Therefore, for
experiments whose @seclink["repeatable-research"]{repeatability} depends on
I/O performance, all data should be copied to local disk before use.
@section[#:tag "planned-quick-profiles"]{``Quick'' Profiles}
Sometimes, you just need one node running a particular
@seclink["disk-images"]{disk image}, without making a complicated profile to go
with it. We plan to add a ``quick profile'' feature that will create a one-off
experiment with a single node.
@apt-only{
@section[#:tag "planned-virt-switching"]{Simpler Virtual/Physical Profile Switching}
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment