IBM LTO5 data tape media.

The Academy of Television Arts & Sciences has announced the recipients of the 63rd Primetime Emmy® Engineering Awards. This year, one of four Engineering Emmys will be awarded one of which goes to IBM for the LTFS technology.

I was responsible for the architecture, format specification, and development lead for the Linear Tape File System (LTFS) from the start of the product development. During my work on LTFS I was instrumental in producing LTFS Single Drive Edition for Linux, OS X and Windows in 2010 (all platforms released within 12 months of starting the project); producing LTFS Library Edition in 2011; and laying plans for future LTFS products up to my last day at IBM.

omgbbqwtf!! Over.

“I’d like to thank the Academy, …”

“Original article found at And the Emmy goes to…    LTFS.”

I will need to come up to speed before I can talk intelligently about what Nimbula is doing and my role in the company. Right now, after a week I can only comment on the simplicity of the on-boarding process.

Mon 9:30am good morning…

Arrive and shown to my desk.
Monitor, Apple Keyboard, Magic Mouse, and 13″ MacBook Pro already hooked up.
Laptop is wired for ethernet and also already connected to company WiFi.

9:35am passwords changed, email working

Logged in.
OS X password changed.
Logged in to email.
Changed email password.
A bunch of applications are already installed… Chrome set as default browser, SIP softphone, Skype, Adium, DropBox, Evernote, VirtualBox, OpenOffice, TunnelBlick and others. Company-specific settings such as VPN and SIP are already configured.

10:10am

I have DropBox syncing with my personal account and 1Password installed waiting for DropBox to finish syncing my password vault.

10:30am more passwords changed

IT guy comes over and points me to a wiki page with a list of new hire setup instructions and starts walking me through the handful of password changes I need to make. He realizes that I have already changed my OS X and Google Apps passwords so we run through the remaining company-specific passwords.

10:45am hr paperwork

Our office admin comes by to point me at the HR web portal. Two screens later and I have completed my I-9 form by verifying the pre-populated data, entering my Alien number, typing name and the date for an esignature. Our admin hands me the 401k plan documents and points me to the benefits signup pages and some other online HR documents I should read.

11:10am making lists

I start putting together a list of account passwords to save into 1Password when DropBox finishes syncing. The list expands to other cascading setup tasks: install Office2011, extract old contacts from previous Outlook identity, investigate iCal or Outlook with Google Calendars, install XCode, setup Fink, etc, etc.

11:18am continue through the list

I paste a copy of the New Hire wiki page into TextEdit and strike off the completed tasks. Roughly 50% of tasks are already done.

12:05pm access bug tracking

I skim the current bug list after my new hire task list directs me to login to bug tracking site and verify my account is working.

12:20 lunch

Recruiter reminds me that lunch is brought in four days a week and there is a picnic table outside with a cafe umbrella in the sun.

By lunch I was largely done with the on-boarding process and had access to all the systems in use other than the development cluster. It was predominantly self-directed without the baggage of other “self-directed” training I have experienced. Throughout the morning a number of people came by to say hello and ask if I need anything.

Early afternoon my mentor, who I had met during my interviews, walked me around the office to introduce me to the people in the office. Without fail, everyone dropped what they were doing for a few minutes to say hello to the new guy.

By the end of day Friday I had finished the HR paperwork, read the Employee Handbook, largely finished configuring my laptop, arranged my desk, and have started getting up to speed on the product.

“Original article found at joining Nimbula.”

In my time here, I have shipped 4 different LTFS releases, numerous LTFS fixpacks, 3 LTFS Format Specifications, the first Information Archive appliance release, several internal projects, along with multiple papers and patents. I’ve worked with some extremely talented people and have helped an industry change the way they store and manage their data.

I will be taking some personal time before starting in my new role. I will continue posting my brain dumps about LTFS to capture as much information as I can share publicly. Over time I expect to post more about the new space in which I will be working.

“Original article found at leaving IBM.”

