Updated Branches:
  refs/heads/master 0c6c25e6c -> 70c70cafe

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/70c70caf/doc/arch/cache/cache-data-structures.en.rst
----------------------------------------------------------------------
diff --git a/doc/arch/cache/cache-data-structures.en.rst 
b/doc/arch/cache/cache-data-structures.en.rst
old mode 100755
new mode 100644
index 6ce9bc8..508c4da
--- a/doc/arch/cache/cache-data-structures.en.rst
+++ b/doc/arch/cache/cache-data-structures.en.rst
@@ -1,164 +1,164 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-  distributed with this work for additional information
-  regarding copyright ownership.  The ASF licenses this file
-  to you under the Apache License, Version 2.0 (the
-  "License"); you may not use this file except in compliance
-  with the License.  You may obtain a copy of the License at
-
-   http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing,
-  software distributed under the License is distributed on an
-  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-  KIND, either express or implied.  See the License for the
-  specific language governing permissions and limitations
-  under the License.
-
-Cache Data Structures
-******************************
-
-.. include:: common.defs
-
-.. cpp:class:: OpenDir
-
-   An open directory entry. It contains all the information of a 
:cpp:class:`Dir` plus additional information from the first :cpp:class:`Doc`.
-
-.. cpp:class:: CacheVC
-
-   A virtual connection class which accepts input for writing to cache.
-
-.. cpp:function:: int CacheVC::openReadStartHead(int event, Event* e)
-
-   Do the initial read for a cached object.
-
-.. cpp:function:: int CacheVC::openReadStartEarliest(int event, Event* e)
-
-   Do the initial read for an alternate of an object.
-
-.. cpp:class:: HttpTunnel
-
-   Data transfer driver. This contains a set of *producers*. Each producer is 
connected to one or more *consumers*. The tunnel handles events and buffers so 
that data moves from producers to consumers. The data, as much as possible, is 
kept in reference counted buffers so that copies are done only when the data is 
modified or for sources (which acquire data from outside |TS|) and sinks (which 
move data to outside |TS|).
-
-.. cpp:class:: CacheControlResult
-
-   Holds the data from a line in :file:`cache.config`.
-
-.. cpp:class:: CacheHTTPInfoVector
-
-   Defined in |P-CacheHttp.h|_. This is an array of :cpp:class:`HTTPInfo` 
objects and serves as the respository of information about alternates of an 
object. It is marshaled as part of the metadata for an object in the cache.
-
-.. cpp:class:: HTTPInfo
-
-   Defined in |HTTP.h|_.
-
-   This class is a wrapper for :cpp:class:`HTTPCacheAlt`. It provides the 
external API for accessing data in the wrapped class. It contains only a 
pointer (possibly ``NULL``) to an instance of the wrapped class.
-
-.. cpp:class:: CacheHTTPInfo
-
-   A typedef for :cpp:class:`HTTPInfo`.
-
-.. cpp:class:: HTTPCacheAlt
-
-   Defined in |HTTP.h|_.
-
-   This is the metadata for a single alternate for a cached object. In 
contains among other data
-
-   * The key for the earliest ``Doc`` of the alternate.
-   * The request and response headers.
-   * The fragment offset table. [#]_
-   * Timestamps for request and response from origin server.
-
-.. cpp:class:: EvacuationBlock
-
-    Record for evacuation.
-
-.. cpp:class:: Vol
-
-   This represents a storage unit inside a cache volume.
-
-   .. cpp:member:: off_t Vol::segments
-
-      The number of segments in the volume. This will be roughly the total 
number of entries divided by the number of entries in a segment. It will be 
rounded up to cover all entries.
-
-   .. cpp:member:: off_t Vol::buckets
-
-      The number of buckets in the volume. This will be roughly the number of 
entries in a segment divided by ``DIR_DEPTH``. For currently defined values 
this is around 16,384 (2^16 / 4). Buckets are used as the targets of the index 
hash.
-
-   .. cpp:member:: DLL\<EvacuationBlock\> Vol::evacuate
-
-      Array of of :cpp:class:`EvacuationBlock` buckets. This is sized so there 
is one bucket for every evacuation span.
-
-   .. cpp:member:: off_t len
-
-      Length of stripe in bytes.
-
-.. cpp:function:: int Vol::evac_range(off_t low, off_t high, int evac_phase)
-
-   Start an evacuation if there is any :cpp:class:`EvacuationBlock` in the 
range from *low* to *high*. Return 0 if no evacuation was started, non-zero 
otherwise.
-
-.. cpp:class:: CacheVol
-
-   A cache volume as described in :file:`volume.config`.
-
-.. cpp:class:: Doc
-
-   Defined in |P-CacheVol.h|_.
-
-   .. cpp:member:: uint32_t Doc::magic
-
-      Validity check value. Set to ``DOC_MAGIC`` for a valid document.
-
-   .. cpp:member:: uint32_t Doc::len
-
-      The length of this segment including the header length, fragment table, 
and this structure.
-
-   .. cpp:member:: uint64_t Doc::total_len
-
-      Total length of the entire document not including meta data but 
including headers.
-
-   .. cpp:member:: INK_MD5 Doc::first_key
-
-      First index key in the document (the index key used to locate this 
object in the volume index).
-
-   .. cpp:member:: INK_MD5 Doc::key
-
-      The index key for this fragment. Fragment keys are computationally 
chained so that the key for the next and previous fragments can be computed 
from this key.
-
-   .. cpp:member:: uint32_t Doc::hlen
-
-      Document header (metadata) length. This is not the length of the HTTP 
headers.
-
-   .. cpp:member:: uint8_t Doc::ftype
-
-      Fragment type. Currently only `CACHE_FRAG_TYPE_HTTP` is used. Other 
types may be used for cache extensions if those are ever used / implemented.
-
-   .. cpp:member:: uint24_t Doc::flen
-
-      Fragment table length, if any. Only the first ``Doc`` in an object 
should contain a fragment table.
-
-      The fragment table is a list of offsets relative to the HTTP content 
(not counting metadata or HTTP headers). Each offset is the byte offset of the 
first byte in the fragment. The first element in the table is the second 
fragment (what would be index 1 for an array). The offset for the first 
fragment is of course always zero and so not stored. The purpose of this is to 
enable a fast seek for range requests - given the first ``Doc`` the fragment 
containing the first byte in the range can be computed and loaded directly 
without further disk access.
-
-      Removed as of version 3.3.0.
-
-   .. cpp:member:: uint32_t Doc::sync_serial
-
-      Unknown.
-
-   .. cpp:member:: uint32_t Doc::write_serial
-
-      Unknown.
-
-   .. cpp:member:: uint32_t pinned
-
-      Flag and timer for pinned objects.
-
-   .. cpp:member:: uint32_t checksum
-
-      Unknown. (A checksum of some sort)
-
-.. cpp:class:: VolHeaderFooter
-
-.. rubric:: Footnotes
-
-.. [#] Changed in version 3.2.0. This previously resided in the first ``Doc`` 
but that caused different alternates to share the same fragment table.
+.. Licensed to the Apache Software Foundation (ASF) under one
+   or more contributor license agreements.  See the NOTICE file
+  distributed with this work for additional information
+  regarding copyright ownership.  The ASF licenses this file
+  to you under the Apache License, Version 2.0 (the
+  "License"); you may not use this file except in compliance
+  with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing,
+  software distributed under the License is distributed on an
+  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+  KIND, either express or implied.  See the License for the
+  specific language governing permissions and limitations
+  under the License.
+
+Cache Data Structures
+******************************
+
+.. include:: common.defs
+
+.. cpp:class:: OpenDir
+
+   An open directory entry. It contains all the information of a 
:cpp:class:`Dir` plus additional information from the first :cpp:class:`Doc`.
+
+.. cpp:class:: CacheVC
+
+   A virtual connection class which accepts input for writing to cache.
+
+.. cpp:function:: int CacheVC::openReadStartHead(int event, Event* e)
+
+   Do the initial read for a cached object.
+
+.. cpp:function:: int CacheVC::openReadStartEarliest(int event, Event* e)
+
+   Do the initial read for an alternate of an object.
+
+.. cpp:class:: HttpTunnel
+
+   Data transfer driver. This contains a set of *producers*. Each producer is 
connected to one or more *consumers*. The tunnel handles events and buffers so 
that data moves from producers to consumers. The data, as much as possible, is 
kept in reference counted buffers so that copies are done only when the data is 
modified or for sources (which acquire data from outside |TS|) and sinks (which 
move data to outside |TS|).
+
+.. cpp:class:: CacheControlResult
+
+   Holds the data from a line in :file:`cache.config`.
+
+.. cpp:class:: CacheHTTPInfoVector
+
+   Defined in |P-CacheHttp.h|_. This is an array of :cpp:class:`HTTPInfo` 
objects and serves as the respository of information about alternates of an 
object. It is marshaled as part of the metadata for an object in the cache.
+
+.. cpp:class:: HTTPInfo
+
+   Defined in |HTTP.h|_.
+
+   This class is a wrapper for :cpp:class:`HTTPCacheAlt`. It provides the 
external API for accessing data in the wrapped class. It contains only a 
pointer (possibly ``NULL``) to an instance of the wrapped class.
+
+.. cpp:class:: CacheHTTPInfo
+
+   A typedef for :cpp:class:`HTTPInfo`.
+
+.. cpp:class:: HTTPCacheAlt
+
+   Defined in |HTTP.h|_.
+
+   This is the metadata for a single alternate for a cached object. In 
contains among other data
+
+   * The key for the earliest ``Doc`` of the alternate.
+   * The request and response headers.
+   * The fragment offset table. [#]_
+   * Timestamps for request and response from origin server.
+
+.. cpp:class:: EvacuationBlock
+
+    Record for evacuation.
+
+.. cpp:class:: Vol
+
+   This represents a storage unit inside a cache volume.
+
+   .. cpp:member:: off_t Vol::segments
+
+      The number of segments in the volume. This will be roughly the total 
number of entries divided by the number of entries in a segment. It will be 
rounded up to cover all entries.
+
+   .. cpp:member:: off_t Vol::buckets
+
+      The number of buckets in the volume. This will be roughly the number of 
entries in a segment divided by ``DIR_DEPTH``. For currently defined values 
this is around 16,384 (2^16 / 4). Buckets are used as the targets of the index 
hash.
+
+   .. cpp:member:: DLL\<EvacuationBlock\> Vol::evacuate
+
+      Array of of :cpp:class:`EvacuationBlock` buckets. This is sized so there 
is one bucket for every evacuation span.
+
+   .. cpp:member:: off_t len
+
+      Length of stripe in bytes.
+
+.. cpp:function:: int Vol::evac_range(off_t low, off_t high, int evac_phase)
+
+   Start an evacuation if there is any :cpp:class:`EvacuationBlock` in the 
range from *low* to *high*. Return 0 if no evacuation was started, non-zero 
otherwise.
+
+.. cpp:class:: CacheVol
+
+   A cache volume as described in :file:`volume.config`.
+
+.. cpp:class:: Doc
+
+   Defined in |P-CacheVol.h|_.
+
+   .. cpp:member:: uint32_t Doc::magic
+
+      Validity check value. Set to ``DOC_MAGIC`` for a valid document.
+
+   .. cpp:member:: uint32_t Doc::len
+
+      The length of this segment including the header length, fragment table, 
and this structure.
+
+   .. cpp:member:: uint64_t Doc::total_len
+
+      Total length of the entire document not including meta data but 
including headers.
+
+   .. cpp:member:: INK_MD5 Doc::first_key
+
+      First index key in the document (the index key used to locate this 
object in the volume index).
+
+   .. cpp:member:: INK_MD5 Doc::key
+
+      The index key for this fragment. Fragment keys are computationally 
chained so that the key for the next and previous fragments can be computed 
from this key.
+
+   .. cpp:member:: uint32_t Doc::hlen
+
+      Document header (metadata) length. This is not the length of the HTTP 
headers.
+
+   .. cpp:member:: uint8_t Doc::ftype
+
+      Fragment type. Currently only `CACHE_FRAG_TYPE_HTTP` is used. Other 
types may be used for cache extensions if those are ever used / implemented.
+
+   .. cpp:member:: uint24_t Doc::flen
+
+      Fragment table length, if any. Only the first ``Doc`` in an object 
should contain a fragment table.
+
+      The fragment table is a list of offsets relative to the HTTP content 
(not counting metadata or HTTP headers). Each offset is the byte offset of the 
first byte in the fragment. The first element in the table is the second 
fragment (what would be index 1 for an array). The offset for the first 
fragment is of course always zero and so not stored. The purpose of this is to 
enable a fast seek for range requests - given the first ``Doc`` the fragment 
containing the first byte in the range can be computed and loaded directly 
without further disk access.
+
+      Removed as of version 3.3.0.
+
+   .. cpp:member:: uint32_t Doc::sync_serial
+
+      Unknown.
+
+   .. cpp:member:: uint32_t Doc::write_serial
+
+      Unknown.
+
+   .. cpp:member:: uint32_t pinned
+
+      Flag and timer for pinned objects.
+
+   .. cpp:member:: uint32_t checksum
+
+      Unknown. (A checksum of some sort)
+
+.. cpp:class:: VolHeaderFooter
+
+.. rubric:: Footnotes
+
+.. [#] Changed in version 3.2.0. This previously resided in the first ``Doc`` 
but that caused different alternates to share the same fragment table.

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/70c70caf/doc/arch/cache/images/ats-cache-write-cursor.png
----------------------------------------------------------------------
diff --git a/doc/arch/cache/images/ats-cache-write-cursor.png 
b/doc/arch/cache/images/ats-cache-write-cursor.png
old mode 100755
new mode 100644

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/70c70caf/doc/arch/cache/images/cache-directory-structure.png
----------------------------------------------------------------------
diff --git a/doc/arch/cache/images/cache-directory-structure.png 
b/doc/arch/cache/images/cache-directory-structure.png
old mode 100755
new mode 100644

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/70c70caf/doc/arch/cache/images/cache-doc-layout-3-2-0.png
----------------------------------------------------------------------
diff --git a/doc/arch/cache/images/cache-doc-layout-3-2-0.png 
b/doc/arch/cache/images/cache-doc-layout-3-2-0.png
old mode 100755
new mode 100644

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/70c70caf/doc/arch/cache/images/cache-doc-layout-4-0-1.png
----------------------------------------------------------------------
diff --git a/doc/arch/cache/images/cache-doc-layout-4-0-1.png 
b/doc/arch/cache/images/cache-doc-layout-4-0-1.png
old mode 100755
new mode 100644

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/70c70caf/doc/arch/cache/images/cache-multi-fragment.png
----------------------------------------------------------------------
diff --git a/doc/arch/cache/images/cache-multi-fragment.png 
b/doc/arch/cache/images/cache-multi-fragment.png
old mode 100755
new mode 100644

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/70c70caf/doc/arch/cache/images/cache-stripe-layout.png
----------------------------------------------------------------------
diff --git a/doc/arch/cache/images/cache-stripe-layout.png 
b/doc/arch/cache/images/cache-stripe-layout.png
old mode 100755
new mode 100644

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/70c70caf/doc/arch/cache/images/dir-bucket-assign.png
----------------------------------------------------------------------
diff --git a/doc/arch/cache/images/dir-bucket-assign.png 
b/doc/arch/cache/images/dir-bucket-assign.png
old mode 100755
new mode 100644

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/70c70caf/doc/arch/cache/images/dir-segment-bucket.png
----------------------------------------------------------------------
diff --git a/doc/arch/cache/images/dir-segment-bucket.png 
b/doc/arch/cache/images/dir-segment-bucket.png
old mode 100755
new mode 100644

http://git-wip-us.apache.org/repos/asf/trafficserver/blob/70c70caf/doc/arch/cache/tier-storage.en.rst
----------------------------------------------------------------------
diff --git a/doc/arch/cache/tier-storage.en.rst 
b/doc/arch/cache/tier-storage.en.rst
old mode 100755
new mode 100644
index a379a27..b802929
--- a/doc/arch/cache/tier-storage.en.rst
+++ b/doc/arch/cache/tier-storage.en.rst
@@ -1,118 +1,118 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-
-   http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-==============================
-Tiered Storage Design
-==============================
-
-.. include:: common.defs
-
---------------
-Introduction
---------------
-
-Tiered storage is an attempt to allow |TS| to take advantage of physical 
storage with different properties. This design
-concerns only mechanism. Policies to take advantage of these are outside of 
the scope of this document. Instead we will
-presume an *oracle* which implements this policy and describe the queries that 
must be answered by the oracle and the
-effects of the answers.
-
-Beyond avoiding question of tier policy the design is also intended to be 
effectively identical to current operations
-for the case where there is only one tier.
-
-The most common case for tiers is an ordered list of tiers, where higher tiers 
are presumed faster but more expensive
-(or more limited in capacity). This is not required. It might be that 
different tiers are differentiated by other
-properties (such as expected persistence). The design here is intended to 
handle both cases.
-
-The design presumes that if a user has multiple tiers of storage and an 
ordering for those tiers, he will usually want
-content stored at one tier level to also be stored at every other lower level 
as well, so that it does not have to be
-copied if evicted from a higher tier.
-
--------------
-Configuration
--------------
-
-Each storage unit in :file:`storage.config` can be marked with a *quality* 
value which is 32 bit number. Storage units
-that are not marked are all assigned the same value which is guaranteed to be 
distinct from all explicit values. The
-quality value is arbitrary from the point of view of this design, serving as a 
tag rather than a numeric value. The user
-(via the oracle) can impose what ever additional meaning is useful on this 
value (rating, bit slicing, etc.). In such
-cases all volumes should be explicitly assigned a value, as the default / 
unmarked value is not guaranteed to have any
-relationship to explicit values. The unmarked value is intended to be useful 
in situations where the user has no
-interest in tiered storage and so wants to let Traffic Server automatically 
handle all volumes as a single tier.
-
--------------
-Operations
--------------
-
-After a client request is received and processed, volume assignment is done. 
This would be changed to do volume assignment across all tiers simultaneously. 
For each tier the oracle would return one of four values along with a volume 
pointer.
-
-`READ`
-    The tier appears to have the object and can serve it.
-
-`WRITE`
-    The object is not in this tier and should be written to this tier if 
possible.
-
-`RW`
-    Treat as `READ` if possible but if the object turns out to not in the 
cache treat as `WRITE`.
-
-`NO_SALE`
-    Do not interact with this tier for this object.
-
-The volume returned for the tier must be a volume with the corresponding tier 
quality value. In effect the current style
-of volume assignment is done for each tier, by assigning one volume out of all 
of the volumes of the same quality and
-returning one of `RW` or `WRITE` depending on whether the initial volume 
directory lookup succeeds. Note that as with
-current volume assignment it is presumed this can be done from in memory 
structures (no disk I/O required).
-
-If the oracle returns `READ` or `RW` for more than one tier, it must also 
return an ordering for those tiers (it may
-return an ordering for all tiers, ones that are not readable will be ignored). 
For each tier, in that order, a read of
-cache storage is attempted for the object. A successful read locks that tier 
as the provider of cached content. If no
-tier has a successful read, or no tier is marked `READ` or `RW` then it is a 
cache miss. Any tier marked `RW` that fails
-the read test is demoted to `WRITE`.
-
-If the object is cached every tier that returns `WRITE` receives the object to 
store in the selected volume (this
-includes `RW` returns that are demoted to `WRITE`). This is a cache to cache 
copy, not from the origin server. In this
-case tiers marked `RW` that are not tested for read will not receive any data 
and will not be further involved in the
-request processing.
-
-For a cache miss, all tiers marked `WRITE` will receive data from the origin 
server connection (if successful).
-
-This means, among other things, that if there is a tier with the object all 
other tiers that are written will get a
-local copy of the object, the origin server will not be used. In terms of 
implementation, currently a cache write to a
-volume is done via the construction of an instance of `CacheVC` which recieves 
the object stream. For tiered storage the
-same thing is done for each target volume.
-
-For cache volume overrides (e.g. via :file:`hosting.config`) this same process 
is used except with only the volumes
-stripes contained within the specified cache volume.
-
--------
-Copying
--------
-
-It may be necessary to provide a mechanism to copy objects between tiers 
outside of a client originated transaction. In
-terms of implementation this is straight forward using `HttpTunnel` as if in a 
transaction only using a `CacheVC`
-instance for both the producer and consumer. The more difficult question is 
what event would trigger a possible copy. A
-signal could be provided whenever a volume directory entry is deleted although 
it should be noted that the object in
-question may have already been evicted when this event happens.
-
-----------------
-Additional Notes
-----------------
-
-As an example use, it would be possible to have only one cache volume that 
uses tiered storage for a particular set of
-domains using volume tagging. :file:`hosting.config` would be used to direct 
those domains to the selected cache volume.
-The oracle would check the URL in parallel and return `NO_SALE` for the tiers 
in the target cache volume for other
-domains. For the other tier (that of the unmarked storage units) the oracle 
would return `RW` for the tier in all cases
-as that tier would not be queried for the target domains.
+.. Licensed to the Apache Software Foundation (ASF) under one
+   or more contributor license agreements.  See the NOTICE file
+   distributed with this work for additional information
+   regarding copyright ownership.  The ASF licenses this file
+   to you under the Apache License, Version 2.0 (the
+   "License"); you may not use this file except in compliance
+   with the License.  You may obtain a copy of the License at
+
+   http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing,
+   software distributed under the License is distributed on an
+   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+   KIND, either express or implied.  See the License for the
+   specific language governing permissions and limitations
+   under the License.
+
+==============================
+Tiered Storage Design
+==============================
+
+.. include:: common.defs
+
+--------------
+Introduction
+--------------
+
+Tiered storage is an attempt to allow |TS| to take advantage of physical 
storage with different properties. This design
+concerns only mechanism. Policies to take advantage of these are outside of 
the scope of this document. Instead we will
+presume an *oracle* which implements this policy and describe the queries that 
must be answered by the oracle and the
+effects of the answers.
+
+Beyond avoiding question of tier policy the design is also intended to be 
effectively identical to current operations
+for the case where there is only one tier.
+
+The most common case for tiers is an ordered list of tiers, where higher tiers 
are presumed faster but more expensive
+(or more limited in capacity). This is not required. It might be that 
different tiers are differentiated by other
+properties (such as expected persistence). The design here is intended to 
handle both cases.
+
+The design presumes that if a user has multiple tiers of storage and an 
ordering for those tiers, he will usually want
+content stored at one tier level to also be stored at every other lower level 
as well, so that it does not have to be
+copied if evicted from a higher tier.
+
+-------------
+Configuration
+-------------
+
+Each storage unit in :file:`storage.config` can be marked with a *quality* 
value which is 32 bit number. Storage units
+that are not marked are all assigned the same value which is guaranteed to be 
distinct from all explicit values. The
+quality value is arbitrary from the point of view of this design, serving as a 
tag rather than a numeric value. The user
+(via the oracle) can impose what ever additional meaning is useful on this 
value (rating, bit slicing, etc.). In such
+cases all volumes should be explicitly assigned a value, as the default / 
unmarked value is not guaranteed to have any
+relationship to explicit values. The unmarked value is intended to be useful 
in situations where the user has no
+interest in tiered storage and so wants to let Traffic Server automatically 
handle all volumes as a single tier.
+
+-------------
+Operations
+-------------
+
+After a client request is received and processed, volume assignment is done. 
This would be changed to do volume assignment across all tiers simultaneously. 
For each tier the oracle would return one of four values along with a volume 
pointer.
+
+`READ`
+    The tier appears to have the object and can serve it.
+
+`WRITE`
+    The object is not in this tier and should be written to this tier if 
possible.
+
+`RW`
+    Treat as `READ` if possible but if the object turns out to not in the 
cache treat as `WRITE`.
+
+`NO_SALE`
+    Do not interact with this tier for this object.
+
+The volume returned for the tier must be a volume with the corresponding tier 
quality value. In effect the current style
+of volume assignment is done for each tier, by assigning one volume out of all 
of the volumes of the same quality and
+returning one of `RW` or `WRITE` depending on whether the initial volume 
directory lookup succeeds. Note that as with
+current volume assignment it is presumed this can be done from in memory 
structures (no disk I/O required).
+
+If the oracle returns `READ` or `RW` for more than one tier, it must also 
return an ordering for those tiers (it may
+return an ordering for all tiers, ones that are not readable will be ignored). 
For each tier, in that order, a read of
+cache storage is attempted for the object. A successful read locks that tier 
as the provider of cached content. If no
+tier has a successful read, or no tier is marked `READ` or `RW` then it is a 
cache miss. Any tier marked `RW` that fails
+the read test is demoted to `WRITE`.
+
+If the object is cached every tier that returns `WRITE` receives the object to 
store in the selected volume (this
+includes `RW` returns that are demoted to `WRITE`). This is a cache to cache 
copy, not from the origin server. In this
+case tiers marked `RW` that are not tested for read will not receive any data 
and will not be further involved in the
+request processing.
+
+For a cache miss, all tiers marked `WRITE` will receive data from the origin 
server connection (if successful).
+
+This means, among other things, that if there is a tier with the object all 
other tiers that are written will get a
+local copy of the object, the origin server will not be used. In terms of 
implementation, currently a cache write to a
+volume is done via the construction of an instance of `CacheVC` which recieves 
the object stream. For tiered storage the
+same thing is done for each target volume.
+
+For cache volume overrides (e.g. via :file:`hosting.config`) this same process 
is used except with only the volumes
+stripes contained within the specified cache volume.
+
+-------
+Copying
+-------
+
+It may be necessary to provide a mechanism to copy objects between tiers 
outside of a client originated transaction. In
+terms of implementation this is straight forward using `HttpTunnel` as if in a 
transaction only using a `CacheVC`
+instance for both the producer and consumer. The more difficult question is 
what event would trigger a possible copy. A
+signal could be provided whenever a volume directory entry is deleted although 
it should be noted that the object in
+question may have already been evicted when this event happens.
+
+----------------
+Additional Notes
+----------------
+
+As an example use, it would be possible to have only one cache volume that 
uses tiered storage for a particular set of
+domains using volume tagging. :file:`hosting.config` would be used to direct 
those domains to the selected cache volume.
+The oracle would check the URL in parallel and return `NO_SALE` for the tiers 
in the target cache volume for other
+domains. For the other tier (that of the unmarked storage units) the oracle 
would return `RW` for the tier in all cases
+as that tier would not be queried for the target domains.

Reply via email to