We mentioned earlier that system D, mounts the filesystems divined in the fstab file. Let's see what's in this file, so the F stab all the filesystems table file, typically lists all available disk partitions, and other types of file systems. And data sources that are not necessarily disk based, and indicates how they are to be initialized, or otherwise integrated into the larger file system structure. This file mounts the file systems, that are present in it automatically during boot time. There are six fields per line of this file, an example F stabs files content search shown here. The first field is the file system specifier, this is the device which can be referenced using its /dev location, or by its unique identifier. The second field is the Mount Point, this is the location at which the mounted device, should be accessible. In our example, the root file system shows as mounted under the /directory, and the swap file system is mounted under swap. Swap in Linux is the area on disk that's used as ram, if the system runs out of space in the real ram. The third field is the file system type, you can expect to see common file system types like AX3 or AXT4 or XFS. XFS is the default file system, for Red Hat Enterprise Linux Seven, it supports metadata journaling, which facilitates quicker crash recovery. The 4th field is Mount options, this could contain values like defaults as we see here in our example, and other values like auto, no auto, exec and so on. Defaults as the name indicates, mounts a file system with the default settings. The auto option will mount the file system, automatically at boot, or when you use the amount minus a command. The no auto option will mount the file system, only if you tell it to. There are many such options, which you can specify depending on what you'd like to do. The field is dump frequency, this is used by the dump utility to decide, when to make a backup. When installed, dump checks the entry an uses the number to decide, if they file system should be backed up. Possible entries are 0 and 1, if 0 double ignore the file system, if 1 don't will make a backup. The 6th field is file system check order, file system check or FSCK, reads the number specified here to read the order. The file system should be checked, possible entries here are 0, 1 and 2. The root file system, should have the highest priority 1, and all other file systems. Should you want to have them checked, should get a two file systems with a path value 0, will not be checked by the FSCK utility. Now, let's identify a few important control directories in Linux. First, let's look at the difference between /user, /lib, /systemd and /etc, /systemd, /system. The files that shipping packages downloaded from the distribution repository, go into /user, /lib, /systemd. Modifications done by a System Administrator, go into /etc, /systemd, /system. You can also override the unit supplied by vendor, here we see the contents of these /etc, /systemd, /system directory. As we previously discussed, this directory contains unit files created by systemctl enable, as well as unit files added for extending a service. This directory takes presidence, over the directory with runtime unit files that is, /run, /systemd, /system. You may be wondering about the .once string appended, to several of these directories. In the unit configuration file, if a specific unit is wanted by another unit, that is a dependency. A directory will be created within /etc, /systemd, /system, named after the specified unit with .once appended to the end. Within this a symbolic link to the current unit will be created, creating the dependencies. So for example, if the current unit has wanted by equals .bluetooth.target. A directory called bluetooth.target.once, will be created within /etc, /systemd, /system. If not already available, and a symbolic link to the current unit will be placed within. Now, here we see the whole boot process visualized. You can see an overview of the various targets, that get run when your system starts up. To do this, run these systemd minus analyze critical minus chain command. Let's go through an overview of this process, so as you may remember, systemd is capable of parallel executions, so many of these tasks may run in parallel. Here, we attempt to give you an overview of the kinds of tasks, that may occur during startup. We've covered the first two steps already, let's have a quick digression here, to introduce the term PRep. Power PC reference platform, PRep is a standard system architecture for power CPC based systems. It's developed by IBM, and allows the system to run multiple operating systems. After this, the first target that gets loaded, is default.target, which is a symlink to graphical.target. Notice, that the multi-user.target, must be reached before the graphical target dependencies can be met. Multi-user.target is the alternative for run level three, insiste in it. This target is nothing, but a group of demons that need to be started, in order to configure this as a multiuser server operating system. Then we have the basic.target unit, this is a group of demons responsible for starting the usual services, especially graphical manager service. It uses the basic.target.once directory to decide, which services need to be started, then it passes control to the sysinit.target. Then the sysniti.target is reached, when all the units on which it depends are completed. All of those units, mounting filesystems, setting up swap files, starting udev, setting the random generator seed, initiating low level services, an setting up cryptography services if one or more file systems are encrypted. Well, all of that must be completed, but within these system in its .target, those tasks can be performed all in parallel. The system in it .target, and basic target.targets, can be considered as checkpoints in the startup process. Although systemd has one of its design goals, to start system services in parallel, there are still certain services, and functional targets, that must be started before other services, and targets can be started. These checkpoints cannot be passed, until all of the services, and targets required by that checkpoint are fulfilled. The sysinit.target sets up or the low level services, and units required for the system to be marginally functional. And that are required to enable moving onto the basic.target. After the sysinit.target is fulfilled, systemd next starts the basic.target, starting all of the units required to fulfill it. The basic target provides some additional functionality, by starting units that are required for the next target. These include setting up things like path, to various executable directory's communication sockets, an timers. We also have the local fs .target, which handles low level services such as adding dependencies to all mount units. It performs actions on the basis of the /etc, /fstab and /etc and /syinit tab files.