With LTFS we took a very different approach. The LTFS filesystem-based approach to accessing data stored on tape brings significant benefits to the tape market. For example, application developers no longer need to learn specialized APIs, and users get a fully self-describing storage medium that largely behaves the same as more common storage media such as hard-disk drives and memory sticks.

The benefits afforded by LTFS are arguably sufficient to support releasing LTFS as proprietary software that uses a closed data format on the tape media. Rather than treating LTFS as yet another proprietary on-tape format, the LTFS team at IBM elected to release the LTFS Single Drive Edition (LTFS-SDE) software as open-source¹. The LTFS open-source software release is licensed under the LGPL license to protect the LTFS format while providing application developers the ability to dynamically link with LTFS binary code without risking their own intellectual property. Each fix-pack released for LTFS-SDE has also been released under the LGPL.

In addition to the open-source software release, the LTFS team wrote the LTFS Format Specification document and released this specification to the public. This Format Specification describes the on-media data structures in sufficient detail for independent developers to read and write LTFS tapes that are compatible with other LTFS implementations.

During development of the LTFS software and the LTFS Format Specification the IBM team built a working relationship with developers at both HP and Quantum through the LTO Consortium. These relationships afforded an opportunity to inform HP and Quantum about the up-coming LTFS technology and allowed for some pre-release co-ordination between these three LTO 5 vendors. These on-going relationships have provided the opportunity to conduct inter-operablity testing between all three vendors. We are fortunate to enjoy continuing discussions between vendors on the direction and development of the LTFS format.

This communication, the open-specification, and the open-source approach to software distribution is motivated by a desire for LTFS to become an industry-wide standard. During LTFS development we recognized that if LTFS was a proprietary release then we would be adding to the fragmentation and incompatibility of data tape use. Instead, a release of LTFS as an open implementation with an open specification would create an environment that may lead to broad industry adoption. Broad adoption along with the ease of use benefits may result in expanded use of tape media for data storage. Expansion of the tape market would be good for the industry and all of us involved in the data tape business.

“Original article found at LTFS Format Specification and Open-Source.”

This Mac Mini is a late 2009 model with a 2.26GHz Core 2 Duo processor, 4GB of RAM, and an NVIDIA GeForce 9400 GPU. Since this machine is not mission-critical for our household I figured it would be a reasonable candidate for our first Lion upgrade.

After the upgrade video streaming has become practically impossible. Both Hulu Desktop and web-based video streaming suffers from decompression artifacts that result in blocky video and video freezes. After a minute or so of playback the video stream will freeze on the current image and audio playback will continue. When the video freezes if I use VNC to access the machine I can see that the mouse cursor is beach-balling.

I have found that video playback can be made reliable and returned to the same quality as provided by OS X Snow Leopard (10.6) by disabling the new Lion functionality that restores applications to their running state after a reboot. To disable this function, open the System Preferences->General panel and uncheck the “Restore windows when quitting and re-opening apps” option. The option is shown unchecked in the screenshot below.

The OS X Lion 'Restore windows when quitting and re-opening apps' option. Option shown unchecked.

My suspicion is that the background task that takes a snapshot of the memory and system state for each running application is failing behind in taking snapshots when large amounts of RAM are updated. In video streaming by definition the application memory is undergoing large frequent updates. If my suspicion is correct, then instead of dropping work items the snapshot application is trying to process an ever-increasing list of work. The result appears to be CPU starvation to video playback. This starvation probably occurs in the Quicktime stack since the behavior is demonstrated in different playback applications.

“Original article found at Problem with video-stream playback in OS X Lion (10.7).”

In this post I describe some inconsistent states a volume may wind up in, the scenarios that may lead to these states (often power-loss), and how ltfsck recovers to a consistent state.

I’ve described the layout of a consistent LTFS Volume here and here. A consistent LTFS Volume is illustrated below. An LTFS Volume must be consistent at mount time otherwise the LTFS software will reject the volume and instruct the user to run the ltfsck utility to recover the volume to a consistent state.

Logical layout of an LTFS volume showing historical Indexes with back-pointers and multiple files written and edited in-place.

