-These are the entities that you can use in your platform files to include
-storage in your model. See also the list of our \ref pf_storage_example_files "example files";
-these might also help you to get started.
-
-\anchor pf_storage_entity_storage_type
-#### \<storage_type\> ####
-
-Attribute name | Mandatory | Values | Description
---------------- | --------- | ------ | -----------
-id | yes | string | Identifier of this storage_type; used when referring to it
-model | yes | string | For reasons of future backwards compatibility only; specifies the name of the model for the storage that should be used
-size | yes | string | Specifies the amount of available storage space; you can specify storage like "500GiB" or "500GB" if you want. (TODO add a link to all the available abbreviations)
-content | yes | string | Path to a \ref pf_storage_content_file "Storage Content File" on your system. This file must exist.
-content_type | no | ("txt_unix"\|"txt_win") | Determines which kind of filesystem you're using; make sure the filenames (stored in that file, see \ref pf_storage_content_file_structure "Storage Content File Structure"!)
-
-This tag must contain some predefined model properties, specified via the <model_prop> tag. Here is a list,
-see below for an example:
-
-Property id | Mandatory | Values | Description
---------------- | --------- | ------ | -----------
-Bwrite | yes | string | Bandwidth for write access; in B/s (but you can also specify e.g. "30MBps")
-Bread | yes | string | Bandwidth for read access; in B/s (but you can also specify e.g. "30MBps")
-Bconnexion | yes | string | Throughput (of the storage connector) in B/s.
-
-\note
- A storage_type can also contain the <b><prop></b> tag. The <prop> tag allows you
- to associate additional information to this <storage_type> and follows the
- attribute/value schema; see the example below. You may want to use it to give information to
- the tool you use for rendering your simulation, for example.
-
-Here is a complete example for the ``storage_type`` tag:
-\verbatim
-<storage_type id="single_HDD" model="linear_no_lat" size="4000" content_type="txt_unix">
- <model_prop id="Bwrite" value="30MBps" />
- <model_prop id="Bread" value="100MBps" />
- <model_prop id="Bconnection" value="150MBps" />
- <prop id="Brand" value="Western Digital" />
-</storage_type>
-\endverbatim
-
-\anchor pf_storage_entity_storage
-#### <storage> ####
-
-``storage`` attributes:
-
-Attribute name | Mandatory | Values | Description
--------------- | --------- | ------ | -----------
-id | yes | string | Identifier of this ``storage``; used when referring to it
-typeId | yes | string | Here you need to refer to an already existing \ref pf_storage_entity_storage_type "\<storage_type\>"; the storage entity defined by this tag will then inherit the properties defined there.
-attach | yes | string | Name of a host (see Section \ref pf_host) to which this storage is <i>physically</i> attached to (e.g., a hard drive in a computer)
-content | no | string | When specified, overwrites the content attribute of \ref pf_storage_entity_storage_type "\<storage_type\>"
-content_type | no | string | When specified, overwrites the content_type attribute of \ref pf_storage_entity_storage_type "\<storage_type\>"
-
-Here are two examples:
-
-\verbatim
- <storage id="Disk1" typeId="single_HDD" attach="bob" />
-
- <storage id="Disk2" typeId="single_SSD"
- content="content/win_storage_content.txt"
- content_type="txt_windows" attach="alice" />
-\endverbatim
-
-The first example is straightforward: A disk is defined and called "Disk1"; it is
-of type "single_HDD" (shown as an example of \ref pf_storage_entity_storage_type "\<storage_type\>" above) and attached
-to a host called "bob" (the definition of this host is omitted here).
-
-The second storage is called "Disk2", is still of the same type as Disk1 but
-now specifies a new content file (so the contents will be different from Disk1)
-and the filesystem uses the windows style; finally, it is attached to a second host,
-called alice (which is again not defined here).
-
-\anchor pf_storage_entity_mount
-#### <mount> ####
-
-Attributes:
-| Attribute name | Mandatory | Values | Description |
-| ---------------- | ----------- | -------- | ------------- |
-| id | yes | string | Refers to a \ref pf_storage_entity_storage "<storage>" entity that will be mounted on that computer |
-| name | yes | string | Path/location to/of the logical reference (mount point) of this disk
-
-This tag must be enclosed by a \ref pf_host tag. It then specifies where the mountpoint of a given storage device (defined by the ``id`` attribute)
-is; this location is specified by the ``name`` attribute.
-
-Here is a simple example, taken from the file ``examples/platform/storage.xml``:
-
-\verbatim
- <storage_type id="single_SSD" model="linear_no_lat" size="500GiB">
- <model_prop id="Bwrite" value="60MBps" />
- <model_prop id="Bread" value="200MBps" />
- <model_prop id="Bconnection" value="220MBps" />
- </storage_type>
-
- <storage id="Disk2" typeId="single_SSD"
- content="content/win_storage_content.txt"
- content_type="txt_windows" attach="alice" />
- <storage id="Disk4" typeId="single_SSD"
- content="content/small_content.txt"
- content_type="txt_unix" attach="denise"/>
-
- <host id="alice" power="1Gf">
- <mount storageId="Disk2" name="c:"/>
- </host>
-
- <host id="denise" power="1Gf">
- <mount storageId="Disk2" name="c:"/>
- <mount storageId="Disk4" name="/home"/>
- </host>
-\endverbatim
-
-This example is quite interesting, as the same device, called "Disk2", is mounted by
-two hosts at the same time! Note, however, that the host called ``alice`` is actually
-attached to this storage, as can be seen in the \ref pf_storage_entity_storage "<storage>"
-tag. This means that ``denise`` must access this storage through the network, but SimGrid automatically takes
-care of that for you.
-
-Furthermore, this example shows that ``denise`` has mounted two storages with different
-filesystem types (unix and windows). In general, a host can mount as many storage devices as
-required.
-
-\note
- Again, the difference between ``attach`` and ``mount`` is simply that
- an attached storage is always physically inside (or connected to) that machine;
- for instance, a USB stick is attached to one and only one machine (where it's plugged-in)
- but it can only be mounted on others, as mounted storage can also be a remote location.
-
-###### Example files #####
-
-\verbinclude example_filelist_xmltag_mount
-
-\anchor pf_storage_entity_mstorage
-#### <mstorage> ####
-\note
- This is currently unused.
-
-<b>mstorage</b> attributes :
-\li <b>typeId (mandatory)</b>: the id of the <b>storage</b> that must
- be mounted on that computer.
-\li <b>name (mandatory)</b>: the name that will be the logical
- reference to this disk (the mount point).
-
-\subsubsection pf_storage_example_files Example files
-
-Several examples were already discussed above; if you're interested in full examples,
-check the the following platforms:
-
-1. ``examples/platforms/storage.xml``
-2. ``examples/platforms/remote_io.xml``
-
-If you're looking for some examplary C code, you may find the source code
-available in the directory ``examples/msg/io/`` useful.
-
-\subsubsection pf_storage_examples_modelling Modelling different situations
-
-The storage functionality of SimGrid is type-agnostic, that is, the implementation
-does not presume any type of storage, such as HDDs/SSDs, RAM,
-CD/DVD devices, USB sticks etc.
-
-This allows the user to apply the simulator for a wide variety of scenarios; one
-common scenario would be the access of remote RAM.
-
-#### Modelling the access of remote RAM ####
-
-How can this be achieved in SimGrid? Let's assume we have a setup where three hosts
-(HostA, HostB, HostC) need to access remote RAM:
-
-\verbatim
- Host A
- /
-RAM -- Host B
- \
- Host C
-\endverbatim
-
-An easy way to model this scenario is to setup and define the RAM via the
-\ref pf_storage_entity_storage "storage" and \ref pf_storage_entity_storage_type "storage type"
-entities and attach it to a remote dummy host; then, every host can have their own links
-to this host (modelling for instance certain scenarios, such as PCIe ...)
-
-\verbatim
- Host A
- /
-RAM - Dummy -- Host B
- \
- Host C
-\endverbatim
-
-Now, if read from this storage, the host that mounts this storage
-communicates to the dummy host which reads from RAM and
-sends the information back.
-
-
-\section pf_routing Routing