July 31, 2012 – LTFS makes the LTO technology accessible to a broader audience. However, if you plan to use it like a file system on a disk, you will end up being disappointed. To make the most of this technology, you need a basic understanding of how it works.

The pitfalls of the LTFS technology are already described in its name: Linear Tape File System. The keyword here is “Linear”. The one major drawback of tape technology is its linearity. In other words, it takes time to position the tape to a certain point. Then it takes more time to read the data off the tape, since all this involves spooling hundreds of meters (thousands of feet) of tape and positioning through thousands of tracks. An LTO-5 tape is 846 meters long and contains 1280 tracks on a 1/2 inch 6.4 micrometers thick magnetic band.

It takes the drive several minutes to spool the tape from one side to the other. Data is written as a linear sequence of bits on the tape. A tape cannot be written randomly. Data cannot randomly be changed in the middle of a written tape because anything that was previously written beyond that point is then automatically erased and destroyed. This means, that for any practical purpose, data can only be added (appended) to the tape, but no old data can be modified or erased. As a consequence, if one changes a file and re-saves it, although it appears as a single entry in the directory, both the old content and the new will be occupying the tape and space is “wasted” by the old contents.

A tape has a limited and small number of read and write cycles. Repeated reads and writes slowly degrade the tape until it can no longer be used reliably. In case of LTO-5, this happens after around 260 times.

To obtain reasonable performance, the LTO drive has to be fed a constant stream of data. This enables the drive to keep spooling the tape, which enables it to achieve its declared writing speed. Every time the drive has to stop the tape because it does not have enough data to write, speed is lost and the wear and tear on the tape is increased. This effect is called stop-and-go or shoe-shining.

LTFS employs the ability of LTO to partition the tape into two. It uses the first partition to store the directory of the contents that is saved in the second partition. Partitioning also enables it to write data at the beginning of the tape without destroying the data at the end, where the contents resides.

In order to use an LTO tape with LTFS, you have to format it first. A tape has to be mounted in order to appear as a volume or directory in the file system. Every time the LTFS mounts a tape, it will first read the directory off the first partition and save it in memory. Depending on the mount options, it will either write the directory back periodically if it changes or at the end, when the tape is being unmounted. Writing the directory periodically is safer in the event of unexpected failures, however it takes up more time and shortens the tape’s life.

Things to avoid when using LTFS:

  • Do not write single files. This promotes the shoe-shining effect. Rather, select all the files you wish to save, collect them in a folder on disk and copy them in a batch.
  • Do not execute concurrent writes, meaning to start one copy and then another and another at the same time. LTFS is capable of executing them. However, this will mix the blocks of the different files on the tape and will extremely degrade retrieve times, since the system will have to locate the blocks and position the tape on every one of them separately to be able to read them. This extremely degrades retrieve times and promotes the shoe-shining effect.
  • Do not do any concurrent operations for the same reasons as above. An example of such a concurrent operation is doing a copy and paste of a file in the LTFS file system.
  • Do not copy files within the LTFS file system, since this is also an example of a concurrent operation, where the file has to be read and rewritten on the same tape. It wastes space and it promotes the shoe-shining effect, but most importantly, it takes forever to keep repositioning the tape between the old file and the new.
  • Avoid mounting and unmounting a tape. Keep the tape mounted as long as possible, until you have completed copying all your files. This will extend your tape’s life.
  • Keep in mind that deleting files will not release the space they occupy on tape. It will only remove their reference in the directory.
  • Renaming a file is OK. This will not cause a new copy of the file. However, it will cause a change in the directory and may cause the directory to be written out. Writing the directory causes repositioning, interrupts the write stream and takes a lot of time.
  • Do not attempt to open or edit a file directly in the LTFS file system. This will take a lot of time and many applications will not be able to handle the delay appropriately. Make a copy to disk first.
  • Do not expect your file attributes to be saved correctly. Avoid using extended attributes, ACLs, colors, etc. altogether. For one, they will probably not be saved correctly and they will cause the directory to be written with all the consequences as above.
  • Do not expect the operating system’s report of the tape or rather its file system’s capacity to be accurate. There is no way to tell how many of the tape’s blocks are faulty and lost. Furthermore, the OS does not take into account the amount of space lost on deleted or re-saved data.

Most important of all, do not use LTFS to backup or archive your data. You will very quickly find out that you will loose track of what is saved where, when it got saved, the versions, the retention times, etc. All those are taken care of by a good backup or archival program such as PresSTORE. Also, data data that belongs together but occupies several  tapes can quickly become an unmanageable problem.

The primary application LTFS was developed for is to transport data between sites and to exchange data. If you employ it for what it was designed for, you will find it to be a valuable tool.

On the LTFS Experience Part 2
Tagged on:             

5 thoughts on “On the LTFS Experience Part 2

  • July 31, 2012 at 4:03 pm
    Permalink

    Ibrahim,

    Is the following hybrid approach possible? I don’t require that my LTO Archive be transient. I was thinking that I could use LTFS to create a mounted volume, with a directory that is representative of my PresStore Archive, and instead of storing source files, proxy or stub files would be stored on the LTFS volume. My fuzzy logic works like this. I commit a single file or batch of files to archive via PresStore. I use PresStore to commit a batch of proxy/stub files to the LTFS volume, thus limiting its use to only maintaining a deep archive directory.

    • November 21, 2012 at 2:34 pm
      Permalink

      Hi Grant. This is a possible approach. You will of course have to make sure that the tape is really mounted all the time. However, I am not sure how you intend to search the contents later on. Relying on the Finder to display previews (of the proxies) or to traverse this file system will cause reading the tape contents every time and will be slow, to say the least.
      — Ibrahim

  • November 15, 2012 at 5:05 pm
    Permalink

    Hindsight is 20/20.

    using LFTS: I’ve backed up roughly 12TB of dpx images sequences to LTO-5. Each
    sequence broken into 1HR REELS. Now its time to restore and I’m stuck with reads from the LTO at 1MB/sec. I’m attributing this to concurrent writes. Without knowing any better FileZilla was used to transfer all my dpx sequences and no doubt multiple writes were executed during the orig backup.

    Are there any workarounds to recover this data at reasonable read speeds

    any advise would be appreciated.

    thanks
    J

    • November 21, 2012 at 2:30 pm
      Permalink

      Hi Jason. I am sorry, but all I can suggest is to try to restore one file at a time and hope for the best. Since the blocks of the different files interleave and the files are scattered on the tape, there is no real help there.
      — Ibrahim

  • January 26, 2013 at 5:18 am
    Permalink

    Sorry – but I really don’t agree with the statement.. “Most important of all, do not use LTFS to backup or archive your data.”.

    I’ve used LTO/LTFS in production from staged volumes which were then written to LTFS formatted tapes. It’s particularly well suited to the ‘completed’ work model found in production and media companies all around the world.

    We created our own setup from a Linux server and SAS adapter connected to an HP LTO5 device. It works very well.

    For solutions that have more complete front-ends, Cache-A are doing some interesting work in this area as well.

Comments are closed.