+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" speed="1Gf">
+ <mount storageId="Disk2" name="c:"/>
+ </host>
+
+ <host id="denise" speed="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
+
+\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.