Has anybody tried hfsfuse to mount HFS+ disks on FreeNAS?

[volothamp]

I found some old thread regarding HFS+ but this seems pretty new, I was wondering if somebody compiled it on FreeNAS/TrueNAS

GitHub - 0x09/hfsfuse: FUSE driver for HFS+ filesystems

FUSE driver for HFS+ filesystems. Contribute to 0x09/hfsfuse development by creating an account on GitHub.

github.com

https://www.freebsdnews.com/2018/03/23/read-hfs-filesystem-freebsd/

 

[sretalla]

Unlikely... What's your intended use case?

FreeNAS/TrueNAS is a product that focuses on ZFS, there are a few scenarios (UFS, NTFS, Extfs2, FAT) where non-ZFS disks can be "imported" and hence temporarily mounted for the purposes of copying, but that's not any kind of indication that those disks can/should be used without re-formatting into ZFS once the import is complete.

 

[volothamp]

Unlikely... What's your intended use case?

FreeNAS/TrueNAS is a product that focuses on ZFS, there are a few scenarios (UFS, NTFS, Extfs2, FAT) where non-ZFS disks can be "imported" and hence temporarily mounted for the purposes of copying, but that's not any kind of indication that those disks can/should be used without re-formatting into ZFS once the import is complete.

Exactly this.

I need to migrate my data from my Mac Workstation internal drive to my FreeNAS pool but I rather do it internally rather than using SMB and mount the drive with some cheap USB enclsoure.

This solution would be used once and it's also read-only so it seems perfect for my use case. I mount the old HD, rsync the data on the new ZFS pool, unmount and then reformat the old HD or keep it for archival

 

[sretalla]

You would spend less time and trouble copying the data to an NTFS disk on the Mac.

 

[Constantin]

I did it via AFP and I’d suggest so do you. It’s straightforward (I use carbon copy cloner from Bombich) and can approach the speed of a hard drive depending on the rig you have.

While AFP is deprecated, OSX still supports it natively. Unlike OSX’s SMB, you won’t experience issues with names getting mangled, file paths being too long, etc. which are all issues that Apples SMB implementation continues to suffer from.

Officially, SMB supports very long file paths (allowing for some hope re: better future OSX SMB performance) but the file name character diversity limitations are likely more permanent. This is also why I continue to use AFP as my main protocol on this server. It just works - the files, folder names etc. appear at the ZFS file system level just as they do on the Mac.

Also consider creating disk images or sparse bundles of some content, such as old CPU System folder backups. There are literally hundreds of thousands of tiny files in OSX’s System folder now, which is very inefficient to transfer via rsync. Moreover, to take advantage of special VDEVs (small file variety in this case) the number of small files you don’t use very often should be minimized.

 

[volothamp]

You would spend less time and trouble copying the data to an NTFS disk on the Mac.

I like this idea, I basically clone my internal HD to an identical NTFS formatted drive, and then mount it on FreeNAS as it's supported. Thanks

 

[volothamp]

I did it via AFP and I’d suggest so do you. It’s straightforward (I use carbon copy cloner from Bombich) and can approach the speed of a hard drive depending on the rig you have.

Thanks for the suggestion, but AFP is a sharing protocol right? So except for the SMB details I still need to have two machines powered and connected via ethernet, I was trying to do do a local sync instead.

Does CCC support cloning an HD throughout AFP? I think I still have a license for SuperDuper that should do the same thing

 

[Constantin]

Yes. I mount the ZFS volume, then set whatever sub directory as a target, set your HDD as a source and off you go. I’m still running Mojave here so I cannot speak to the inclusion of AFP in Big Sur or Catalina.

CCC does a decent job of verifying writes as far as I can tell. It will be slow for small files, both reading and writing. Images and sparse bundles help here because they present fewer, larger chunks to the file system to copy.