Notice that this consistent LTFS Volume matches the definition of a consistent state. Specifically, that the current Index is written at the end of both partitions on the media.

Power-loss after writing DP Index

In the event of a power loss while unmounting the LTFS Volume the volume may end up in the state illustrated below.

Logical layout of an LTFS volume showing historical Indexes with back-pointers and multiple files written and edited in-place after power-loss during IP Index write.

In the example above, the LTFS cartridge was unmounted after writing File A and B to the volume. This unmount resulted in Index². The cartridge was then mounted again and File A was opened for writing and had some new data written. This new data is stored in the purple extent labeled “File A³”. The cartridge was then unmounted. This unmount processing wrote the current Index as Index³ and switched to the Index Partition and started to write the current Index. This unmount processing follows the order listed here. Before the Index write completed the system crashed or lost power. This loss of power prevented completion of the Index write to the IP.

If this cartridge is mounted again the LTFS software will identify that the volume is inconsistent and recommend that ltfsck be used with the volume. ltfsck will identify the partial write of the Index to the IP and attempt to read the Index³ stored on the DP. If the Index at the end of the DP can be read successfully then ltfsck will over-write the partial Index on the IP with a duplicate of Index³ from the DP. After this write the cartridge will be consistent and in the state shown in the first diagram on this page.

A similar situation occurs if the power loss occurs after the current Index is written to the DP but before the current Index is written to the IP. The resultant volume structure is shown below.

Logical layout of an LTFS volume showing historical Indexes with back-pointers and multiple files written and edited in-place after power-loss during partition change.

In the example above, encountering a power-loss while the tape drive is changing partitions has resulted in a correct DP with the current Index as Index³, but the IP still has the old Index². In this scenario, the LTFS software will identify that the Index² on the IP is out of date based on the values stored in the cartridge MAM parameters and reject the LTFS Volume. ltfsck will identify based on the MAM parameters that Index³ at the end of the DP is the most current Index and will over-write Index¹ on the DP with a copy of Index³.

This recovery is equivalent to the previous recovery of the partially written Index. In both cases, there is no loss of user data.

Power-loss before writing DP Index

In the event of a power loss while writing file data to the LTFS Volume the volume may end up in the state illustrated below.

Logical layout of an LTFS volume showing historical Indexes with back-pointers and multiple files written and edited in-place after power-loss during write of new data file.

In the example above, the file data write for “File ?” was in progress when the system crashed or lost power. Immediately before the loss of power the filename for this file existed in memory in the Index but the LTFS software was waiting for the write operation to complete before laying down the current Index as “Index⁴”. Due to the power loss, the updated Index was written to the media and there is no way of knowing whether the data stored in the black extent labeled “File ?” is complete or just a partial write.

In this example, the LTFS software will refuse to mount the volume and suggest that ltfsck be run against the volume. When ltfsck is run the user has a few different courses of action. By default the ltfsck utility will identify the “unexpected” data at the end of the DP and perform recovery actions to:

1. read Index³ from the IP,
2. create a directory at the root of the LTFS filesystem named “_ltfs_lostandfound” if the directory doesn’t already exist,
3. update Index³ to include the “File ?” data as the contents of one or more files with generated filenames. Each separate file contains the data written to a single block on the media. The files are stored in “_ltfs_lostandfound”,
4. write the updated Index out as Index⁴ to the DP, and
5. perform normal unmount processing to write Index⁴ to the IP.

The layout of the LTFS Volume after these recovery steps have been performed by ltfsck is illustrated below.

Logical layout of an LTFS volume showing historical Indexes with back-pointers and multiple files written and edited in-place after power-loss during write of new data file, followed by full data recovery by ltfsck.

In the illustration above, the LTFS Volume is consistent but the data blocks shown in black have generated filenames rather than the user-specified filename. Additionally, these recovered data blocks are most likely to contain only partially written data. Recovering the blocks to the volume as recovered files provides the ability for the user to copy these blocks off the volume and re-construct the original data if no other copy exists. In most scenarios the user will still have a copy of the original data elsewhere because the file write to LTFS had not completed before the power loss.

