Merge remote-tracking branch 'origin/master' into buildtree_runner

doc/CHEP2016/CHEP_2016_paper_CTA.tex

@@ -214,7 +214,7 @@ to route EOS disk files to specific tape pools:
   \item Tape pool.
   \item Archive route.
 \end{itemize}
-An EOS user archives a file to tape by copying the file into to an EOS directory
+An EOS user archives a file to tape by copying the file into an EOS directory
 that has been tagged with a CTA storage class.  Within the EOS namespace a CTA
 storage class is simply a name.  For example the \texttt{raw\_data} storage
 class could be used to refer to user files that should have one copy on tape and
@@ -276,12 +276,12 @@ of the jobs it contains to allow efficient mount scheduling.
 \subsection{Tape mount scheduling and job handling}
 Several competing requirements need to be taken into account when scheduling tape
 drives.  User-initiated accesses in both directions should be executed within a
-bound latency (measured in the order of hours). As mounting and dismounting tape
-cartridges to and from a drive costs about a minute each, the execution of a data
-access is postponed until the amount of data to transfer makes it worthwhile
-or the job age is too high. User initiated mounts create an irregular demand,
-driven by the accelerator cycles and experiment data taking, as well as various
-analysis patterns.
+bound latency (measured in the order of hours). Mounting and dismounting a tape
+cartridge to and from a drive can take several minutes.  The execution of a data
+access is therefore postponed until the amount of data to transfer makes it
+worthwhile or the job age is too high. User initiated mounts create an irregular
+demand, driven by the accelerator cycles and experiment data taking, as well as
+various analysis patterns.
 
 The maintenance tasks of retrieving and archiving for repack, and retrieving for
 data verification are high bandwidth tasks with very relaxed latency
@@ -304,10 +304,11 @@ adjustments are expected as experience with CTA grows.
 \subsection{Tape drive pre-emption}
 A background task that repacks or verifies a whole tape can take several hours.
 Such long duration background tasks must be pre-empted when higher priority user
-tasks arrive in order to meet the latency requirements of users.  The tape
-daemon will keep polling the scheduling information at a low rate and interrupt
-a low priority background task if a higher priority one is available to replace
-it.
+tasks arrive in order to meet the latency requirements of users.  A pre-empted
+background task will be resumed at a later point in time when it again becomes
+the highest priority task.  The tape daemon will keep polling the scheduling
+information at a low rate and interrupt a low priority background task if a
+higher priority one is available to replace it.
 
 This mixing of high and low priority tasks previously had to be handled by hand or \textit{ad hoc}
 scripts in CASTOR.