archive exchange format
from its content transport-centric focus. In fact, AXF provides all of the features offered by LTFS and more benefits besides. Further, because AXF does not rely on features of modern data tape technologies, its use does not require costly upgrade of existing infrastructures.
AXF architecture
AXF has been architected so that each AXF object originates with an AXF object header - a structure containing descriptive XML metadata such as the AXF object’s unique identifier (UMID/GUID), creation date, object provenance and file-tree information, including file permissions. Following the AXF object header are any number of optional AXF generic metadata packages that are self-contained, open metadata containers in which applications can include AXF object-specific metadata. This metadata can be structured or unstructured, open or vendor-specific, binary or XML. The next part of the AXF object construct is
any number of file data + file padding + file footer triplets - or the AXF File Payload, the actual byte data of the files encapsulated in the object. The file footer structure contains the exact size of the preceding file along with an optional file level checksum designed to be processed on the fly by the application during restore operations. The final portion of an AXF object is the AXF
object footer, which repeats the information contained in the AXF object header and adds information captured during the AXF object’s creation, including per-file checksums and structure block positions. The AXF object footer is important to the resiliency of the AXF specification because it allows efficient re-indexing by foreign systems when the media content is not previously known. This adds self-describing characteristics to the AXF medium itself, ensuring full recoverability in the case of application data loss or movement to a foreign system, regardless of the storage technology selected.
Use with linear data tape
Used with linear data tape, an AXF implementation includes three additional structures to incorporate self-describing characteristics on the medium itself, ensuring full recoverability in the case of application data loss or movement to a foreign system. The first structure, which appears on the medium, is an ISO/ANSI standard VOL1 volume label. This is included for compatibility purposes with legacy applications to ensure they do not erroneously handle AXF formatted media. The second structure is the Medium Identifier, which contains the AXF volume signature and other information about the storage medium itself. The implementation of the Medium Identifier differs slightly depending on whether the storage medium is linear or nonlinear, and whether it includes a file system or not, but the overall structures are fully compatible.
The third structure is the AXF object index,
which is an optional structure that assists in the recoverability of AXF-formatted media. It is simply a collection of AXF object footer structures containing information for the AXF objects on the storage medium. Information contained in this structure is sufficient to rapidly recover and reconstruct the entire catalogue of AXF objects on the storage medium. In a case where the application has not maintained the optional AXF object index structures, the contents of each AXF object can still be reconstructed by simply processing each AXF object footer structure.
General benefits of an embedded file system
The AXF specification’s embedded file system enables it to translate between any generic set of files and logical block positions on any storage medium, whether or not the medium has its own file system. This gives AXF an advantage over formats such as LTFS that rely on partitioning and file marks on data tape or other storage technology elements because that reliance hinders both storage capabilities and performance. Likewise, these alternative formats are ineffective for complex file collections with millions of related elements, and for extremely large individual files, which may span more than one storage medium. A further benefit of AXF over legacy container
formats, as well as some modern operating and file systems, is its ability to scale without limits, encapsulating any number of related component files of any size. AXF also supports spanning of payload data across storage media ensuring even the largest assets can be stored on any media type without advanced knowledge of storage size or media capacity. These are the key to AXF’s ability to support large-scale archive and preservation systems as well as simple, standalone applications. The benefit to users is easier encapsulation or wrapping of content, longer term protection, and the ability to transport content between systems from different vendors without regard for the underlying storage technology, the file system, or the operating system.
Conclusion
An open format for storage and preservation of media assets supports interoperability among systems, helps ensure long term accessibility to valued assets, and keeps up with evolving storage technologies. These benefits will offer profound present and future advantages to any enterprise that uses media - from heritage institutions, to schools, to broadcasters. Having incorporated AXF into the latest release of DIVArchive, launched at the 2011 NAB Show, Front Porch Digital today is committed to working closely with standards bodies such as SMPTE for its ratification and standardisation.
Amsterdam in
special report
www.riedel.net www.ibeweb.com l september/october 2011 l ibe l 77
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80 |
Page 81 |
Page 82 |
Page 83 |
Page 84