As noted, I additionally enabled the _hfs setting in the event that I might run into problems with programs such as Photos (as indicated by the OpenZFS wiki). Sudo zfs set _hfs=on Lyon/UsersĪnd thereafter moving the Mac OS partition’s Users contents to it and setting up the appropriate mount paths. This was merely a matter of issuing: sudo zfs create 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. With this in place, I switched back to Linux and confirmed that it had R/W access to the same pool. This would not do, so I issued sudo zpool destroy Lyon and recreated it on Mac OS with sudo zpool create Lyon /dev/disk0s4. 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. 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. Once this was complete, I simply issued the basic commands to setup a zpool: sudo zpool create Lyon /dev/sda4 I began first by installing and setting it up on Arch Linux, following the guide here. Having recently delved into ZFS – a filesystem I hadn’t touched since the late-aughts with Solaris – for a Debian office server, I realized that the answer to my problems could potentially be ZFS.Ī quick search revealed that the OpenZFS on OS X project had matured much since my last viewing (as I had noticed of the ZFS on Linux project some weeks prior). With this, I then thought of another project I was working on… The Solution 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. 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). 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.Īfter 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. HFS+ write access under Linux is experimental and must be enabled with the force option during mount. The ProblemĪfter the initial install of both Arch Linux and Mac OS – along with rEFInd – I was met with a potential problem. 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.įrom Linux’s perspective, the total partitions, with the important three noted, were: #īefore and after each of the Tyger, Lyon, and Lyger partitions I also placed 128MB of free space as per Apple’s recommendations. The reason for this is that I primarily do cross-platform development and would like my two preferred operating systems to be available during travel. The idea was to have three major partitions: Mac OS High Sierra, Arch Linux, and a shared partition that would store my user/home directory. Now just set your Linux user to use the same UID:GUID as Mac OS and set /etc/passwd to point to /Users/. Then presuming Linux has already been set up with ZFS on Linux: sudo zpool import -d sudo zpool cachefile=/etc/zfs/zpool.cache Mac:~ user$ sudo zfs set mountpoint=/Users /Usersĭownload and install ZFSLoadCheck, ensuring you issue sudo touch /Users/.zfsloadcheck. After installing OpenZFS on OS X: Mac:~ user$ sudo zpool create
0 Comments
Leave a Reply. |