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.
