ltfs VS osxfuse

Hi, What is the LTFS 'driver' you use for this? Some LTFS version provide a mode for supporting the buggy HBA. This helps time to time with some. It can be worst to try . Here is one version of LTFS i can recommend to use, and a link to an explanation about the Buggy HBA mode: https://github.com/LinearTapeFileSystem/ltfs/wiki/HBA-info And link to issue of user having potential similar problem https://github.com/LinearTapeFileSystem/ltfs/issues/144

I think IBM are actually the ones writing the reference implementation that HP and everyone else are basing their LTFS drivers on, so the compatibility list includes more than just IBM drives. In a production environment you'll probably be using the vendor software in any case. But I built the reference implementation on my home machine previously and it worked fine. https://github.com/LinearTapeFileSystem/ltfs

There is also a fair amount of energy going into the reference ltfs implementation, which I’ve yet to try properly: https://github.com/LinearTapeFileSystem/ltfs I suspect using this version would be a good idea in the long term.

Is LTFS (including "mkltfs") on any repo? Is CentOS 6 still supported? The IBM docs suggest RHEL6 was supported. I found an LTFS GitHub, but of course it says CentOS 7+ is needed. It doesn't show support for newer Linux releases, though (CentOS9/RHEL9, Ubuntu 20/22, Debian 10/11, etc.), so I'm not sure if there is a better source for LTFS.

I recently purchased a LTO-5 drive for my Gentoo-based NAS and have a few key takeaways for those who are interested. Don't buy a HP tape drive if you want to use LTFS on Linux! HPE Library & Tape Tools is prety much dead on modern Linux. Official support is only for RHE 7.x and a few versions of Suse. Building from source is a dependency nightmare that will leave you pulling hair. IBM drives have much better Linux support thanks to https://github.com/LinearTapeFileSystem/ltfs. That being said, IMO, you should consider ditching LTFS for good ol' TAR! It's been battle tested since 1979 and can be installed on basically anything. TAR is easy to use, well documented, and makes way more sense for linear filesystems. While drag&drop is nice and all, it really does not make sense for linear storage.

Looks fairly active to me

Install macFUSE, thank me later: https://osxfuse.github.io

I didn't exactly use any 'tutorial'. Assumming you can already SSH to the target machine, you just need to install both these pkgs then reboot to 1TR Recovery Mode and choosing Reduced Security and choose to enable Kernel Extension and then reboot again goto Security & Privacy and Allow the extension, and that's it you can now use it.

Yeah, FUSE is Linux only. But for completeness, for macs there is macFUSE, and for Windows there is winfsp. Both of these have fewer filesystems than FUSE, and I've used neither so I don't know how well they work.

https://github.com/osxfuse/osxfuse/wiki/List-of-macFUSE-File...

https://winfsp.dev/doc/Known-File-Systems/

Weird. Where did you download (lat/new)est MacFuse from? https://osxfuse.github.io/ I hope!

I lead a project that included shipping a filesystem driver and a virtual disk on Windows.

What I did to learn the lower-level APIs, and perform initial testing on the driver, was write a "mirror" drive. The user-mode code pointed to a folder on disk, the driver made a virtual disk drive, and all reads and writes in the virtual disk drive went to the mirror folder.

On Windows, you can implement something like that using Dokany, Dokan, or Winfsp. On linux, there's the Fuse API. On Mac, there's MacFUSE.

Even if you don't do a "mirror" drive, understanding the callbacks that libraries like Dokany, Dokan, Winfsp, and Fuse do helps you understand how IO happens in the driver. Many IO methods provided in popular languages provide abstractions above what the OS does. (For example, the Windows kernel has no concept of the "Stream" that's in your C# program. The "Stream"'s Position property is purely a construct within the .Net framework.)

https://dokan-dev.github.io/

https://github.com/dokan-dev/dokany

https://osxfuse.github.io/

Another place to start is the OS's documentation itself. For example, you can start with Window's CreateFileA function. This typically is what gets called "under the hood" in most programming languages when you open or create a file: https://learn.microsoft.com/en-us/windows/win32/api/fileapi/...

"FUSE-T is a kext-less implementation of FUSE for macOS that uses NFS v4 local server instead of a kernel extension. The main motivation for this project is to replace macfuse (https://osxfuse.github.io/) that implements its own kext to make fuse work. With each version of macOS it's getting harder and harder to load kernel extensions. Apple strongly discourages it and, for this reason, software distributions that include macfuse are very difficult to install. Additionally, the macfuse kext is unstable, may cause frequent system crashes and kernel lock-ups. Given those limitations many software publishers are unable to use macfuse anymore. FUSE-T doesn't make use of kernel extension, it implements its own userspace server that converts between FUSE protocol and NFS calls and let macOS mount NFS volume instead of a kernel filesystem."

MacFuse (ntfs-3g) and a Foolproof way of getting it working via Homebrew.

macos doesn’t support many Linux file system formats. You’ll have to use something like macFUSE https://osxfuse.github.io/