After the user has finished working with the recovered files on the LTFS Volume there is probably no need to leave the blocks on the LTFS Volume. Rather than deleting the recovered files the user can use ltfsck to rollback the LTFS Volume to the Index³ snapshot. Using ltfsck to roll the volume back, rather than deleting the recovered files, means that the space occupied by the partial write (shown in black) will be reclaimed and the LTFS Volume will be returned the the state shown in the first illustration at the top of this page.

If the user has encountered a power loss during file write as described above and the user is not interested in recovering the partially written data, ltfsck provides a command-line option to automate the recovery of the LTFS Volume. With this automated recovery, rather than generating Index⁴ (described above), ltfsck simply erases the “File ?” data thereby returning the volume to the consistent state shown in the first illustration at the top of this page.

“Original article found at Filesystem recovery examples with ltfsck.”

“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.”

where a complete parition is:

“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.”

The LTFS Format Specification additionally includes the following conformance statement:

“Recorded media claiming conformance to this format shall be in a consistent state when interchanged or stored.”

In practice this conformance statement means that when an LTFS Volume is ejected from an LTO drive the volume must be consistent. Software implementing support for the LTFS format can expect a consistent LTFS cartridge when the cartridge is loaded and reject inconsistent cartridges.

Logical layout of a consistent LTFS volume showing historical Indexes with back-pointers and multiple files written and edited in-place.

The LTFS software writes an updated Index to the end of the Data Partition (DP). The Indexes stored in the DP are interleaved with the file content that is also stored in the DP. LTFS maintains each Index written to the DP for three core reasons:

• data safety,
• performance, and
• snapshots/rollback.

Data safety
To protect the data stored on the media it is vital that LTFS commit an updated Index to the media soon after the file content is written. Without the updated Index, new file content cannot be accessed. Additionally, maintaining the current Index in the DP along with the same logical Index stored in the Index Partition (IP) provides a redundant copy of the Index on the media. These redundant copies mean that in the event of catastrophic failure there is a second chance to read a valid current Index.

Performance
In normal LTFS operation the tape head is positioned in the DP to allow rapid access the file content storage area to service read and write requests. When a new Index needs to be written to the media the LTFS software will write the new Index to the DP and continue servicing any concurrent write operations. By writing the Index to the DP in-line with the file content the LTFS software does not incur a penalty for switching to the other partition and seeking back to the Beginning of Tape (BOT).

Snapshots and rollback
The Indexes written to the DP are likely to be followed by file content during write operations. LTO data tape is sequential media which makes it impossible to delete these Indexes without destroying any file content data that is written after the Index. Maintaining these Indexes provides the ability to inspect and potentially revert the LTFS Volume to any earlier time for which an Index exists on the media. For example, if you work with an LTFS Volume by adding, updating, and deleting files. If you later decide that these changes are not wanted then you can either mount the LTFS Volume read-only using an earlier Index to show and access an earlier version of the volume, or you can permanently revert the LTFS Volume to the an earlier state using a rollback operation.

The Index written to the IP is typically written during unmount processing of the LTFS file-system. During unmount the following operations are performed in order:

1. all file content written to the volume but still in memory is flushed to the DP,
2. an updated Index is written to the DP,
3. LTO cartridge memory is written with new MAM parameters,
4. the tape head is moved to the IP,
5. any file content destined for the IP is written overwriting the old Index,
6. a replica of the current Index is written to the IP overwriting the old Index,
7. LTO cartridge memory is written with new MAM parameters, and
8. media is rewound then optionally ejected.

Note that it is safe to overwrite the old Index on the IP because the LTFS software has successfully written the current Index at the end of the DP in operation #2. The details of how MAM parameters are used and the conditions in which file content may be written to the IP are described in a later blog post.

“Original article found at LTFS consistency and Index snapshots.”

