What explains the APFS sibling volumes architecture ( / & Data )

What are the advantages of this sibling volumes architecture?

I can't give an authoritative answer, but I can give you a general answer. Basically, there are are two main issues:

A) At a very high level, any change to the overall file system layout is inherently very risky. It would certainly simplify the overall architecture if we could consolidate EVERTYHING into two ("read only"/"read write") or (possibly) three ("RO system, RW system, RW user"), but it would also require a completely restructuring the entire system layout. That's going to break a lot of stuff and I'm not sure if justifies the benefit (particularly given #2).

B) On the technical side, there is an issue with an architecture that's based purely on symbolic links:

/                       ro
/var                    rw, nosuid, nodev

The issue here is, once multiple volumes are involved, how does the "/" volume determine what volume it'd link "target"? The obvious answer would be to use the volume name, however, that won't work because:

• The "/" volume should include NO user information AT ALL and, ideal, should minimize any kind of "configuration specific" data.

• We want the data and system volume to be strongly linked so that, for example, volume name collisions won't change the data volume of a configured system volume.

One thing to note here is both of these issues would still be there even if you completely reorganized the hierarchy to rigidly segregate data into exactly two "buckets". "How do I find these directories?" Simply chanages to "how do I find var?"

These issues are why "volume groups" were created- the volume groups connects a system and data volume with each other, so that the boot system "knows" to treat them as a matched "set". With that construct, a firmlink is basically a symbolic link that's referenced "through" the volume group, instead of solely through it's simple path.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

The "/" volume should include NO user information AT ALL and, ideal, should minimize any kind of "configuration specific" data.

This is perfectly achieved with a simple directory /var inside / volume (RO ) and a bucket of symbolinc links ( the traditionnal one ) pointing to directories inside the var volume ( RW ) mounted on /var, as exposed in my OQ.

As a concrete example, there is a need to clearly separate system applications ( RO ) and user installed applications ( RW ), this is achieved throught the use of 2 different clearly distinct directories and one preconfigured symbolic link inside / ( RO ⇒ non modifiable ):

User visible path     real path to        volume
------------------------------------------------
/Applications         /Applications       /
/local/Applications   /var/Applications   /var

And that's all folks!

Thus my OQ stands: why didn't Apple choose such a basic, simple and efficient construct with just 2 basic volumes?

Real life teach us everyday that complexity is one of the biggest enemy of performance and security.

Thus my OQ stands: why didn't Apple choose such a basic, simple and efficient construct with just 2 basic volumes?

I'll try and summarize my earlier answer.

1. The size and skill range of our user base and app ecosystem meant that any file system reorganization was going to be extremely disruptive.

2. We needed a construct that would tightly bind the system and data volume in a way that a simple symbolic link would not. The construct we created for that were firmlinks. Note, given our security and technical requirements, that construct would have been necessary even if we reorganized the file system layout.

3. Firmlinks were then used to avoid that major file system reorganization.

Note that #1 here is extremely critical. Moving directories around may be the simplest solution, but that doesn't matter if it breaks critical apps that users rely on, not to mention generating mass confusion and support calls.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware