Writable Directories for Junos OS Evolved

The various versions of software share the same disk and partitions. The run-time environment enables a clean separation of the version's private state while also enabling the sharing of common directories, such as the log files and the core files. The final run-time filesystem topology is read-only by default. The system contains two kinds of writable directories:

Shared—All software versions installed on the device use these directories. These directories hold files such as the log files and core files. For example, /var is a shared writable directory.
Private—The individual software versions own these directories. Each version gets a pristine set of these directories and files, based on packaging content, and gets the opportunity to synchronize these files with whatever is the current file version, by peeking under the /curroot directory prefix. The system creates these directories in the /data partition and uses the name of the directory, with '/' replaced by '_' (slashes replaced with underscores). These directories are bind-mounted during boot up; the files contained within the directory are specific to that software version. The private directory list differs according to the capabilities of the nodes (for example, Routing Engine or FPC) and the products (for example, PTX10003 or PTX10008).

How the System Handles Writable Directories

Shared writable directories do not need special handling during software upgrades or rollbacks, because the contents are common across software versions. During software synchronization for dual-Routing Engine systems, only the user home directories in /var/home for the current software version synchronize to the backup Routing Engine from the primary Routing Engine. No other contents of the shared writable directories synchronize.

For private writable directories, because these directories are version-specific, the directories need special handling during software upgrades, rollbacks, and synchronizations:

Software upgrades—During the post-install stage of the upgrade to a new version, the system creates a chroot environment for the new version, and the previous version mounts as /curroot. The post-install scripts of the new version merge the contents of the previous version's private directories into the new version. Therefore, any user scripts or configurations that are part of the previous version's private writable directories carry forward to the new version.
Software rollbacks when you specify the with-old-snapshot-config option on the request system software rollback command—The system does not copy over any contents of the running version's private writable directories to the rollback version's private writable directories. After reboot, the system comes up with the contents that were present at the stage when the software upgrade was done from the previous (rollback) version to the currently running version.
Software rollbacks without the with-old-snapshot-config option—During the roll back from the running version to the previous version, the system merges the contents of the running version's private writable directories with the previous version's private writable directories, similarly to what happens during a software upgrade.
Software synchronization (Dual-Routing Engine systems only)—The system synchronizes the contents of the private writable directories from the primary Routing Engine to the backup Routing Engine for the software versions, based upon the option you specify on the request system software sync command: current, rollback or all-versions. When you configure the auto-sw-sync statement at the [edit system] hierarchy level, the system synchronizes all contents of the private writable directories from the primary Routing Engine to the backup Routing Engine for all software versions.