LTFS relies on the cartridge partitioning support that was introduced in the LTO5 specification by the LTO Consortium. Earlier generations of LTO media and drives do not have this partitioning capability and are therefore unable to support the LTFS on-tape format.

Support for multiple partitions at the media and hardware level is the key enabling functionality that allowed my team at IBM to invent and implement the LTFS technology. The details of how LTFS uses partitioning and the tape media are the subject of other posts on this blog, specifically Partitioning in LTO5 and LTFS, and How does LTFS work?.

Without partitioning support there are limited options for where the file-system metadata (or “Index”) may be stored on the media. With LTO generations prior to LTO5 these limited options are all that we have to work with. None of these options provide a satisfactory mix of performance, data safety, and business opportunity to make it practical to pursue LTFS on these older generations.

LTFS is available for LTO5 from all current drive vendors (IBM, HP, and Quantum). Additionally, LTFS is available for IBM’s enterprise tape product the TS1140 (aka Jaguar) and has been ported by Oracle to their T10000C product line. At this point LTFS has been adopted by all actively developed data tape technologies.

“Original article found at Can you use LTFS on LTO4 or earlier media?.”

This blog entry outlines the sync() behavior in LTFS and the rational behind the associated design choices. In this post, comments that reference the sync() system call apply equally to the FlushFileBuffers() call in LTFS-SDE for Windows.

The Linear Tape File System – Single Drive Edition (LTFS-SDE) maintains the working copy of the Index for the LTFS Volume in main memory while the file-system is mounted. Additionally, individual write calls are cached in memory in block-size memory buffers in an attempt to write large blocks of data to the media rather than performing many very small writes to the media. This write-caching dramatically increases write performance of the file-system. The metadata caching is briefly described in an earlier blog post. Write-buffer caching in LTFS-SDE will be discussed in a future post. This metadata cache and the write-buffers are at risk in the event of a system crash or power-loss.

In LTFS there is also the additional concern about frequency of sync() operations. A file-system on random access media such as flash or a hard-drive can update the on-media Index in-place. This means that frequent updates to the on-media Index will over-write older versions and therefore will usually occupy the same amount of media space. With sequential media there is a real risk of consuming all of the media space with metadata Indexes leaving no room for data storage. Careful design of our sync() operations in LTFS has resulted in a balanced and safe range of sync() functionality that can be tweaked to meet differing user scenarios.

LTFS v1.0 and v1.1

The first two releases (v1.0 and v1.1) of the Linear Tape File System took a very simple approach to synchronizing the metadata cache and write-buffers. In these releases, the Index metadata is only flushed to the media is when a partition change occurs, or when the Volume is unmounted. In typical operation (without a data placement policy defined) there will never be a partition change to the Index Partition. In effect, an Index will only be flushed during unmount. (For the purpose of this blog post I will ignore data placement policies to simplify the discussion.)

Since LTFS v1.0 and v1.1 will only flush the Index during unmount, if the system loses power the user is exposed to potentially losing all of the data changes made to the Volume during the entire mount session. This data loss would include any files written to the LTFS Volume, any changes made to files already on the LTFS Volume, and any metadata updates such as file deletes, file renames, file moves, and timestamp updates.

Traditional file-systems

Traditional file-systems (NTFS, HFS+, ext3, etc) maintain a similar in-memory working cache of parts of the file-system Index and write-buffers. These caches and write-buffers help improve file-system performance. At any point with these traditional systems there is the potential for the same types of data loss described above if the in-memory file-system Index has not been flushed to the storage media. This is the primary reason for requiring an explicit unmount operation before disconnecting a hard drive from a running system. In Linux, the unmount operation is performed using the “umount” command. In Windows, the unmount operation is performed using the “Safely Eject Device” GUI action.

In modern systems the a background kernel thread takes periodic action to reduce the this risk of data loss by triggering a flush of the in-memory file-system Index cache. This periodic action is typically performed every 5 seconds and flushes any changes to mounted file-systems. As a result, the window of risk with traditional file-systems is limited to the last 5 seconds of operation.

