2

I (also) use external hard drives for backup. For full backups I attach them directly via USB to a Mac, but most of the time they are attached (still USB)to a Linux (Raspberry Pi) server, where I can access the files or use rsync for incremental backups.

That means I need fast, native access from Mac, and relatively fast access from Linux.

Once in 2-3 years I have to access things from Windows, and Samba is definitely good enough for that.

I've also noticed speed issues with the fuse-supported NTFS on Linux.

Was that just my perception?

and are there substantal counter-arguments to using HFS+ in these circumstances?

or would I be better off with NTFS?

1
  • 1
    If you're accessing the disk through a server with Samba, then the disk format is irrelevant. Jan 8, 2019 at 18:34

1 Answer 1

1

HFS+ support on Linux is mediocre at best. In theory, it's supported, but filesystem checking is essentially nonexistent without a lot of manual work, and it has issues sometimes if the filesystem was not cleanly shut down. Performance is also not particularly great, and the driver is not widely used with means it's more likely to have undiscovered bugs. I'm not sure how well it's supported on Windows as I've never dealt with it there.

Given all of this, I'd say that it's probably not a great choice unless you can 100% guarantee that the hardware will never have issues that cause the filesystem to have errors.


NTFS has it's own issues for this type of thing. On Linux, you essentially need FUSE for it, and it's not natively supported by macOS. I've not tried it on macOS, but the Linux FUSE module isn't horrible if you're dealing with a fast storage device (I use it without significant performance problems on an SSD, though I would be hesitant to use it on rotational media or a flash drive). Given that Windows support is not a high priority for you, I would look elsewhere.


This leaves a handful of other options, many of which are at best mediocre:

  • FAT32: Natively supported on both macOS and Linux, performance is decent as long as you're just doing writes of whole files at once and not doing in-place file updates, and it's trivially usable from Windows too. The big downside here is that it has a really low limit on file size compared to most other filesystems. Most well designed backup software can handle this fact without issue though (because it will archive everything to a single file, and can then split that across multiple smaller files to stay under the file size limit), or you can bump up the cluster size when creating the filesystem to increase the max file size at the expense of higher potential for wasted space. It also doesn't preserve most UNIX attributes, though you can work around this by using archive files instead of flat file copies.
  • UDF: This is the filesystem format used on DVD's. It also happens to have support for more conventional block storage devices like hard disks, and it's natively supported on both Linux and macOS. Performance is decent but not amazing. Just like FAT32, it doesn't preserve most UNIX attributes, and you can work around this in the same way. There's also an issue in that the Linux driver is a bit buggy, and Linux has almost no filesystem recovery options for UDF.
  • UFS: Limited native support on both macOS and Linux, both with decent performance for typical backup workloads. Tools for working with it form userspace are somewhat limited in both cases, and it's somewhat expected that support may be going away on macOS in the near future (if it hasn't already been removed in the most recent macOS version).
  • ext2: Native support and great performance on Linux, needs special drivers on macOS but gets decent performance. This is probably your best bet if you're usually using the disk from Linux, as it gets you proper filesystem recovery support on the system you will use it on most of the time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.