For the last two items, there are essentially two possible ways you can provide
this information as an input:
-\li You can program it, either by using the Lua console (
- \ref MSG_Lua_funct) or, if you're using MSG, some of MSG's platform and
+\li You can program, if you're using MSG, some of MSG's platform and
deployment functions (\ref msg_simulation). If you want to use this,
check the particular documentation. (You can also check the section
\ref pf_flexml_bypassing, however, this documentation is deprecated;
there is a new, but undocumented, way to do it properly).
\li You can use two XML files: one contains the platform description while
- the other contains the deployment instructions.
+ the other contains the deployment instructions. The platform description
+ can also be in Lua format.
For more information on SimGrid's deployment features, please refer to
the \ref deployment documentation.
loopback_bw | no | int | Bandwidth for loopback (if any). See <b>link</b> section for syntax/details. If loopback_bw and loopback_lat (see below) attributes are omitted, no loopback link is created and all intra-node communication will use the main network link of the node. Loopback link is a \ref pf_sharing_policy_fatpipe "\b FATPIPE".
loopback_lat | no | int | Latency for loopback (if any). See <b>link</b> section for syntax/details. See loopback_bw for more info.
topology | no | FLAT\|TORUS\|FAT_TREE (default: FLAT) | Network topology to use. SimGrid currently supports FLAT (with or without backbone, as described before), <a href="http://en.wikipedia.org/wiki/Torus_interconnect">TORUS </a> and FAT_TREE attributes for this tag.
-topo_parameters | no | string | Specific parameters to pass for the topology defined in the topology tag. For torus networks, comma-separated list of the number of nodes in each dimension of the torus. For fat trees, refer to \ref AsClusterFatTree "AsClusterFatTree documentation".
+topo_parameters | no | string | Specific parameters to pass for the topology defined in the topology tag. For torus networks, comma-separated list of the number of nodes in each dimension of the torus. For fat trees, refer to \ref simgrid::surf::AsClusterFatTree "AsClusterFatTree documentation".
TODO
Attribute name | Mandatory | Values | Description
--------------- | --------- | ------ | -----------
id | yes | string | The identifier of the router to be used when referring to it.
-coordinates | yes | string | Must be provided when choosing the Vivaldi, coordinate-based routing model for the AS the router belongs to. More details can be found in the Section \ref pf_P2P_tags.
+coordinates | no | string | Must be provided when choosing the Vivaldi, coordinate-based routing model for the AS the router belongs to. More details can be found in the Section \ref pf_P2P_tags.
#### Example ####
#### The ``<prop/>`` tag ####
-Similar to
``\<host\>``, the link may also contain the ``<prop/>`` tag; see the host
+Similar to
the ``<host>`` tag, a link may also contain the ``<prop/>`` tag; see the host
documentation (Section \ref pf_host) for an example.
-TODO
-
\subsubsection pf_backbone <backbone/>
\note
- This tag is <b>only available</b> when the containing AS uses the "Cluster" mode!
+ This tag is <b>only available</b> when the containing AS uses the "Cluster" routing mode!
Using this tag, you can designate an already existing link to be a backbone.
\subsection pf_storage Storage
\note
- This is a prototype version that should evolve quickly, this
- is just some doc valuable only at the time of writing this doc
+ This is a prototype version that should evolve quickly, hence this
+ is just some doc valuable only at the time of writing.
This section describes the storage management under SimGrid ; nowadays
it's only usable with MSG. It relies basically on linux-like concepts.
You also may want to have a look to its corresponding section in \ref
- msg_file_management ; functions access are organized as a POSIX-like
+ msg_file_management ; access functions are organized as a POSIX-like
interface.
-\subsubsection pf_sto_conc Storage Main concepts
-Basically there are 3 different entities available in SimGrid that
-can be used to model storages:
+\subsubsection pf_sto_conc Storage - Main Concepts
+
+The storage facilities implemented in SimGrid help to model (and account for)
+storage devices, such as tapes, hard-drives, CD or DVD devices etc.
+A typical situation is depicted in the figure below:
+
+\image html ./webcruft/storage_sample_scenario.png
+\image latex ./webcruft/storage_sample_scenario.png "storage_sample_scenario" width=\textwidth
+
+In this figure, two hosts called Bob and Alice are interconnected via a network
+and each host is physically attached to a disk; it is not only possible for each host to
+mount the disk they are attached to directly, but they can also mount disks
+that are in a remote location. In this example, Bob mounts Alice's disk remotely
+and accesses the storage via the network.
+
+SimGrid provides 3 different entities that can be used to model setups
+that include storage facilities:
Entity name | Description
--------------- | -----------
-\ref pf_storage_entity_storage_type "storage_type" | Defines a template for a particular kind of storage (such as a hard-drive) and specifies important features of the storage, such as capacity, performance (read/write), content, ... Different models of hard-drives use different storage_types (because the difference between an SSD and an HDD does matter), as they differ in some specifications (e.g., different size or read/write performance).
-\ref pf_storage_entity_storage "storage" | Defines an actual instance of a storage (disk, RAM, ...); uses a ``storage_type`` template (see line above) so that you don't need to re-specify the same details over and over again.
+\ref pf_storage_entity_storage_type "storage_type" | Defines a template for a particular kind of storage (such as a hard-drive) and specifies important features of the storage, such as capacity, performance (read/write), contents, ... Different models of hard-drives use different storage_types (because the difference between an SSD and an HDD does matter), as they differ in some specifications (e.g., different sizes or read/write performance).
+\ref pf_storage_entity_storage "storage" | Defines an actual instance of a storage type (disk, RAM, ...); uses a ``storage_type`` template (see line above) so that you don't need to re-specify the same details over and over again.
\ref pf_storage_entity_mount "mount" | Must be wrapped by a \ref pf_host tag; declares which storage(s) this host has mounted and where (i.e., the mountpoint).
### %Storage Content File ###
In order to assess exactly how much time is spent reading from the storage,
-SimGrid needs to know what is stored in the storage device (identified by distinct (file-)name, like in a file system)
+SimGrid needs to know what is stored on the storage device (identified by distinct (file-)name, like in a file system)
and what size this content has.
\note
storage changes, only the internal SimGrid data structures change.
\anchor pf_storage_content_file_structure
-#### Structure of a %Storage File ####
+#### Structure of a %Storage Content File ####
-Here is an excerpt from two storage file; if you want to see the whole file, check
+Here is an excerpt from two storage content file; if you want to see the whole file, check
the file ``examples/platforms/content/storage_content.txt`` that comes with the
SimGrid source code.
try running this command (works only on unix systems):
\verbatim
-find /path/you/want -type f -exec ls -l {} \; 2>/dev/null > ./content.txt
+find . -type f -exec ls -1s --block=1 {} \; 2>/dev/null | awk '{ print $2 " " $1}' > ./content.txt
\endverbatim
\subsubsection pf_storage_entities The Storage Entities
-------------- | --------- | ------ | -----------
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) that this storage is <i>physically</i> attached to (e.g., a harddrive in a computer)
+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\>"
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 content will be different from Disk1)
+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).
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 via network, but SimGrid automatically takes
+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
\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 storagei, such as HDDs/SSDs, RAM,
+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
#### Example Files ####
-This is an automatically generated list of example files that use the \c <link_ctn/gt;
+This is an automatically generated list of example files that use the \c <link_ctn/>
entity (the path is given relative to SimGrid's source directory):
\verbinclude example_filelist_xmltag_linkctn