LTFS v1.2

With LTFS-SDE v1.2 we added two new sync() behaviors to help reduce the risk of data loss. These behaviors have different semantics and are appropriate in different user scenarios. The new behaviors are:

• Time-based sync, and
• Sync-on-close.

“Time-based sync” behaves as logically equivalent to the traditional operating system driven sync() operation. That is, at a defined time period the file-system will flush the in-memory Index to the media if there are any changes to the Index that only exist in-memory. The sequential nature of tape prompted me to set the default time period for time-based sync at 5 minutes. Thus the user is exposed to data loss for only the past 5 minutes of operation. On balance I felt that 5 minutes was a reasonable compromise between “wasting” a large amount of tape space for frequent Index updates versus the time period during which the user is exposed to data loss. The default time period can be overridden at mount time by users who have particular requirements.

“Sync-on-close” provides a sync() semantic where each time a file is closed the in-memory Index is flushed to the media if the Index has been updated. This ensures that each time the user finishes operating on a file all changes in the file-system are flushed to the media. Some metadata changes do not involve a close() operation. With these metadata operations there is potential risk to losing the result of these operations in the event of power-loss. Myself and the other members of the LTFS development team felt that the metadata operations that remain at risk are operations that can tolerate higher risk than file-content.

In LTFS-SDE v1.2 the user can specify “time-based sync” or “sync-on-close” at file-system mount time. The desired sync() behavior can also be configured system-wide in the ltfs configuration file.

If “time-based sync” or “sync-on-close” are enabled the file-system will still perform a sync() during unmount operations.

Manual sync()

LTFS-SDE v1.2 also exposes the ability for the user (or an application) to manually trigger a file system sync() by writing to the ltfs.sync extended attribute. If this sync() is triggered while there are open file handles there is the potential that the Index written will contain partially written files.

All versions of LTFS-SDE to date ignore sync() system calls from user-space. This is a limitation of the FUSE library. The FUSE developers are rightfully concerned about a FUSE-based file-system taking an arbitrarily long time to complete a sync() during which the whole system will be blocked. The ltfs.sync extended attribute and the time-based sync are approaches to provide traditional sync() functionality without FUSE support for the sync() system call.

Potential user concerns

In the situation where “time-based sync” is enabled and a file copy is performed that exceeds the sync timeout value an Index may be written to the media in the middle of the copy operation. Assume that Index generation 4 was written before the copy started and Index generation 5 is written in the middle of the file copy operation. Index generation 5 will contain an entry for the file that is in the middle of the copy operation and only the data that has landed on the media will be referenced in this Index. This means that if the file copy is 50% done when the sync() occurs then the Index will only reference the first half of the file being copied. If, at a later date, the user chooses to roll-back the Volume to Index generation 5 then the Volume will only contain the first half of the file after the roll-back. This may be perceived by the user as a data-loss scenario, but technically the roll-back has not resulted in a loss of data. Index generation 5 will correctly represent the state of the LTFS Volume at the point in time when the Index was written.

We explored ways to remove this perceived problem but none of the potential changes will eliminate this issue. In fact, this partial-write being perceived as data-loss exists with any sync() operation that is performed outside of the unmount processing. For example, consider a Volume that is mounted with only sync-on-close enabled and two files (A.txt and B.txt) are simultaneously copied to the filesystem from two different copy commands. If A.txt is significantly smaller than B.txt then the close() operation on A.txt will trigger a sync operation. Assume that this sync() operation produces Index generation 10 on the Volume. If a user then rolls back the volume to generation 10 they will find that only part of file B.txt exists on the Volume.

A potential solution would be to track open file handles that are open as a side-effect of a create() call. If these handles were tracked the file system could theoretically prevent a sync operation until these handles were closed. This approach would reduce the potential for partial files on roll-back. However, this approach would not cover cases where a copy operation is performed on a filename that already exists in the filesystem. In the case where the file already exists applications typically use “open()” followed by either a truncate or seek to the beginning of the file and just start overwriting the file contents. In these cases we still would get partial writes on the Volume if a roll-back is performed.

