ISO/IEC 20919:2016
(Main)Information technology - Linear Tape File System (LTFS) Format Specification
Information technology - Linear Tape File System (LTFS) Format Specification
ISO/IEC 20919:2016 defines the LTFS Format requirements for interchanged media that claims LTFS compliance. Those requirements are specified as the size and sequence of data blocks and file marks on the media, the content and form of special data constructs (the LTFS Label and LTFS Index), and the content of the partition labels and use of MAM parameters. The data content (not the physical media) of the LTFS format shall be interchangeable among all data storage systems claiming conformance to this format. Physical media interchange is dependent on compatibility of physical media and the media access devices in use. ISO/IEC 20919:2016 does not contain instructions or tape command sequences to build the LTFS structure.
Technologies de l'information — Spécification du format de système de fichier à bande magnétique
General Information
Relations
Frequently Asked Questions
ISO/IEC 20919:2016 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - Linear Tape File System (LTFS) Format Specification". This standard covers: ISO/IEC 20919:2016 defines the LTFS Format requirements for interchanged media that claims LTFS compliance. Those requirements are specified as the size and sequence of data blocks and file marks on the media, the content and form of special data constructs (the LTFS Label and LTFS Index), and the content of the partition labels and use of MAM parameters. The data content (not the physical media) of the LTFS format shall be interchangeable among all data storage systems claiming conformance to this format. Physical media interchange is dependent on compatibility of physical media and the media access devices in use. ISO/IEC 20919:2016 does not contain instructions or tape command sequences to build the LTFS structure.
ISO/IEC 20919:2016 defines the LTFS Format requirements for interchanged media that claims LTFS compliance. Those requirements are specified as the size and sequence of data blocks and file marks on the media, the content and form of special data constructs (the LTFS Label and LTFS Index), and the content of the partition labels and use of MAM parameters. The data content (not the physical media) of the LTFS format shall be interchangeable among all data storage systems claiming conformance to this format. Physical media interchange is dependent on compatibility of physical media and the media access devices in use. ISO/IEC 20919:2016 does not contain instructions or tape command sequences to build the LTFS structure.
ISO/IEC 20919:2016 is classified under the following ICS (International Classification for Standards) categories: 35.220.20 - Magnetic storage devices in general. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/IEC 20919:2016 has the following relationships with other standards: It is inter standard links to ISO/IEC 20919:2021. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO/IEC 20919:2016 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 20919
First edition
2016-04-01
Information technology — Linear
Tape File System (LTFS) Format
Specification
Technologies de l’information — Spécification du format de système
de fichier à bande magnétique
Reference number
©
ISO/IEC 2016
© ISO/IEC 2016, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2016 – All rights reserved
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non‐governmental, in liaison with ISO and IEC, also
take part in the work. In the field of information technology, ISO and IEC have established a joint
technical committee, ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does
not constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO's adherence to the World Trade Organization (WTO)
principles in the Technical Barriers to Trade (TBT) see the following
URL: www.iso.org/iso/foreword.html.
technical committee ISO/IEC JTC 1, Information technology, in parallel with its approval by national
bodies of ISO and IEC.
© ISO/IEC 2016 – All rights reserved iii
Linear Tape File System (LTFS) Format
Specification
Version 2.2.0
This document has been released and approved by the SNIA. The SNIA believes that
the ideas, methodologies and technologies described in this document accurately
represent the SNIA goals and are appropriate for widespread distribution. Suggestions
for revision should be directed to http://www.snia.org/feedback/
SNIA Technical Position
December 21, 2013
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
Revision History
Revision Date Sections Originator: Comments
2.1.0 May 18, 2012 Entire Document David Pease LaTeX version contributed by IBM
2.2.0 rev a January 15, 2013 Entire document Arnold Jones Converted to Microsoft Word
2.2.0 rev b March 15, 2013 Entire document Carl Madison Edits/Additions per TWG
2.2.0 rev c April 4, 2013 Entire document Carl Madison Edits/Additions per TWG F2F
2.2.0 rev d May 7, 2013 Entire document Carl Madison Diagram Replacement/edits
2.2.0 rev e May 28, 2013 Entire document Carl Madison F2F edits, misc edits
2.2.0 rev f July 16, 2013 Entire document Carl Madison Edits per TWG
2.2.0 rev g July 23, 2013 Entire document Carl Madison Edits per TWG F2F
2.2.0 rev h July 29, 2013 Entire document Carl Madison Edits per TWG
2.2.0 rev i July 30, 2013 Entire document Carl Madison Edits per TWG 7/30/13 mtg
2.2.0 rev j August 13, 2013 Entire document Carl Madison Edits per TWG 8/13/13 mtg
2.2.0 rev k August 27, 2013 Entire Document Carl Madison Edits per TWG 8/27/13 mtg.
2.2.0 SNIA December 21, 2013* Entire Document Carl Madison *2.2.0 rev k formatted as a SNIA
Technical Technical Position after SNIA
Position membership approval.
March 14, 2013**
**Additional editorial revisions
Suggestion for changes or modifications to this document should be sent to the SNIA Linear Tape File
System Technical Work Group at http://www.snia.org/feedback/.
Changes between v1.0 and v2.0.0
• Incremented version number to 2.0.0 and updated date to March 11, 2011.
• Improvements in specification text to remove ambiguity and clarify intention of the specification.
These changes were made at several locations throughout the document.
• Improvements to clarify description of MAM parameters in Section 9 Medium Auxiliary Memory.
• Removed reference to a specific version of the Unicode standard in Section 6.5 Name pattern format.
This removes any requirement to use specific versions of Unicode support code in an
implementation.
• Improved description of Name pattern format to remove ambiguity in Section 6.5 Name pattern
format.
• Added description of LTFS Format specification version numbering in Section 2.1 Versions.
• Updated XML Schema for Label and Index to match version number format in Annex A and
Annex B.
• Added specification of minimum and recommended blocksize value for LTFS Volumes to Section
7.1.2 LTFS Label.
• Added definition of allowed version numbers to Section 7.1.2 LTFS Label and Section 8.2 Index.
• Added definition of fileoffset tag in Section 8.2 Index.
• Extended description in Section 5 Data Extents to support addition of fileoffset tag and associated
functionality.
• Added definition of highestfileuid tag in Section 8.2 Index.
• Added definition of fileuid tag in Section 8.2 Index.
2 SNIA Technical Position LTFS Format Specification V2.2.0
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
• Added definition of backuptime tag in Section 8.2 Index.
• Incremented version number in Application Client Specific Information (ACSI) structure shown in 9.3
Use of Volume Coherency Information for LTFS. This increment allows identification of LTFS
Volumes written with a LTFS v1.0 compliant implementation. A widely used v1.0 implementation
wrote ambiguous ACSI values due to an implementation bug.
• Added definition of extended attributes in the ltfs.* namespace in Annex C.
• Added description for handling unknown XML tags in Index to Section 8.2.10 Managing LTFS
Indexes.
Changes between v2.0.0 and v2.0.1
• Incremented specification version number to 2.0.1.
• Updated specification date to August 17, 2011.
• Expanded historical record of changes between revisions of LTFS Format Specification.
• Improved description of constraints for two Indexes having the same generation number in Section
4.4.1 Generation Number to make it clear that differences in access time values is permitted between
Indexes that are otherwise except for self pointer and index pointer values.
• Added note in Section 4.4.1 Generation Number to explicitly state that Index generation numbers may
increase by integer values other than 1.
• Expanded description of the ltfs.sync extended attribute in Annex C . The expanded description
explicitly states that this extended attribute triggers a sync of the in-memory data to the storage
media. That is, the operation is analogous to a POSIX sync operation.
Changes between v2.0.1 and v2.1.0
• Incremented specification version number to 2.1.0.
• Updated specification date to October 18, 2012.
• Added definition of symlink tag in Section 8.2 Index.
• Added example of symlink tag use in Annex E (informative) Complete Example LTFS Index.
• Added symlink tag to Annex B.
• Added description of “ltfs.vendor.X.Y” extended attribute namespace in Annex C .
• Added description of software metadata section in Annex C.
• Added description of drive metadata section in Annex C.
• Added ”ltfs.labelVersion” extended attribute in Annex C.
• Added ”ltfs.indexVersion” extended attribute in Annex C
• Added ”ltfs.mediaEncrypted” extended attribute in Annex C .
• Improved description of ”ltfs.mediaStorageAlert” extended attribute in Annex C.
Changes between v2.1.0 and v2.2.0
• Incremented specification version number to 2.2.0.
• Updated specification date to July 16, 2013.
• Changed “2010” to “2013” in XML examples.
• Editorial Cleanup.
LTFS Format Specification V2.2.0 SNIA Technical Position 3
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
• Changed “extentinfo” definition in Section 8.2 Index.
• Changed “symlink” definition in Section 8.2 Index.
• Added additional paragraph to “symlink” definition in Section 8.2 Index.
• Added general comments at start of Section 9 Medium Auxiliary Memory.
• Added Section 9.4 Use of Host-type Attributes for LTFS.
• Removed Section 9 Certification from document.
• Added “ltfs.mamBarcode” extended attribute in Annex C.4 Volume Metadata.
• Added “ltfs.mamApplicationVendor” extended attribute in Annex C.4 Volume Metadata.
• Added “ltfs.mamApplicationVersion” extended attribute in Annex C.4 Volume Metadata.
• Added “ltfs.mamApplicationFormatVersion” extended attribute in Annex C.4 Volume Metadata.
• Added new Annex F Interoperability Recommendation and added File Spanning and File Permissions
subsections
Usage
The SNIA hereby grants permission for individuals to use this document for personal use only, and for
corporations and other business entities to use this document for internal use only (including internal
copying, distribution, and display) provided that:
1. Any text, diagram, chart, table or definition reproduced must be reproduced in its
entirety with no alteration, and,
2. Any document, printed or electronic, in which material from this document (or any
portion hereof) is reproduced must acknowledge the SNIA copyright on that material,
and must credit the SNIA for granting permission for its reuse.
Other than as explicitly provided above, you may not make any commercial use of this document, sell any
or this entire document, or distribute this document to third parties. All rights not explicitly granted are
expressly reserved to SNIA.
Permission to use this document for purposes other than those enumerated above may be requested by
emailing tcmd@snia.org. Please include the identity of the requesting individual and/or company and a
brief description of the purpose, nature, and scope of the requested use.
Contacting SNIA
SNIA Web Site
Current SNIA practice is to make updates and other information available through their web site at
http://www.snia.org.
SNIA Address
Requests for interpretation, suggestions for improvement and addenda, or defect reports are welcome.
They should be sent via the SNIA Feedback Portal at http://www.snia.org/feedback/ or by mail to the
Storage Networking Industry Association, 4360 ArrowsWest Drive, Colorado Springs, Colorado 80907,
U.S.A.
4 SNIA Technical Position LTFS Format Specification V2.2.0
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
Disclaimer
The information contained in this publication is subject to change without notice. The SNIA makes no
warranty of any kind with regard to this specification, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. The SNIA shall not be liable for errors contained
herein or for incidental or consequential damages in connection with the furnishing, performance, or use
of this specification.
Suggestions for revisions should be directed to http://www.snia.org/feedback/.
Acknowledgements
The SNIA LTFS Technical Working Group, which developed and reviewed this specification, would like to
recognize the significant contributions made by the following members:
EMC Corporation. . Don Deel
Hewlett-Packard . . Chris Martin
IBM. . David Pease
.................................................. ................ Ed Childers
NetApp. . David Slik
Oracle Corporation. . Matthew Gaffney
................................................. ................. Carl Madison
Quantum Corporation. . Paul Stone
SNIA. . Arnold Jones
LTFS Format Specification V2.2.0 SNIA Technical Position 5
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
Contents
1 Introduction . 10
2 Scope . 11
2.1 Versions . 11
2.2 Conformance . 12
3 Definitions and Acronyms . 13
3.1 Definitions . 13
3.2 Acronyms . 15
4 Volume Layout . 16
4.1 LTFS Partitions . 16
4.2 LTFS Constructs . 16
4.3 Partition Layout . 17
4.4 Index Layout . 18
5 Data Extents . 20
5.1 Extent Lists . 20
5.2 Extents Illustrated . 20
5.3 Files Illustrated . 22
6 Data Formats . 26
6.1 Boolean format . 26
6.2 Creator format . 26
6.3 Extended attribute value format . 26
6.4 Name format . 27
6.5 Name pattern format . 27
6.6 String format . 27
6.7 Time stamp format . 28
6.8 UUID format . 28
7 Label Format . 29
7.1 Label Construct . 29
6 SNIA Technical Position LTFS Format Specification V2.2.0
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
8 Index Format . 32
8.1 Index Construct . 32
8.2 Index . 32
9 Medium Auxiliary Memory . 43
9.1 Volume Change Reference . 43
9.2 Volume Coherency Information . 44
9.3 Use of Volume Coherency Information for LTFS . 44
9.4 Use of Host-type Attributes for LTFS . 46
Annex A (normative) LTFS Label XML Schema . 48
Annex B (normative) LTFS Index XML Schema . 50
Annex C (normative) Reserved Extended Attribute definitions . 53
C.1 Software Metadata . 53
C.2 Drive Metadata . 53
C.3 Object Metadata . 53
C.4 Volume Metadata . 54
C.5 Media Metadata. 55
Annex D (informative) Example of Valid Simple Complete LTFS Volume . 58
Annex E (informative) Complete Example LTFS Index . 59
Annex F (normative) Interoperability Recommendations . 63
F.1 Spanning Files across Multiple Tape Volumes in LTFS . 63
F.2 File Permissions in LTFS . 66
LTFS Format Specification V2.2.0 SNIA Technical Position 7
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
List of Figures
Figure 1 — LTFS Partition .16
Figure 2 — Label Construct .16
Figure 3 — Index Construct .17
Figure 4 — Partition Layout .17
Figure 5 — Complete partition containing data .18
Figure 6 — Back Pointer example .19
Figure 7 — Extent starting and ending with full block .21
Figure 8 — Extent starting with full block and ending with fractional block .21
Figure 9 — Extent starting and ending in mid-block .21
Figure 11 — File contained in two Data Extents .22
Figure 10 — File contained in a single Data Extent .22
Figure 12 — Shared Blocks example .23
Figure 13 — Sparse files example .24
Figure 14 — Shared data example .24
Figure 15 — Label construct .29
Figure 16 — Index Construct .32
Figure D. 1 — Content of a simple LTFS volume .58
8 SNIA Technical Position LTFS Format Specification V2.2.0
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
List of Tables
Table 1 — Version elements .11
Table 2 — Version comparisons .12
Table 3 — Extent list entry starting and ending with full block .21
Table 4 — Extent list entry starting with full block and ending with fractional block .21
Table 5 — Extent list entry starting and ending in mid-block .22
Table 6 — Extent list entry for file contained in a single Data Extent .22
Table 7 — Extent list entry for a file contained in two Data Extents .22
Table 8 — Extent lists for Shared Blocks example .23
Table 9 — Extent list for sparse files example .24
Table 10 — Extent lists for shared data example .25
Table 11 — Creator format definitions .26
Table 12 — Prohibited characters for name format .27
Table 13 — Characters which should be avoided for name format .27
Table 14 — Time stamp format .28
Table 15 — VOL1 Label Construct .29
Table 16 — Volume Coherency Information .44
Table 17 — ACSI format for LTFS .45
Table 18 — Relevant Host-type Attributes for LTFS .46
Table 19 — Example of Host-type Attributes .47
Table C. 1 — Reserved extended attribute definitions: Software metadata .53
Table C. 2 — Reserved extended attribute definitions: Drive metadata .53
Table C. 3 — Reserved extended attribute definitions: Object metadata .54
Table C. 4 — Reserved extended attribute definitions: Volume metadata .54
Table C. 5 — Reserved extended attribute definitions: Media metadata .55
LTFS Format Specification V2.2.0 SNIA Technical Position 9
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
1 Introduction
This document defines a Linear Tape File System (LTFS) Format separate from any
implementation on data storage media. Using this format, data is stored in LTFS Volumes. An
LTFS Volume holds data files and corresponding metadata to completely describe the directory
and file structures stored on the volume.
The LTFS Format has these features:
• An LTFS Volume can be mounted and volume content accessed with full use of the data
without the need to access other information sources.
• Data can be passed between sites and applications using only the information written to an
LTFS Volume.
• Files can be written to, and read from, an LTFS Volume using standard POSIX file
operations.
The LTFS Format is particularly suited to these usages:
• Data export and import.
• Data interchange and exchange.
• Direct file and partial file recall from sequential access media.
• Archival storage of files using a simplified, self-contained or “self-describing” format on
sequential access media.
10 SNIA Technical Position LTFS Format Specification V2.2.0
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
2 Scope
This document defines the LTFS Format requirements for interchanged media that claims LTFS
compliance. Those requirements are specified as the size and sequence of data blocks and file marks on
the media, the content and form of special data constructs (the LTFS Label and LTFS Index), and the
content of the partition labels and use of MAM parameters.
The data content (not the physical media) of the LTFS format shall be interchangeable among all data
storage systems claiming conformance to this format. Physical media interchange is dependent on
compatibility of physical media and the media access devices in use.
NOTE: This document does not contain instructions or tape command sequences to build the LTFS structure.
2.1 Versions
This document describes version 2.2.0 of the Linear Tape File System (LTFS) Format Specification.
The version number for the LTFS Format Specification consists of three integer elements separated by
period characters of the form M.N.R, where M , N , and R are positive integers or zero. Differences in the
version number between different revisions of this specification indicate the nature of the changes made
between the two revisions. Each of the integers in the format specification are incremented according to
Table 1.
Table 1 — Version elements
Element Description
M
Incremented when a major update has been made to the LTFS Format
Specification. Major updates are defined as any change to the on-media format or
specification semantics that are expected to break compatibility with older
versions of the specification.
N Incremented when a minor update has been made to the LTFS Format
Specification. Minor updates are defined as any change to the on-media format or
specification semantics that is not expected to break compatibility with older
versions of the specification that have the same value for M in the version
number.
R
Incremented when textual revisions are made to the LTFS Format Specification.
Textual revisions are defined as revisions that improve the clarity of the
specification document without changing the intent of the document. By definition,
minor changes do not alter the on-media format or specification semantics.
NOTE 1: When any element of the specification version number is incremented, all sub-ordinate elements to the right are reset to
zero. For example, if the version is 1.0.12 and N is incremented to 1, then R is set to zero resulting in version 1.1.0.
NOTE 2: The first public version of this document used version number 1.0. This value should be interpreted as equivalent to 1.0.0
in the version numbering defined in this document.
LTFS Format Specification V2.2.0 SNIA Technical Position 11
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
The result of comparison between two LTFS version numbers M .N .R and M .N .R is defined in
A A A B B B
Table 2.
Table 2 — Version comparisons
Conditional Description
M < M M .N .R is an earlier version than M .N .R .
A B A A A B B B
M = M and M .N .R is an earlier version than M .N .R .
A B A A A B B B
M < N
A B
M = M M .N .R is an earlier version than M .N .R . However, as defined
A B and A A A B B B
N = N above, changes that result only in a different R value are descriptive
A B and
changes in the specification rather than on media changes.
R < R
A B
2.2 Conformance
Recorded media claiming conformance to this format shall be in a consistent state when interchanged or
stored. See Section 3.1.4.
Any implementation conforming to this specification should be able to correctly read Label and Index
structures from all prior versions of this specification and write Label and Index structures conforming to
the descriptions in this document. The current Label and Index structures are defined in Section 7 Label
Format and in Section 8 Index Format.
NOTE: Where practical, any implementation supporting a given version value for M should endeavor to support LTFS volumes with
version numbers containing higher values for N and R than those defined at the time of implementation.
12 SNIA Technical Position LTFS Format Specification V2.2.0
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
3 Definitions and Acronyms
For the purposes of this document the following definitions and acronyms shall apply.
3.1 Definitions
3.1.1
Block Position
The position or location of a recorded block as specified by its LTFS Partition ID and logical block number
within that partition.
The block position of an Index is the position of the first logical block for the Index.
3.1.2
Complete Partition
An LTFS partition that consists of an LTFS Label Construct and a Content Area, where the last construct
in the Content Area is an Index Construct.
3.1.3
Content Area
A contiguous area in a partition, used to record Index Constructs and Data Extents.
3.1.4
Consistent State
A volume is consistent when both partitions are complete and the last Index Construct in the Index
Partition has a back pointer to the last Index Construct in the Data Partition.
3.1.5
Data Extent
A contiguous sequence of recorded blocks.
3.1.6
Data Partition
An LTFS partition primarily used for data files.
3.1.7
File
A group of logically related extents together with associated file metadata.
3.1.8
filesystem sync
An operation during which all cached file data and metadata is flushed to the media.
3.1.9
generation number
A positive decimal integer which shall indicate the specific generation of an Index within an LTFS volume.
LTFS Format Specification V2.2.0 SNIA Technical Position 13
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
3.1.10
Index
A data structure that describes all valid data files in an LTFS volume. The Index is an XML document
conforming to the XML schema shown in Annex B (normative) LTFS Index XML Schema.
3.1.11
Index Construct
A data construct comprised of an Index and file marks.
3.1.12
Index Partition
An LTFS partition primarily used to store Index Constructs and optionally data files.
3.1.13
Label Construct
A data construct comprised of an ANSI VOL1 tape label, LTFS Label, and tape file marks.
3.1.14
Linear Tape File System (LTFS)
This document describes the Linear Tape File System Format.
3.1.15
LTFS Construct
Any of three defined constructs that are used in an LTFS partition. The LTFS constructs are: Label
Construct, Index Construct, and Data Extent.
3.1.16
LTFS Label
A data structure that contains information about the LTFS partition on which the structure is stored. The
LTFS Label is an XML document conforming to the XML schema shown in Annex A (normative) LTFS
Label XML Schema.
3.1.17
LTFS Partition
A tape partition that is part of an LTFS volume. The partition contains an LTFS Label Construct and a
Content Area.
3.1.18
LTFS Volume
A pair of LTFS partitions, one Data Partition and one Index Partition, that contain a logical set of files and
directories. The pair of partitions in an LTFS Volume shall have the same UUID. All LTFS partitions in an
LTFS volume are related partitions.
3.1.19
Medium Auxiliary Memory
An area of non-volatile storage that is part of an individual storage medium. The method of access to this
non-volatile storage is standardized as described in the T10/SPC-4 standard.
14 SNIA Technical Position LTFS Format Specification V2.2.0
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
3.1.20
Partition Identifier (Partition ID)
The logical partition letter to which LTFS data files and Indexes are assigned.
The linkage between LTFS partition letter and physical SCSI partition number is determined by the SCSI
partition in which the LTFS Label is recorded. The LTFS partition letter is recorded in the LTFS Label
construct, and the SCSI partition number is known by the SCSI positional context where they were
read/written.
3.1.21
sparse file
A file that has some number of empty (unwritten) data regions. These regions are not stored on the
storage media and are implicitly filled with bytes containing the value zero (0x00).
3.1.22
UUID
Universally unique identifier; an identifier use to bind a set of LTFS partitions into an LTFS volume.
3.1.23
Volume Change Reference (VCR)
A value that represents the state of all partitions on a medium.
3.2 Acronyms
ASCII American Standard Code for Information Interchange
CM Cartridge Memory
DCE Distributed Computing Environment
ISO International Organization for Standardization
LTFS Linear Tape File System
MAM Media Auxiliary Memory
NFC Normalization Form Canonical Composition
OSF Open Software Foundation
POSIX Portable Operating System Interface for Unix
T10/SSC-4 ISO/IEC 14776-334, SCSI Stream Commands - 4 (SSC-4) [T10/2123-D]
UTC Coordinated Universal Time
UTF-8 8-bit UCS/Unicode Transformation Format
UUID Universally Unique Identifier
W3C World Wide Web Consortium
XML Extensible Markup Language
LTFS Format Specification V2.2.0 SNIA Technical Position 15
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
4 Volume Layout
An LTFS volume is comprised of a pair of LTFS partitions. LTFS defines two partition types: data partition
and index partition. An LTFS volume shall contain exactly one Data Partition and exactly one Index
Partition.
4.1 LTFS Partitions
Each partition in an LTFS volume shall consist of a Label Construct followed by a Content Area. This
logical structure is shown in Figure 1.
Figure 1 — LTFS Partition
The Label Construct is described in Section 4.2 LTFS Constructs and in Section 7 Label Format. The
Content Area contains some number of interleaved Index Constructs and Data Extents. These constructs
are described in Section 4.2 LTFS Constructs and in Section 8 Index Format. The precise layout of the
partitions is defined in Section 4.3 Partition Layout.
4.2 LTFS Constructs
LTFS constructs are comprised of file marks and records. These are also known as ‘logical objects’ as
found in T10 SSC specifications and are not described here. An LTFS volume contains three kinds of
constructs.
• A Label Construct contains identifying information for the LTFS volume.
• A Data Extent contains file data written as sequential logical blocks. A file consists of zero
or more Data Extents plus associated metadata stored in the Index Construct.
• An Index Construct contains an Index, which is an XML data structure which describes the
mapping between files and Data Extents.
4.2.1 Label Construct
Each partition in an LTFS volume shall contain a Label Construct with the following structure. As shown in
Figure 2, the construct shall consist of an ANSI VOL1 label, followed by a single file mark, followed by
one record in LTFS Label format, followed by a single file mark. Each Label construct for an LTFS volume
shall contain identical information except for the “location” field of the LTFS Label.
The content of the ANSI VOL1 label and the LTFS Label is specified in Section 7 Label Format.
Figure 2 — Label Construct
16 SNIA Technical Position LTFS Format Specification V2.2.0
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
4.2.2 Data Extent
A Data Extent is a set of one or more sequential logical blocks used to store file data. The “blocksize” field
of the LTFS Label defines the block size used in Data Extents. All blocks within a Data Extent shall have
this fixed block size except the last block, which may be smaller.
The use of Data Extents to store file data is specified in Section 5 Data Extents.
4.2.3 Index Construct
Figure 3 shows the structure of an Index Construct. An Index Construct consists of a file mark, followed
by an Index, followed by a file mark. An Index consists of a record that follows the same rules as a Data
Extent, but it does not contain file data. That is, the Index is written as a sequence of one or more logical
blocks of size “blocksize” using the value stored in the LTFS Label. Each block in this sequence shall
have this fixed block size except the last block, which may be smaller. This sequence of blocks records
the Index XML data that holds the file metadata and the mapping from files to Data Extents. The Index
XML data recorded in an Index Construct shall be written from the start of each logical block used. That
is, Index XML data may not be recorded offset from the start of the logical block.
Figure 3 — Index Construct
Indexes also include references to other Indexes in the volume. References to other Indexes are used to
maintain consistency between partitions in a volume. These references (back pointers and self pointers)
are described in Section 4.4 Index Layout.
The content of the Index is described in Section 8 Index Format.
4.3 Partition Layout
This section describes the layout of an LTFS Partition in detail. An LTFS Partition contains a Label
Construct followed by a Content Area. The Content Area contains zero or more Data Extents and Index
Constructs in any order. The last construct in the Content Area of a complete partition shall be an Index
Construct.
Figure 4 illustrates an empty complete partition. It contains a Label Construct followed by an Index
Construct. This is the simplest possible complete partition.
Figure 4 — Partition Layout
LTFS Format Specification V2.2.0 SNIA Technical Position 17
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
Figure 5 illustrates a complete partition containing data. The Content Area on the illustrated partition
contains two Data Extents (the first extent comprising the block ‘A’, the second extent comprising blocks
‘B’ and ‘C’) and three Index Constructs.
Figure 5 — Complete partition containing data
NOTE: There must not be any additional data trailing the end of the VOL1 Label, the LTFS Label, nor any Index on an LTFS
Volume. The Label Construct must be recorded starting at the first logical block in each partition.
4.4 Index Layout
Each Index data structure contains three pieces of information used to verify the consistency of an LTFS
volume.
• A generation number, which records the age of this Index relative to other Indexes in the
volume.
• A self pointer, which records the volume to which the Index belongs and the block position
of the Index within that volume.
• A back pointer, which records the block position of the last Index present on the Data
Partition immediately before this Index was written.
4.4.1 Generation Number
Each Index in a volume has a generation number, a non-negative integer that increases as changes are
made to the volume. In any consistent LTFS volume, the Index with the highest generation number on the
volume represents the current state of the entire volume. Generation numbers are assigned in the
following way:
• Given two Indexes on a partition, the one with a higher block position shall have a generation number
greater than or equal to that of the one with a lower block position.
• Two Indexes in an LTFS volume may have the same generation number if and only if their contents
are identical except for these elements:
• access time values for files and directories (described in Section 8.2 ),
• the self pointer (described in 4.4.2), and
• the back pointer (described in 4.4.3).
NOTE: The value of the generation number between any two successive Indexes may increase by any positive integer value. That
is, the magnitude of increase between any two successive Indexes is not assumed to be equal to 1.
The first Index on an LTFS Volume shall be generation number ‘1’.
4.4.2 Self Pointer
The self pointer for an Index is comprised of the following information:
• The UUID of the volume to which the Index belongs
• The block position of the Index
The self pointer is used to distinguish between Indexes and Data Extents. An otherwise valid Index with
an invalid self pointer shall be considered a Data Extent for the purpose of verifying that a volume is valid
18 SNIA Technical Position LTFS Format Specification V2.2.0
© ISO/IEC 2016 – All rights reserved
LTFS Format Specification
and consistent. This minimizes the likelihood of accidental confusion between a valid Index and a Data
Extent containing Index-like data.
4.4.3 Back Pointer
Each Index contains at most one back pointer, defined as follows.
• If the Index resides in the Data Partition, the back pointer shall contain the block position of
the preceding Index in the Data Partition. If no preceding Index exists, no back pointer shall
be
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...