My statement about the wrap size of 37.5GB is in error. The correct statement is that the Index Partition and the guard wrap decrease available storage by roughly 37.5GB. Since the Index Partition occupies a single wrap and the guard wrap occupies another wrap. The correct math would be 37.5GB divided by 2 wraps = ~18.75GB per wrap. These numbers will vary in real use due to media quality and data compression.

I am trying to make some diagrams about LTO5 and LTFS and got a little confused about the math. You state that each wrap consists of 2 tracks (one in each direction) and there are 80 wraps on the tape, which means that there are 160 tracks per tape. Yet wiki says that there are 1280 tracks per tape, which means that every wrap should consist of 16 tracks… What’s the catch?

And another question: In your “Partitioning in LTO5 and LTFS” article you state that the data capacity of the wrap is 37.5 GB. If you multiply 37.5 with 80 you get roughly 3TB, when it should be 1.5 TB according to specs… How is that possible?

Thanks and regards,

With regard to an ltfs sdk or ltfs-sdr build, I know of there is no such build available to the public. The LTFS codebase on Windows contains roughly 98% of the Linux LTFS codebase. But on Windows IBM uses a third-party library to hook into the Windows kernel. This library is only licensed by IBM for binary distribution so there no good options for distributing the LTFS Windows source given this dependency. I do not know the current IBM thinking regarding the Windows codebase.

With regard to integrating into a Windows-based system, I know of two approaches that have been used by system integrators. Approach one is to use the LTFS for Windows binary code and actively monitor the LTFS log events to identify when LTFS transitions to/from an active filesystem state when a tape is inserted/ejected. Approach two is to use a virtualization product like VMware Player to host a guest Linux OS on your Windows machine. This Linux guest can run Linux LTFS and export the LTFS volume via a CIFS/Samba share. The Windows machine running on the physical hardware can then mount the exported LTFS volume using Windows file sharing.

Both of these approaches have their own particular trade-offs and rough-edges. However, both of these approaches have been used by system integrators in shipping solutions delivered to significant numbers of customers.

First of all, Happy New Year.

Now, my company is looking for a way to integrate LTFS into our system. We made some tests with the LTFS-SDR (windows version) and it looks great but it is unusable in an automated environment.

I read that you don’t work on the project anymore but I tough you could point me out to the right place where to get a proper ltfs sdk or an ltfs-sdr build without all the ui requirements (pop-up on mount / eject trough interface / etc / … ) for windows as its source code was never released.

Best Regards.

The illegal characters are ‘/’ (forward slash), ‘:’ (colon), and null. The disallowed characters are ‘*’ (asterisk), ‘?’ (question mark), ‘”‘ (double quotation mark), ” (greater than sign, ‘\’ (backslash), ‘|’ (vertical line), and the control codes U+0009, U+000A, U+000D. The illegal characters are often unusable in filenames on any filesystem. The disallowed characters are characters that we identified during LTFS development as causing problems for cross-platform compatibility of LTFS volumes. We made the decision to block use of these characters in our software to avoid problems when using LTFS volumes on different platforms.

LTFS5 tapes support 1.5TB of raw, uncompressed storage. After formatting with LTFS there is about 1.47TB of available storage on the tape. Average video files do not gain much benefit from compression because the video data is very dense in common file formats. I have seen video get some benefit from compression, but that benefit is on the order of ~5-10%.

Some tape vendors choose to market their tapes as LTO5 with 1.5TB of storage. Other tape vendors choose to quote the “1.5TB – 3.0TB” of storage where the high number assumes the data is 2:1 compressible.

Your thinking makes sense as to why this issue occurs. I have seen my operating system work much more effectively since updating this setting also.

4Gb Ram
iMac 2.8 GHz Duel Core

With regard to storing the .dmg files and allowing random access, I expect that this will work. I do not recall whether I tested this explicit use-case for LTFS.

The MacFUSE framework allows individual byte-level access to files and does not cause any additional reads other than those requested by applications accessing the filesystem. However, the Mac OS X default behavior of verifying the .dmg file prior to mounting the disk image is likely to be a full read of the fisk image. You can skip the verify step by clicking the ⊗ button in the disk image mount dialog box. Otherwise, the disk image verification can be disabled at the system level by issuing the following terminal command:

defaults write com.apple.frameworks.diskimages skip-verify true

I recommend that you only do this if you fully understand the implications of disabling the default behavior.

With regard to integration of LTFS into the OS, I assume you are referring to an in-kernel implementation of LTFS. In my opinion an in-kernel implementation of LTFS is very unlikely. The over-head incurred by use of FUSE and FUSE-like frameworks is negligible based on our testing of LTFS on Mac OS X, Linux, and Windows. Additionally, LTFS uses XML data structures for the filesystem meta-data. Parsing XML data in kernel-space is not a pleasant idea from a technical perspective. Given that the current user-space implementation does not suffer from performance problems or other limitations due to the user-space implementation, I do not personally see what value would be achieved by an in-kernel implementation. Particularly given the engineering complexity of performing such an implementation.
Regards,
Michael Richmond