All of these partial write scenarios exist in traditional file-systems that operate on flash and hard drive media. However the scenarios are hidden on the traditional media because the Index is updated in place rather than recording a sequence of Index snapshots as happens with LTFS.

My team explored a number of potential changes to address the concern over partially written files appearing after a file-system roll-back. We did not find an approach to addressed all partially written file scenarios without introducing significant complexity into the file-system. My judgement was that the risk of added complexity did not justify the development effort.

In a future version of the LTFS Specification I hope to extend the LTFS Format to keep track of the number of open files when an Index is written to the media. If this open file count is written as part of the LTFS Index it could be exposed in the roll-back point list. This change would not remove the potential for partially written files but it would expose to the user the necessary information for them to understand which Index generations may have partial files. The user can then make an informed choice about which generation to select. I believe that this extension the best way to address concerns over partially written files.

“Original article found at sync() behavior in LTFS.”

A data tape formatted for use with LTFS has two partitions, an Index Partition (IP) and a Data Partition (DP). The Index Partition has a relatively small capacity of 37.5GB. The Data Partition comprises the remaining 1.43TB of available capacity on the media.

LTFS writes an Index that holds all the file and folder meta-data for the LTFS Volume to the Index Partition. The LTFS Format Specification defines that a consistent LTFS Volume must, along with other properties, have the most-recent Index written to the end of both the IP and the DP. In the diagram below, “Index²” is the most-recent Index. The specification defines that an LTFS Volume must be consistent when it is exchanged with another system. In practice, this means that any compliant implementation of the specification that operates on an LTFS Volume must ensure that the media is consistent when the media is ejected.

At mount-time the LTFS software reads the current Index from the IP and builds an in-memory structure representing all of the folders and files stored on the media. This structure contains meta-data such as file timestamps, file permissions, file name, file size, etc. The structure also contains the location on the DP for each data extent that holds part of the file content.

When a user or an application traverses a mounted Linear Tape File System the LTFS software can return filenames, folders, timestamps, file sizes, and other meta-data from the in-memory index structure. When the user double-clicks on a file to open it, or an application reads from a file the LTFS software causes the tape drive to seek to the start of the relevant data extents and reads the data from the tape media.

LTO5 tape drives are able to stream data for reading and writing at 140MB/s. This speed is about 40% higher than the best hard-drives which top out at around 100MB/s. Of course, since LTO data tape is sequential access media there is a high seek time for data tape. Worst case seek time is moving from one end of the physical tape to the other end. An end-to-end seek will take roughly 90 seconds. So the average seek time is around 45 seconds.

Logical layout of a LTFS Volume on LTO5 media. Beginning of Tape (BOT) at the left edge of diagram, End of Tape (EOT) at the right edge. Diagram is not to scale. BOT to EOT is 846 meters (~2775 feet) and tape width top-to-bottom is 1.27 centimeters (1/2 inch).

LTO5 data tape writes data in a sequence of wraps on the physical media. Each wrap consists of one track of data written in a forward direction along the length of the tape plus another track of data written in a reverse direction along the length of the tape. There are 80 such wraps on LTO5 media. To fully traverse all of the stored data on a full LTO 5 cartridge requires traversing the length of the tape one-hundred and sixty times. (Eighty times in the forward direction interleaved with eighty times in the reverse direction.)

As a result of the wrap-based data layout a seek to the beginning of a randomly selected file is often quite fast. Typically a seek to the beginning of a file will only require a short tape movement along the length of the tape along with a lateral head movement that is perpendicular to the axis of tape movement. These lateral head moves are performed in a few seconds.

Writes to a file stored in LTFS are performed by seeking to the end of the data and writing the file content to the media. If the file already exists in the LTFS volume then only the “over-written” areas of the file are written at the end of the DP. The extent list for such files that are modified “in-place” (on tape media) is updated to insert the new extents into the appropriate offsets in the extent list for the file.

“Original article found at How does LTFS work?.”