PSA: Store iTunes media in a single ZFS filesystem

[tangent]

I've kept my iTunes media folder in a dedicated ZFS pool for years now. When an opportunity came to rebuild my pool, I thought I'd be clever and make a separate ZFS filesystem for iTunes/Movies, one for iTunes/Music, etc. I expected to get several advantages from this:

• "zfs list" would show how much space each takes; much faster than "du"!
• sanoid doesn't work on the pool root, only on ZFS filesystems. I wanted to use it as a replacement for my hand-rolled snapshotting script.
• I could have separate ZFS settings for each filesystem, such as a smaller block size on the Music filesystem than for the Movies filesystem.
• Eventually, when disks become large enough to let me store more than just iTunes in this pool, I'd like to enable compression on the other filesystems; I have compression off on the iTunes pool for obvious reasons.

Unfortunately, iTunes failed badly when given this structure, even though from a pure POSIX standpoint, it's identical to the old scheme. Apparently iTunes is doing some kind of filesystem or mount point aware path parsing, so a bunch of things fail when you do this. Rather than list the problems, I'll just leave you with this simple advice: store all iTunes media in a single ZFS filesystem.

[leeb]

I have separate file systems for every "folder" in my user home folder and nothing on root, which I think is good enough, I don't think messing with block size is going to grant any significant advantages unless you have some specific reason to the contrary? Custom for ~/Music (which is where the iTunes folder lives) seems like enough and iTunes has no issue with that. My schema right now is roughly:

Code: Select all

zpool1(SSD):
/zpool1 (nomount)
/zpool1/Users (nomount, for organization)
/zpool1/Users/user1 (nomount, also for organization)
/zpool1/Users/user1/HOME (the home folder root stuff itself, dotfiles and remaining empty mount point folders)
/zpool1/Users/user1/Applications|Desktop|Documents|git|Library|Projects|etc (the smaller stuff that I want to run fastest)

zpool2(HDD): (same overall org)
/zpool2/Users/user1/Music|Movies|Software|etc (big stuff that is most sequential access patterns, any working project media can go to Projects)

I then user overlay mounting to make it all have a structure that looks like a normal home folder. There are other various FS beyond users of course, shadow backups and system stuff and VMs and so on. This is roughly how I ran Z410/ZEVO for years, though not exactly because 10.8 had some odd quirks that couldn't be ironed out before the project died. Under 10.13 though this mostly seems to work pretty well, beyond Spotlight recently going insane (but it was fine before the last upgrade).

I do not use iTunes for movies in general, mainly music, so I haven't directly experimented there. I keep all my Movies in ~/Movies. However you might try setting up custom ZFS FS as you wish and then see if iTunes will work with symlinks instead. Back in the day I got around bugs in the Finder using a symlink for Desktop for example (so I made a FS called user1/Desktop.user1, then symlinked that to ~/Desktop).

A few other quick replies:

sanoid doesn't work on the pool root, only on ZFS filesystems. I wanted to use it as a replacement for my hand-rolled snapshotting script.

Haven't used that yet, but there shouldn't be any need to have anything in the pool root at all. At worst you could at least stick your home folder in a hierarchy.

Eventually, when disks become large enough to let me store more than just iTunes in this pool, I'd like to enable compression on the other filesystems; I have compression off on the iTunes pool for obvious reasons.

FWIW on modern compression: in the old days yeah, you really wanted different compression settings for media vs compressible stuff because a significant hit was incurred. However with LZ4 that really is a ton better, it's good at recognizing non-compressibles and not getting bogged down and it's very fast. With ZEVO I had differing compression per FS, but after moving to O3X (and well before that under FreeBSD) I just used lz4 as the algorithm and defaulted it to on everywhere unless I had a very specific tested reason otherwise, and I haven't seen any noticeable speed issues even on media FS.