Wow, more ZFS stuff
parent
4ec611cf8c
commit
a491ae81d1
|
@ -1,11 +1,11 @@
|
|||
[[toc]]
|
||||
|
||||
## Preface
|
||||
# Preface
|
||||
Having had some failed system updates on my MacBook Pro5,5 that caused Mac OS to be nigh unusable, I decided to swap out the original 500GB HDD for a much smaller -- but much faster -- 128GB SSD I had on hand.
|
||||
|
||||
Although this is certainly a size constraint, I keep majority of my large data elsewhere and can easily access them via remote sharing or various web interfaces, so it is a moot point.
|
||||
|
||||
## The Notion
|
||||
# The Notion
|
||||
The original idea was to have three major partitions: Mac OS High Sierra, Arch Linux, and a shared partition that would store my user/home directory. The initial setup and install -- which took some time due to learning how to setup rEFInd and much fury at the more modern Disk Utility.app's insane pie chart partitioning system -- used HFS+ for High Sierra, Ext4 for Arch, and HFS+ for the shared partition.
|
||||
|
||||
The total partitions, with the important self-made ones noted, were:
|
||||
|
@ -20,25 +20,30 @@ The total partitions, with the important self-made ones noted, were:
|
|||
|
||||
Before and after each of the Tyger, Lyon, and Lyger partitions I also placed 128MB of free space as per Apple's recommendations.
|
||||
|
||||
## The Problem
|
||||
# The Problem
|
||||
After the initial install of both Arch Linux and Mac OS -- along with rEFInd -- I was met with a potential problem. HFS+ write access under Linux is experimental and must be enabled with the force option during mount. Although I was uncertain as to what potential issues could arise from forcing R/W HFS+ access, as it seemed to work during initial tests, I did not feel comfortable with keeping HFS+ as the shared partition in the event of file loss or corruption.
|
||||
|
||||
After an initial review of the potentially shared options of NTFS, HFS+ R/W or using EXT4 via FUSE on Mac OS, I came to the conclusion that none of these were very good options. In the case of HFS+, it was uncertain what extended use would lead to, and in the case of EXT4, the only reliable EXT3/EXT4 R/W "driver" came at a bit of a cost (not much, by any means). NTFS was denied on the principle of it -- if I was triple booting, NTFS might have been the choice, although permission incompatibility would probably deny the shared user directory design.
|
||||
|
||||
With this, I then thought of another project I was working on...
|
||||
|
||||
## The Solution
|
||||
# The Solution
|
||||
Having recently delved into ZFS -- a filesystem I hadn't touched since late-2000s with Solaris -- for a Debian office server, I realized that the answer to my problems could potentially be **ZFS**.
|
||||
|
||||
A quick search revealed that the [OpenZFS on OS X](https://openzfsonosx.org) project had matured much since my last viewing (as I had noticed of the [ZFS on Linux](https://zfsonlinux.org) project some weeks prior).
|
||||
|
||||
I began first by installing and setting it up on Arch Linux, following the guide [here](https://wiki.archlinux.org/index.php/ZFS). Once this was complete, I simply issued the basic commands to setup a zpool:
|
||||
|
||||
sudo zpool create Lyon /dev/sda5
|
||||
sudo zpool create Lyon /dev/sda4
|
||||
|
||||
With this, the zpool *Lyon* was created, allowing me to copy over my home directory and begin using it by setting my entry in `/etc/passwd` to point to the appropriate Lyon zfs volume. I rebooted into Mac OS and issued the standard `sudo zpool import` and discovered that the Linux-made ZFS pool had setup an extended Linux-centric option that rendered it only able to mounted as read-only in Mac OS. This would not do, so I issued `sudo zpool destroy Lyon` and recreated it on Mac OS. With this in place, I switched back to Linux and confirmed that it had R/W access to the same pool.
|
||||
With this, the zpool *Lyon* was created, allowing me to copy over my home directory and begin using it by setting my entry in `/etc/passwd` to point to the appropriate Lyon zfs volume. I rebooted into Mac OS and issued the standard `sudo zpool import` and discovered that the Linux-made ZFS pool had setup an extended Linux-centric option that rendered it only able to mounted as read-only in Mac OS. This would not do, so I issued `sudo zpool destroy Lyon` and recreated it on Mac OS with `sudo zpool create Lyon /dev/disk0s4`. With this in place, I switched back to Linux and confirmed that it had R/W access to the same pool.
|
||||
|
||||
With the zpool working and visible between both, I decided to set up a generic *Users* volume within the *Lyon* zpool in the event of adding additional volumes or otherwise. This was merely a matter of issuing `zfs create Lyon/Users`, moving the Mac OS partition's *Users* contents to it, and setting up the appropriate mount paths. I additionally enabled the *com.apple.mimic_hfs* setting in the event that I might run into problems otherwise: `sudo zfs set com.apple.mimic_hfs=on Lyon/Users`.
|
||||
With the zpool working and visible between both, I decided to set up a generic *Users* volume within the *Lyon* zpool in the event of adding additional volumes or otherwise. This was merely a matter of issuing:
|
||||
|
||||
sudo zfs create Lyon/Users
|
||||
sudo zfs set com.apple.mimic_hfs=on Lyon/Users
|
||||
|
||||
and thereafter moving the Mac OS partition's *Users* contents to it and setting up the appropriate mount paths. As noted, I additionally enabled the *com.apple.mimic_hfs* setting in the event that I might run into problems with programs such as Photos (as indicated by the OpenZFS wiki).
|
||||
|
||||
On Mac OS, I backed up the root */Users* directory, deleted the original, issued `zfs set mountpoint=/Users Lyon/Users`, then moved the original */Users/* contents into the mounted share.
|
||||
|
||||
|
@ -46,12 +51,12 @@ On Linux, I logged in as root, simply used the same */Users/* mount point and se
|
|||
|
||||
With all this in place -- and omitting some some minor mistakes along the way -- I safely rebooted back to Mac OS. However, upon attempting to login, it seemed the ZFS filesystem *Lyon/Users* was not automatically mounting on boot. To solve this -- and perhaps this is the wrong way to go about automounting ZFS -- I created two files responsible for mounting *Lyon/Users* on boot:
|
||||
|
||||
### /usr/sbin/mount-Lyon
|
||||
#### /usr/sbin/mount-Lyon
|
||||
|
||||
#!/bin/bash
|
||||
zfs mount Lyon/Users
|
||||
|
||||
### /System/Library/LaunchDaemons/net.kettek.Lyon.plist
|
||||
#### /System/Library/LaunchDaemons/net.kettek.Lyon.plist
|
||||
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple$
|
||||
|
|
Loading…
Reference in New Issue