Spanning a volume over a network or with a remote device

I have not done anything of the sort, but have a look at the website of Alex Narvey where you might get some pointers and assistance.

Leo

The advantage of such a solution is speed. Using Ethernet, you have only 1GB vs 20GB on Thunderbotl2. The flexibility and potential redundancy, for a hot standby on one of the drives, at least, is tremendous. Having that, and access to the other drives potentially to be used at will, is as good as it can get. What you gain by that is a redundant system, that could be fired up immediately if something goes wrong. What you loose, is an (presumably old), processor and some RAM.

Spanning over Ethernet? Your RW speed will drop down to slower than SATA 3, and that is more than 5 years ago! Think about it. What about the other normal network traffic? Your bottleneck will be the network.

Leo

The nearest thing I could come up with would be to have one server 'mount' the other server(s) via NFS. Then have this master server re-share the combined storage.

While this will have inferior performance it should provide a single point of entry to the combined storage.

Note: You could help things a bit performance wise by using a second Ethernet port, one for the NFS connections to the slave servers, and one for re-sharing to the client Macs.

A second approach but never done on Mac servers that I have heard of, would be to install SAMBA4, setup Active Directory and setup DFS (Distributed File System). Macs can as standard be clients to a DFS system but cannot as standard be a DFS capable server, this is something SAMBA4 can however do as well of course as 'real' Windows Servers. See https://wiki.samba.org/index.php/Distributed_File_System_(DFS)

It maybe easier to build a Linux server - even a virtualised one to run SAMBA4.

The Apple solution here is fibre channel and Xsan to coordinate the shared access, and this configuration would need to have fibre channel host-bus adapters and fibre channel storage area network storage controllers added. Without distributed coordination, corruptions will arise.

NFS and SMB can be used for serving storage, though gigabit ethernet with any of these will be much slower than SATA storage speeds, or fibre channel speeds.

If the second system is a Mac and with a compatible cable, then use Target Disk Mode.

If the second system is some other sort of box, load some open-source NAS software onto it, and configure and use it as a dedicated file server, at the rather slow gigabit Ethernet speeds. But I'd not try to use something like Core Storage to create logical volumes spanning host systems, however — that path likely ends in pain and frustration and corruptions. (I only know of one operating system that can do that reliably — RAID-1 mirroring member volumes spanning hosts via Ethernet or other connections — and OS X isn't it.)

Storm89161 wrote:

Yea, the other one isn't a mac although I can turn it into a hackintosh if that is most beneficial. But does target disk mode combine the two into a single volume?

If the two systems are both Apple Mac systems, and if the available cable connections are compatible, then Target Disk Mode turns one of the two computers involved into something that is basically an external storage enclosure, which means that Core Storage (Fusion, et al) is in play. It's all local storage.

Given it is not an Apple Mac and thus there is no OS X here, and given that there is very likely no TDM-compatible connection here and very likely no TDM mode at all in the target box, then Core Storage is not in play here, so load the box with some open-source NAS software, and serve that via SMB or NFS or maybe AFP.

Don't expect Core Storage to span local and served (remote) volumes. Not reliably, if at all.

Or extract the storage devices from the not-Mac box, and use external enclosures on the Mac, and use Core Storage — as all the disks are local.

What you are apparently envisioning here — clustering shared storage, across multiple hosts — fundamentally does not work reliably. Not without a cluster connection manager or Xsan or similar clustering software to coordinate the storage access across the hosts.

Even without the multiple-host sharing involved, one NFS disconnect or one crash underneath some sort of multi-host mapped Core Storage volume or one SMB/CIFS server going weird, and I'd expect that all bets are off for the Core Storage data scattered across the "disks" involved here.

So... Load BSD or Linux or an illumos distro — or whatever software is supported on the not-Mac box — and serve your storage from that box. Or go do what you want, blend it all together with Core Storage, and see if it works reliably. But I wouldn't expect reliability, if that's not clear.

I really have no idea what you're referring to as "span" here. It's not a term I recognize. Not in the way that you're using it, at least.

OS X has software RAID-0 (striping) and RAID-1 (mirroring) support, controllers can have additional RAID levels, and I'm aware of one operating system — not OS X — that can have software RAID-1 storage volumes configured across multiple servers, or across multiple storage controllers in the case of NAS or FC SAN storage.

If more than one host is accessing and sharing the same storage, then that access must be coordinated. Otherwise you get corruptions.

Discussions that involve violating copyrights and software EULAs are out of bounds for the forum. As somebody that's developed software commercially, I'm certainly not interested in those discussions myself, either.

Some terms, as I am using them...

I am aware of no way to "span a volume over a network" without involving some form of RAID. That is, to have one volume exist on more than one host. It is possible on a few systems to have a single RAID volume comprised of physical volumes located on multiple servers. OS X is not among those systems.

You can serve a volume remotely over a network, via SMB/CIFS, NFS or other protocols. There are many solutions to that. OS X has SMB/CIFS and AFP clients and servers integrated, among others.

You cannot serve a volume remotely or otherwise share access without some form of coordination services (usually part of the protocol that's serving the volume), as otherwise two hosts will eventually get tangled and will clobber (some of) the updates.