[AFS3-std] Request to create a Dump Tag registry
Jeffrey E Altman
openafs-devel@openafs.org" <openafs-devel@openafs.org
Wed, 12 Oct 2022 23:40:09 -0400
This is a cryptographically signed message in MIME format.
--------------ms070405000404050506010705
Content-Type: multipart/alternative;
boundary="------------74Zi0JE9HnrPq0zpCxyga8gk"
--------------74Zi0JE9HnrPq0zpCxyga8gk
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
AuriStor has been investigating extending the Dump Stream to support the
functionality proposed in April 2011 as RPC Refresh (Gerrit 4573) as
well as additional data and metadata types implemented by AuriStorFS.
To avoid unnecessary collisions and to maximize interoperability I
propose the creation of a Dump Tag Registry.
The Dump Format is poorly documented and many tags and sub-tags have
been squatted upon over the years without creation of a registry. The
original Dump Format did not provide any mechanism for backward
compatibility. The structure of the data following a Tag or Sub-Tag
could not be determined independent of any particular implementation.
For example, when OpenAFS introduced the D_VNODE 'h' Sub-Tag to
represent the lengths of vnodes larger than 2GB any dump stream that
included the D_VNODE 'h' sub-tag could not be parsed by an earlier
version of IBM AFS or OpenAFS. It can be argued that in this particular
case the ability to understand 64-bit lengths should be considered
critical and therefore parsing the dump stream should fail. The same
case cannot be made for the D_VOLUMEHEADER 'V' (volume update counter)
sub-tag that was introduced in October 2005. An inability to parse and
restore this counter should not prevent a backup dump stream from being
used to recover the contents of a Volume.
In March 2005 Peter Somogyi proposed a solution submitted as OpenAFS RT
17947 which requested that OpenAFS implement a mechanism for storing
Vnode Data in compressed form. The data compression implementation was
never adopted by OpenAFS but in September 2009 OpenAFS adopted a
framework which would permit tags and sub-tags to be introduced in the
future without breaking compatibility with earlier versions of OpenAFS
that implemented the framework. OpenAFS 1.4.12 was the first production
release to implement the framework.
The text of the proposed framework was forwarded to afs3-standardization
in October 2007.
https://lists.openafs.org/pipermail/afs3-standardization/2007-October/001053.html
OpenAFS adopted the TLV standard for future tags by merging
https://gerrit.openafs.org/#/c/191/4
The framework extends the pre-existing Dump Format as follows:
1. Valid Dump or "D" Header Tag values range from 0x1 to 0x15
1. The four tags in use before the adoption of the framework are
declared "Legacy"
1. 0x01 D_DUMPHEADER
2. 0x02 D_VOLUMEHEADER
3. 0x03 D_VNODE
4. 0x04 D_DUMPEND
2. The remaining tags are designated Tag-Length-Value (TLV) tags
3. Each D Header tag has its own private namespace of sub-tags
2. Valid Sub-Tags values range from 0x16 to 0x7d
1. All D_VOLUMEHEADER and D_VNODE Sub-tags in use before the
adoption of the framework are declared "Legacy"
2. Non-legacy sub-tags between 0x16 and 0x60 are designated TLV
sub-tags.
3. Non-legacy sub-tags between 0x61 and 0x7a are designated
Standard sub-tags where the sub-tag is followed by a fixed
32-bit integer value in network-byte-order.
4. Non-legacy sub-tags between 0x7b and 0x7d are designated
Dataless sub-tags which are not followed by any data.
3. Tag 0x0 is reserved and currently invalid
4. Tag0x7e is dataless and has the special meaning that the Next Tag or
Sub-tag is CRITICAL. Failure to recognize the meaning of the Tag or
Sub-tag must result in a fatal failure.
5. Tag 0x7f is reserved.
TLV tags are followed by a variable length "Length" field which is then
followed by the specified number of octets. The variable length
"Length" is parsed as follows:
1. If the first octet is less than or equal to 0x7f, then the Value
that follows is that number of octets.
2. If the first octet is 0x80, then the Value that follows is of
indefinite length. The value data that follows must be
self-describing with regards to length. In other words, a parser
that understands the data format must be able to identify the end of
the value from the contents of the data. If an indefinite length
tag or sub-tag is unrecognized, it is a fatal error regardless of
whether or not the CRITICAL tag preceded it.
3. If the first octet 'L' is between 0x81 and 0x88, the length is value
of the next (L & 0x0f) octets combined in most significant byte
(MSB) order. 0x81 indicates one byte, 0x82 two bytes, 0x88 eight bytes.
4. If the first octet is greater than 0x88, it is an invalid length
which is a fatal error.
The OpenAFS implementation has the following deficiencies:
1. It does not handle parsing of unrecognized D Tags.
2. The MIN_TLV_TAG sub-tag must be 0x16 not 0x5.
3. Tag values up to and including D_MAX (20) must not be used as sub-tags.
4. The Legacy tag table is incomplete.
Initial Registry Contents:
I propose that all of the following tags and sub-tags be added to the
registry. Sub-tags designated as deprecated are known to have been
stored in backups and therefore might be present in a restored dump
stream at some point in the future. Deprecated sub-tags should be
avoided but might be reallocated if all other sub-tags are in use.
I propose that new tags be allocated on a first come, first served basis
with a documentation requirement. Documentation must be provided that is
sufficient to permit a dump stream to be restored if non-critical
unrecognized tags are included in the stream. A stream containing
unrecognized critical tags will fail to restore but sufficient
documentation must be present for a site to evaluate the risk associated
with the criticality.
When designing new tags for registration developers should consider use
by the entire ecosystem. For example, in addressing the Year 2038
problem new tags to transmit 64-bit 100ns timestamps for vnodes and
volumes should be reusable by many implementations. The same should be
true for 64-bit data versions, 96-bit vnode ids, 64-bit volume ids,
64-bit user ids, longer volume names, 64-bit volume quotas, and 64-bit
volume space usage. The Dump Header will require new tags for 64-bit
100ns timestamps, 64-bit volume ids, and longer volume names,
D Header Tags:
0x01 D_DUMPHEADER IBM Legacy
0x02 D_VOLUMEHEADER IBM Legacy
0x03 D_VNODE IBM Legacy
0x04 D_DUMPEND IBM Legacy
D_DUMPHEADER Sub-Tags
21 0x15 64-bit Volume ID AuriStor TLV
22 0x16 100ns Dump Times AuriStor TLV
'n' 0x6e Volume Name IBM Legacy: C-String
't' 0x74 32-bit Dump Times IBM Legacy
'v' 0x76 32-bit Volume ID IBM Legacy
D_VOLUMEHEADER Sub-Tags
21 0x15 64-bit Volume IDs AuriStor TLV
22 0x16 Volume Maximum ACL AuriStor TLV
23 0x17 Volume Sec Levels AuriStor TLV
24 0x18 64-bit Max Quota AuriStor TLV
25 0x19 64-bit Disk Usage AuriStor TLV
26 0x1a 100ns Timestamps AuriStor TLV
27 0x1b 64-bit Features AuriStor TLV
28 0x1c 64-bit Owner AuriStor TLV
29 0x1d 64-bit Min Quota AuriStor TLV
30 0x1e 64-bit File Count AuriStor TLV
'A' 0x41 32-bit Last Access Date OSD Legacy
'B' 0x42 32-bit Backup Date IBM Legacy
'C' 0x43 32-bit Creation Date IBM Legacy
'D' 0x44 32-bit Day Use Date IBM Legacy
'E' 0x45 32-bit Expiration Date IBM Legacy
'F' 0x46 OSD Policy OSD Legacy: 32-bit [deprecated - replaced by 'P']
'M' 0x4d MOTD IBM Legacy: C-String
'O' 0x4f Offline Message IBM Legacy: C-String
'P' 0x50 OSD Policy OSD Legacy: 32-bit [deprecated - replaced by 'y']
'U' 0x55 32-bit Update Date IBM Legacy
'V' 0x56 32-bit Update Counter OpenAFS Legacy
'W' 0x57 Week Use Statistics IBM Legacy: structure
'Z' 0x5a Day Use Statistics IBM Legacy
'a' 0x61 Account Number IBM Standard [deprecated]
'b' 0x62 Blessed Flag IBM Legacy: 8-bit
'c' 0x63 32-bit Clone Id IBM Standard
'd' 0x64 32-bit Disk Usage IBM Standard
'f' 0x66 32-bit File Count IBM Standard
'i' 0x69 32-bit Volume Id IBM Standard
'm' 0x6d 32-bit Volume Min Quota IBM Standard
'n' 0x6e Volume Name IBM Legacy: C-String
'o' 0x6f 32-bit Volume Owner IBM Standard
'p' 0x70 32-bit Parent Volume Id IBM Standard
'q' 0x71 32-bit Volume Max Quota IBM Standard
'r' 0x72 OSD Max number of files OSD Standard
's' 0x73 In-Service Flag IBM Legacy: 8-bit
't' 0x74 Volume Type IBM Legacy: 8-bit
'u' 0x75 32-bit Next Uniquifier IBM Standard
'v' 0x76 32-bit Stamp Version IBM Standard [deprecated]
'y' 0x79 OSD Policy OSD Standard
D_VNODE Sub-Tags
21 0x15 File ACL AuriStor TLV [deprecated]
22 0x16 100ns Timestamps AuriStor TLV
23 0x17 64-bit A, O, G IDs AuriStor TLV
24 0x18 96-bit Vnode# Parent# AuriStor TLV
25 0x19 64-bit Data Version AuriStor TLV
26 0x1a 64-bit Ext ACL AuriStor TLV
'A' 0x41 32-bit ACL IBM Legacy: C-String
'L' 0x4c OSD vnode length (hi,lo) OSD TLV
'O' 0x4f OSD metadata string OSD TLV
'P' 0x50 OSD dir policy index OSD Legacy: 32-bit [deprecated - replaced by 'd']
'a' 0x61 32-bit Author ID IBM Standard
'b' 0x62 Unix Mode Bits IBM Legacy: 16-bit
'd' 0x64 OSD dir policy index OSD Standard
'f' 0x66 File Stream - Small IBM Legacy: structured
'g' 0x67 32-bit Group ID IBM Standard
'h' 0x68 File Stream - Large OpenAFS Legacy: structured
'l' 0x6c Link Count IBM Legacy: 16-bit
'm' 0x6d 32-bit UNIX Modify Time IBM Standard
'o' 0x6f 32-bit Owner ID IBM Standard
'p' 0x70 32-bit Parent Vnode # IBM Standard
's' 0x73 32-bit Server Modify Time IBM Standard
't' 0x74 Vnode Type IBM Legacy: 8-bit
'u' 0x75 32-bit Last Access Time OSD Standard [deprecated]
'v' 0x76 32-bit Data Version IBM Standard
'x' 0x78 OSD File Online Flag OSD Standard
'y' 0x79 OSD vnode length OSD Legacy: structure [deprecated - replaced by 'L']
'z' 0x7a OSD metadata string OSD Legacy: C-String [deprecated - replaced by 'O']
Guidance for Use of New Tags
1. If a new sub-tag is allocated to support a larger value, for example
D_VOLUMEHEADER 0x15 "64-bit IDs" which can replace 0x69 "32-bit
Volume Id", 0x70 "32-bit Parent Id", and 0x63 "Clone Id", then the
new tag should only be generated if the data values cannot be
represented by the older tag. If the new tag is used, it should be
preceded by the CRITICAL tag.
2. If a new sub-tag is allocated to augment existing data, then both
sub-tags should be generated. For example, the D_VOLUMEHEADER 0x16
"100ns timestamps" provides 100ns granularity for accessDate,
updateDate, creationDate, backupDate and expirationDate. This
sub-tag should be generated in addition to the 32-bit second
granularity equivalents. The new sub-tag should not be preceded by
the CRITICAL tag. This permits the dump stream to be restored both
to systems that understand 100ns timestamps and those that do not.
Please note that I did not include the RT 17947 Compression D Tags:
D_COMPRESS_TAG (0x5) and D_FLAGS_TAG (0x6) in the list of registered
tags. There are two reasons for this. First, to the best of my
knowledge the Compression Proposal was never put into production.
Second, I believe the allocation of D_COMPRESS_TAG and D_FLAGS_TAG out
of the Dump Header namespace was a mistake. If anyone revisits the
Compression proposal I believe that the details of the compression
should be sent either via D_DUMPHEADER sub-tags or D_VOLUMEHEADER
sub-tags; and a new D_VNODE sub-tag should be used to store the
Compressed File Stream. The choice of D_DUMPHEADER vs D_VOLUMEHEADER
depends on whether or not all of the components of a "merged dump"
stream must share the same compression options. If yes, then
D_DUMPHEADER is the preferred location. If not, then D_VOLUMEHEADER
should be used.
For those that are not familiar with a "merged dump", incremental dump
streams can be merged into a full dump stream by:
1. merging the D_DUMPHEADER "from".."to" time range into the
D_DUMPHEADER at the start of the stream
2. remove the D_DUMPEND header from the end of the first stream
3. remove the D_DUMPHEADER from the stream to be appended
4. concatenate the two streams producing a stream with multiple
D_VOLUMEHEADER blocks each of which are followed by one or more
D_VNODE blocks.
A merged stream can be used to restore a volume in a single RPC.
If anyone is familiar with other Tags and Sub-tags that are in use,
please let me know.
I will provide additional details of the AuriStor sub-tags to the
Registrar once a Registry has been published.
Sincerely,
Jeffrey Altman
--------------74Zi0JE9HnrPq0zpCxyga8gk
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Gill Sans MT">AuriStor has been investigating
extending the Dump Stream to support the functionality proposed
in April 2011 as RPC Refresh (Gerrit 4573) as well as additional
data and metadata types implemented by AuriStorFS. To avoid
unnecessary collisions and to maximize interoperability I
propose the creation of a Dump Tag Registry.<br>
</font></p>
<p><font face="Gill Sans MT">The Dump Format is poorly documented
and many tags and sub-tags have been squatted upon over the
years without creation of a registry. The original Dump Format
did not provide any mechanism for backward compatibility. The
structure of the data following a Tag or Sub-Tag could not be
determined independent of any particular implementation. For
example, when OpenAFS introduced the D_VNODE 'h' Sub-Tag to
represent the lengths of vnodes larger than 2GB any dump stream
that included the D_VNODE 'h' sub-tag could not be parsed by an
earlier version of IBM AFS or OpenAFS. It can be argued that in
this particular case the ability to understand 64-bit lengths
should be considered critical and therefore parsing the dump
stream should fail. The same case cannot be made for the
D_VOLUMEHEADER 'V' (volume update counter) sub-tag that was
introduced in October 2005. An inability to parse and restore
this counter should not prevent a backup dump stream from being
used to recover the contents of a Volume.<br>
</font></p>
<p>In March 2005 Peter Somogyi proposed a solution submitted as
OpenAFS RT 17947 which requested that OpenAFS implement a
mechanism for storing Vnode Data in compressed form. The data
compression implementation was never adopted by OpenAFS but in
September 2009 OpenAFS adopted a framework which would permit tags
and sub-tags to be introduced in the future without breaking
compatibility with earlier versions of OpenAFS that implemented
the framework. OpenAFS 1.4.12 was the first production release to
implement the framework.</p>
<p>The text of the proposed framework was forwarded to
afs3-standardization in October 2007. <br>
</p>
<p><font face="Gill Sans MT">
<a class="moz-txt-link-freetext"
href="https://lists.openafs.org/pipermail/afs3-standardization/2007-October/001053.html">https://lists.openafs.org/pipermail/afs3-standardization/2007-October/001053.html</a></font></p>
<p><font face="Gill Sans MT">OpenAFS adopted the TLV standard for
future tags by merging <br>
</font></p>
<p><font face="Gill Sans MT"> <a class="moz-txt-link-freetext"
href="https://gerrit.openafs.org/#/c/191/4">https://gerrit.openafs.org/#/c/191/4</a></font></p>
<p><font face="Gill Sans MT">The framework extends the pre-existing
Dump Format as follows:</font></p>
<ol>
<li><font face="Gill Sans MT">Valid Dump or "D" Header Tag values
range from 0x1 to 0x15</font></li>
<ol>
<li><font face="Gill Sans MT">The four tags in use before the
adoption of the framework are declared "Legacy"</font></li>
<ol>
<li><font face="Gill Sans MT">0x01 D_DUMPHEADER</font></li>
<li><font face="Gill Sans MT">0x02 D_VOLUMEHEADER</font></li>
<li><font face="Gill Sans MT">0x03 D_VNODE</font></li>
<li><font face="Gill Sans MT">0x04 D_DUMPEND</font></li>
</ol>
<li><font face="Gill Sans MT">The remaining tags are designated
Tag-Length-Value (TLV) tags</font></li>
<li><font face="Gill Sans MT">Each D Header tag has its own
private namespace of sub-tags</font></li>
</ol>
<li><font face="Gill Sans MT">Valid Sub-Tags values range from
0x16 to 0x7d</font></li>
<ol>
<li><font face="Gill Sans MT">All D_VOLUMEHEADER and D_VNODE
Sub-tags in use before the adoption of the framework are
declared "Legacy"</font></li>
<li><font face="Gill Sans MT">Non-legacy sub-tags between 0x16
and 0x60 are designated TLV sub-tags.</font></li>
<li><font face="Gill Sans MT">Non-legacy sub-tags between 0x61
and 0x7a are designated Standard sub-tags where the sub-tag
is followed by a fixed 32-bit integer value in
network-byte-order.</font></li>
<li><font face="Gill Sans MT">Non-legacy sub-tags between 0x7b
and 0x7d are designated Dataless sub-tags which are not
followed by any data.</font></li>
</ol>
<li><font face="Gill Sans MT">Tag 0x0 is reserved and currently
invalid</font></li>
<li><font face="Gill Sans MT">Tag</font><font face="Gill Sans MT">
0x7e is dataless and has the special meaning that the Next Tag
or Sub-tag is CRITICAL. Failure to recognize the meaning of
the Tag or Sub-tag must result in a fatal failure. </font></li>
<li><font face="Gill Sans MT">Tag 0x7f is reserved.</font></li>
</ol>
<p>TLV tags are followed by a variable length "Length" field which
is then followed by the specified number of octets. The variable
length "Length" is parsed as follows:<br>
</p>
<ol>
<li>If the first octet is less than or equal to 0x7f, then the
Value that follows is that number of octets.</li>
<li>If the first octet is 0x80, then the Value that follows is of
indefinite length. The value data that follows must be
self-describing with regards to length. In other words, a
parser that understands the data format must be able to identify
the end of the value from the contents of the data. If an
indefinite length tag or sub-tag is unrecognized, it is a fatal
error regardless of whether or not the CRITICAL tag preceded it.</li>
<li>If the first octet 'L' is between 0x81 and 0x88, the length is
value of the next (L & 0x0f) octets combined in most
significant byte (MSB) order. 0x81 indicates one byte, 0x82 two
bytes, 0x88 eight bytes.</li>
<li>If the first octet is greater than 0x88, it is an invalid
length which is a fatal error.<br>
</li>
</ol>
<p><font face="Gill Sans MT">The OpenAFS implementation has the
following deficiencies:</font></p>
<ol>
<li><font face="Gill Sans MT">It does not handle parsing of
unrecognized D Tags.</font></li>
<li><font face="Gill Sans MT">The MIN_TLV_TAG sub-tag must be 0x16
not 0x5.</font></li>
<li><font face="Gill Sans MT">Tag values up to and including D_MAX
(20) must not be used as sub-tags.</font></li>
<li><font face="Gill Sans MT">The Legacy tag table is incomplete.</font></li>
</ol>
<p><font face="Gill Sans MT"><br>
</font></p>
<p><font face="Gill Sans MT">Initial Registry Contents:</font></p>
<p><font face="Gill Sans MT">I propose that all of the following
tags and sub-tags be added to the registry. Sub-tags
designated as deprecated are known to have been stored in
backups and therefore might be present in a restored dump stream
at some point in the future. Deprecated sub-tags should be
avoided but might be reallocated if all other sub-tags are in
use.<br>
</font></p>
<font face="Gill Sans MT">I propose that new tags be allocated on a
first come, first served basis with a documentation requirement.
Documentation must be provided that is sufficient to permit a dump
stream to be restored if non-critical unrecognized tags are
included in the stream. A stream containing unrecognized critical
tags will fail to restore but sufficient documentation must be
present for a site to evaluate the risk associated with the
criticality.<br>
</font>
<p><font face="Gill Sans MT">When designing new tags for
registration developers should consider use by the entire
ecosystem. For example, in addressing the Year 2038 problem new
tags to transmit 64-bit 100ns timestamps for vnodes and volumes
should be reusable by many implementations. The same should be
true for 64-bit data versions, 96-bit vnode ids, 64-bit volume
ids, 64-bit user ids, longer volume names, 64-bit volume quotas,
and 64-bit volume space usage. The Dump Header will require new
tags for 64-bit 100ns timestamps, 64-bit volume ids, and longer
volume names, <br>
</font></p>
<p>D Header Tags:</p>
<pre> 0x01 D_DUMPHEADER IBM Legacy
0x02 D_VOLUMEHEADER IBM Legacy
0x03 D_VNODE IBM Legacy
0x04 D_DUMPEND IBM Legacy</pre>
<p>D_DUMPHEADER Sub-Tags<br>
</p>
<pre> 21 0x15 64-bit Volume ID AuriStor TLV
22 0x16 100ns Dump Times AuriStor TLV
'n' 0x6e Volume Name IBM Legacy: C-String
't' 0x74 32-bit Dump Times IBM Legacy
'v' 0x76 32-bit Volume ID IBM Legacy
</pre>
<p>D_VOLUMEHEADER Sub-Tags</p>
<pre> 21 0x15 64-bit Volume IDs AuriStor TLV
22 0x16 Volume Maximum ACL AuriStor TLV
23 0x17 Volume Sec Levels AuriStor TLV
24 0x18 64-bit Max Quota AuriStor TLV
25 0x19 64-bit Disk Usage AuriStor TLV
26 0x1a 100ns Timestamps AuriStor TLV
27 0x1b 64-bit Features AuriStor TLV
28 0x1c 64-bit Owner AuriStor TLV
29 0x1d 64-bit Min Quota AuriStor TLV
30 0x1e 64-bit File Count AuriStor TLV
'A' 0x41 32-bit Last Access Date OSD Legacy
'B' 0x42 32-bit Backup Date IBM Legacy
'C' 0x43 32-bit Creation Date IBM Legacy
'D' 0x44 32-bit Day Use Date IBM Legacy
'E' 0x45 32-bit Expiration Date IBM Legacy
'F' 0x46 OSD Policy OSD Legacy: 32-bit [deprecated - replaced by 'P']
'M' 0x4d MOTD IBM Legacy: C-String
'O' 0x4f Offline Message IBM Legacy: C-String
'P' 0x50 OSD Policy OSD Legacy: 32-bit [deprecated - replaced by 'y']
'U' 0x55 32-bit Update Date IBM Legacy
'V' 0x56 32-bit Update Counter OpenAFS Legacy
'W' 0x57 Week Use Statistics IBM Legacy: structure
'Z' 0x5a Day Use Statistics IBM Legacy
'a' 0x61 Account Number IBM Standard [deprecated]
'b' 0x62 Blessed Flag IBM Legacy: 8-bit
'c' 0x63 32-bit Clone Id IBM Standard
'd' 0x64 32-bit Disk Usage IBM Standard
'f' 0x66 32-bit File Count IBM Standard
'i' 0x69 32-bit Volume Id IBM Standard
'm' 0x6d 32-bit Volume Min Quota IBM Standard
'n' 0x6e Volume Name IBM Legacy: C-String
'o' 0x6f 32-bit Volume Owner IBM Standard
'p' 0x70 32-bit Parent Volume Id IBM Standard
'q' 0x71 32-bit Volume Max Quota IBM Standard
'r' 0x72 OSD Max number of files OSD Standard
's' 0x73 In-Service Flag IBM Legacy: 8-bit
't' 0x74 Volume Type IBM Legacy: 8-bit
'u' 0x75 32-bit Next Uniquifier IBM Standard
'v' 0x76 32-bit Stamp Version IBM Standard [deprecated]
'y' 0x79 OSD Policy OSD Standard
</pre>
<p>D_VNODE Sub-Tags</p>
<pre> 21 0x15 File ACL AuriStor TLV [deprecated]
22 0x16 100ns Timestamps AuriStor TLV
23 0x17 64-bit A, O, G IDs AuriStor TLV
24 0x18 96-bit Vnode# Parent# AuriStor TLV
25 0x19 64-bit Data Version AuriStor TLV
26 0x1a 64-bit Ext ACL AuriStor TLV
'A' 0x41 32-bit ACL IBM Legacy: C-String
'L' 0x4c OSD vnode length (hi,lo) OSD TLV
'O' 0x4f OSD metadata string OSD TLV
'P' 0x50 OSD dir policy index OSD Legacy: 32-bit [deprecated - replaced by 'd']
'a' 0x61 32-bit Author ID IBM Standard
'b' 0x62 Unix Mode Bits IBM Legacy: 16-bit
'd' 0x64 OSD dir policy index OSD Standard
'f' 0x66 File Stream - Small IBM Legacy: structured
'g' 0x67 32-bit Group ID IBM Standard
'h' 0x68 File Stream - Large OpenAFS Legacy: structured
'l' 0x6c Link Count IBM Legacy: 16-bit
'm' 0x6d 32-bit UNIX Modify Time IBM Standard
'o' 0x6f 32-bit Owner ID IBM Standard
'p' 0x70 32-bit Parent Vnode # IBM Standard
's' 0x73 32-bit Server Modify Time IBM Standard
't' 0x74 Vnode Type IBM Legacy: 8-bit
'u' 0x75 32-bit Last Access Time OSD Standard [deprecated]
'v' 0x76 32-bit Data Version IBM Standard
'x' 0x78 OSD File Online Flag OSD Standard
'y' 0x79 OSD vnode length OSD Legacy: structure [deprecated - replaced by 'L']
'z' 0x7a OSD metadata string OSD Legacy: C-String [deprecated - replaced by 'O']
</pre>
<p>Guidance for Use of New Tags</p>
<ol>
<li>If a new sub-tag is allocated to support a larger value, for
example D_VOLUMEHEADER 0x15 "64-bit IDs" which can replace 0x69
"32-bit Volume Id", 0x70 "32-bit Parent Id", and 0x63 "Clone
Id", then the new tag should only be generated if the data
values cannot be represented by the older tag. If the new tag
is used, it should be preceded by the CRITICAL tag.</li>
<li>If a new sub-tag is allocated to augment existing data, then
both sub-tags should be generated. For example, the
D_VOLUMEHEADER 0x16 "100ns timestamps" provides 100ns
granularity for accessDate, updateDate, creationDate, backupDate
and expirationDate. This sub-tag should be generated in
addition to the 32-bit second granularity equivalents. The new
sub-tag should not be preceded by the CRITICAL tag. This
permits the dump stream to be restored both to systems that
understand 100ns timestamps and those that do not.</li>
</ol>
<p>Please note that I did not include the RT 17947 Compression D
Tags: D_COMPRESS_TAG (0x5) and D_FLAGS_TAG (0x6) in the list of
registered tags. There are two reasons for this. First, to the
best of my knowledge the Compression Proposal was never put into
production. Second, I believe the allocation of D_COMPRESS_TAG
and D_FLAGS_TAG out of the Dump Header namespace was a mistake.
If anyone revisits the Compression proposal I believe that the
details of the compression should be sent either via D_DUMPHEADER
sub-tags or D_VOLUMEHEADER sub-tags; and a new D_VNODE sub-tag
should be used to store the Compressed File Stream. The choice of
D_DUMPHEADER vs D_VOLUMEHEADER depends on whether or not all of
the components of a "merged dump" stream must share the same
compression options. If yes, then D_DUMPHEADER is the preferred
location. If not, then D_VOLUMEHEADER should be used.</p>
<p>For those that are not familiar with a "merged dump", incremental
dump streams can be merged into a full dump stream by:</p>
<ol>
<li>merging the D_DUMPHEADER "from".."to" time range into the
D_DUMPHEADER at the start of the stream</li>
<li>remove the D_DUMPEND header from the end of the first stream</li>
<li>remove the D_DUMPHEADER from the stream to be appended</li>
<li>concatenate the two streams producing a stream with multiple
D_VOLUMEHEADER blocks each of which are followed by one or more
D_VNODE blocks.</li>
</ol>
<p>A merged stream can be used to restore a volume in a single RPC.<br>
</p>
<p>If anyone is familiar with other Tags and Sub-tags that are in
use, please let me know.</p>
<p>I will provide additional details of the AuriStor sub-tags to the
Registrar once a Registry has been published.</p>
<p>Sincerely,</p>
<p>Jeffrey Altman</p>
<p><br>
</p>
</body>
</html>
--------------74Zi0JE9HnrPq0zpCxyga8gk--
--------------ms070405000404050506010705
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DHEwggXSMIIEuqADAgECAhBAAYJpmi/rPn/F0fJyDlzMMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEz
MB4XDTIyMDgwNDE2MDQ0OFoXDTI1MTAzMTE2MDM0OFowcDEvMC0GCgmSJomT8ixkAQETH0Ew
MTQxMEQwMDAwMDE4MjY5OUEyRkQyMDAwMjMzQ0QxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRt
YW4xFTATBgNVBAoTDEF1cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQCkC7PKBBZnQqDKPtZPMLAy77zo2DPvwtGnd1hNjPvbXrpGxUb3
xHZRtv179LHKAOcsY2jIctzieMxf82OMyhpBziMPsFAG/ukihBMFj3/xEeZVso3K27pSAyyN
fO/wJ0rX7G+ges22Dd7goZul8rPaTJBIxbZDuaykJMGpNq4PQ8VPcnYZx+6b+nJwJJoJ46kI
EEfNh3UKvB/vM0qtxS690iAdgmQIhTl+qfXq4IxWB6b+3NeQxgR6KLU4P7v88/tvJTpxIKkg
9xj89ruzeThyRFd2DSe3vfdnq9+g4qJSHRXyTft6W3Lkp7UWTM4kMqOcc4VSRdufVKBQNXjG
IcnhAgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAwgYQGCCsGAQUFBwEBBHgwdjAwBggr
BgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUF
BzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWEx
My5wN2MwHwYDVR0jBBgwFoAULbfeG1l+KpguzeHUG+PFEBJe6RQwCQYDVR0TBAIwADCCASsG
A1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIBFj5odHRwczov
L3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRt
bDCBugYIKwYBBQUHAgIwga0MgapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4g
aXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj
YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRp
ZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8v
dmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTMuY3JsMB8GA1UdEQQY
MBaBFGphbHRtYW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQB+nzqgljLocLTsiUn2yWqEc2s
gjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJwV
eycprp8Ox1npiTyfwc5QaVaqtoe8Dcg2JXZc0h4DmYGW2rRLHp8YL43snEV93rPJVk6B2v4c
WLeQfaMrnyNeEuvHx/2CT44cdLtaEk5zyqo3GYJYlLcRVz6EcSGHv1qPXgDT0xB/25etwGYq
utYF4Chkxu4KzIpq90eDMw5ajkexw+8ARQz4N5+d6NRbmMCovd7wTGi8th/BZvz8hgKUiUJo
Qle4wDxrdXdnIhCP7g87InXKefWgZBF4VX21t2+hkc04qrhIJlHrocPG9mRSnnk2WpsY0MXt
a8ivbVKtfpY7uSNDZSKTDi1izEFH5oeQdYRkgIGb319a7FjslV8wggaXMIIEf6ADAgECAhBA
AXA7OrqBjMk8rp4OuNQSMA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlJZGVuVHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAe
Fw0yMDAyMTIyMTA3NDlaFw0zMDAyMTIyMTA3NDlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQK
EwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEzMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAu6sUO01SDD99PM+QdZkNxKxJNt0NgQE+Zt6ixaNP0JKSjTd+SG5L
wqxBWjnOgI/3dlwgtSNeN77AgSs+rA4bK4GJ75cUZZANUXRKw/et8pf9Qn6iqgB63OdHxBN/
15KbM3HR+PyiHXQoUVIevCKW8nnlWnnZabT1FejOhRRKVUg5HACGOTfnCOONrlxlg+m1Vjgn
o1uNqNuLM/jkD1z6phNZ/G9IfZGI0ppHX5AA/bViWceX248VmefNhSR14ADZJtlAAWOi2un0
3bqrBPHA9nDyXxI8rgWLfUP5rDy8jx2hEItg95+ORF5wfkGUq787HBjspE86CcaduLka/Bk2
VwIDAQABo4IChzCCAoMwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwgYkG
CCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu
dHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t
L3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTtRBnA0/AGi+6ke75C
5yZUyI42djCCASQGA1UdIASCARswggEXMIIBEwYEVR0gADCCAQkwSgYIKwYBBQUHAgEWPmh0
dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRl
eC5odG1sMIG6BggrBgEFBQcCAjCBrQyBqlRoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMg
YmVlbiBpc3N1ZWQgaW4gYWNjb3JkYW5jZSB3aXRoIElkZW5UcnVzdCdzIFRydXN0SUQgQ2Vy
dGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHBzOi8vc2VjdXJlLmlkZW50cnVzdC5jb20v
Y2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMEoGA1UdHwRDMEEwP6A9oDuGOWh0
dHA6Ly92YWxpZGF0aW9uLmlkZW50cnVzdC5jb20vY3JsL2NvbW1lcmNpYWxyb290Y2ExLmNy
bDAdBgNVHQ4EFgQULbfeG1l+KpguzeHUG+PFEBJe6RQwHQYDVR0lBBYwFAYIKwYBBQUHAwIG
CCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4ICAQB/7BKcygLX6Nl4a03cDHt7TLdPxCzFvDF2
bkVYCFTRX47UfeomF1gBPFDee3H/IPlLRmuTPoNt0qjdpfQzmDWN95jUXLdLPRToNxyaoB5s
0hOhcV6H08u3FHACBif55i0DTDzVSaBv0AZ9h1XeuGx4Fih1Vm3Xxz24GBqqVudvPRLyMJ7u
6hvBqTIKJ53uCs3dyQLZT9DXnp+kJv8y7ZSAY+QVrI/dysT8avtn8d7k7azNBkfnbRq+0e88
QoBnel6u+fpwbd5NLRHywXeH+phbzULCa+bLPRMqJaW2lbhvSWrMHRDy3/d8HvgnLCBFK2s4
Spns4YCN4xVcbqlGWzgolHCKUH39vpcsDo1ymZFrJ8QR6ihIn8FmJ5oKwAnnd/G6ADXFC9bu
db9+532phSAXOZrrecIQn+vtP366PC+aClAPsIIDJDsotS5z4X2JUFsNIuEgXGqhiKE7SuZb
rFG9sdcLprSlJN7TsRDc0W2b9nqwD+rj/5MN0C+eKwha+8ydv0+qzTyxPP90KRgaegGowC4d
UsZyTk2n4Z3MuAHX5nAZL/Vh/SyDj/ajorV44yqZBzQ3ChKhXbfUSwe2xMmygA2Z5DRwMRJn
p/BscizYdNk2WXJMTnH+wVLN8sLEwEtQR4eTLoFmQvrK2AMBS9kW5sBkMzINt/ZbbcZ3F+eA
MDGCAxQwggMQAgEBME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUG
A1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwDQYJYIZIAWUDBAIBBQCg
ggGXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMTAxMzAz
NDAwOVowLwYJKoZIhvcNAQkEMSIEICtDQLREhJ5Giq3JqbXIe1rmdw15zECLynikayw9Nnzy
MF0GCSsGAQQBgjcQBDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEX
MBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTMCEEABgmmaL+s+f8XR8nIOXMwwXwYLKoZIhvcNAQkQ
AgsxUKBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRy
dXN0SUQgQ0EgQTEzAhBAAYJpmi/rPn/F0fJyDlzMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI
AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI
hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAecrr
yh1sBjoO9JLqasqEm0AXx6XiIjpKt1y02SLhv+LJROYaU5522RsdIAmssSmg9TMTcYfc+Ek6
Z0pbjzgrF1CJIYorza5jSAd1wYWh+ODcHma4LKblOj6xkbH7m1cU25IJ+iuIVdPh5YkzV5rV
3UmsXYrklUSApmN9h9qyJVnuABI6Pr7UH1egFcVvprqHKvoYxcePp4NKYfdcgTACAxb94PJi
6W/paW1gU5FF4tTNK7VxxUi1oDbzeDJs1nHkrOz9s1jCxKDehMJMZ1Rz/MmXADsUJNRWpG7w
xFoJtake9VjVwLT+jWroRRikkh4fmKohO4zo6a3oG7hT7YoaBQAAAAAAAA==
--------------ms070405000404050506010705--