Physical storage media are nothing more than very large blocks of raw bytes.
The presence of directories and files on them is merely a way of organising these bytes into data structures that reference one another and the data blocks making up the files.
This organisation into directories and files constitutes a file system.

Start a virtual machine with s7nsa_machine.py A.
When the system starts, it sets up a root file system designated by /; this is referred to as mounting the file system.
Display the contents of /etc/fstab to observe that the file system designated by LABEL=ROOT does indeed correspond to the root /.
The command ll /dev/disk/by-label shows that the file system with the label ROOT✍ is simply the /dev/sda1 device.

Beyond directories and files✍, a file system can also be used to mount other file systems onto some of these directories.
Observe in /etc/fstab that the /tmp directory of the root file system is used to mount a virtual tmpfs file system. There is no physical storage medium, it is purely software-based, the data stored in tmpfs remains in memory and disappears upon reboot.
The mount command shows that many other virtual file systems are mounted by various services during startup.

Display the contents of the root directory with ll /.
Observe that some entries are links to other paths; for example, /bin is simply /usr/bin.

These directories are organised according to the FHS convention.
Among them, the most commonly used are:

List the contents of some of these directories.

It is very common to need to search for files within the directory tree.
For example, try the command find / -name 'ssh*config'.
Of course, if you have a rough idea of the location, you can narrow the search vith find /etc -name 'ssh*config'.

It can also be useful to search for files based on the information they contain.
For example, try the command grep -Fir deny /etc.
Using extended regular expressions✍ allows for more advanced searches, such as grep -Eir '^#\s?(permit|allow|deny)'✍.

A common search pattern concerns the size occupied by files and directories.
It is also very common to be interested in the size occupied by files or directories.
For example, try the command du -ms /usr/share/*; you will see that each path is preceded by its size in megabytes.
The list is very long, making it difficult to spot the largest items.
The command du -ms /usr/share/* | sort -n | tail -20 sorts this list numerically and displays only the last few lines.
If you want to search for the largest files within a directory tree, you can proceed as follows:

It is also quite common to focus searches on the date.
For example, try the commands ll -t /etc | head and ll -t | tail and observe the displayed dates.
To search within a chosen directory for items modified more recently than a certain number of minutes, you can use find /etc -mmin -180.
And to search for items older than a specific date, you can use find /etc ! -newermt '2025-06-01'.

In the previous tutorial, you observed that the virtual machines had been set up with a disk containing their operating system.
In addition to this, prepare an extra disk✍ on the host system that will be used by your virtual machine: qemu-img create -f qcow2 A_sdb.img 40M.
When you start the virtual machine with s7nsa_machine.py A, you will notice that the disks A_sda.img and A_sdb.img are now recognised.

Use the commands lsblk and fdisk -l and interpret their results.
These storage devices are recognised by the system but are not necessarily in use.
The mount command shows the hardware or software storage devices currently in use; try to identify those that correspond to the storage devices recognised earlier.
The list is very long due to software devices; it is therefore useful to filter it with mount | grep -E '^/dev/'.
You should notice that only the sda1 partition is mounted on /; this is the root file system.
The sda disk has been divided into two partitions, but the second one is not yet mounted in the file system.
The sdb disk is not used by the system at all.

After creating a new directory /mnt/data, use the command mount /dev/sda2 /mnt/data to mount the sda2 partition on this mount point; then check again with mount.
Check the usage of the available storage space on these partitions with df -h /dev/sda1 /dev/sda2.
Copy the file /boot/initramfs-linux.img to /mnt/data/file1; check the available space with df.
Repeat in the same way to create file2 and check the available space.
Repeat again to create file3 and check the available space; observe the failure and the exhaustion of space.
Check the space used by these files and this directory with du -hs /mnt/data/file* /mnt/data.

Unmount the sda2 partition with umount /mnt/data and observe that the /mnt/data directory is empty again.
Edit the file /etc/fstab to add this line: /dev/sda2 /mnt/data ext4 rw,relatime 0 0.
This file lists the known partitions and mount points; unless otherwise specified, these mounts occur automatically at system startup.
You can either reboot the system or simply use mount -a to automatically mount what is indicated in this file.
Observe that /mnt/data now contains again the content we previously placed there.

The sdb disk is merely a long sequence of raw bytes, with no form of organisation whatsoever; it therefore cannot directly store files organised into directories.
Although this is not strictly mandatory, it is common practice to divide it into multiple partitions.
Here, a single partition will be created using this command✍: echo -e 'label: dos\nstart=2048, size=-, type=83' | sfdisk -q /dev/sdb.
Check with lsblk and fdisk -l that this new partition of type “83-Linux” indeed exists.
However, the sdb1 partition still remains a long sequence of raw bytes with no form of organisation whatsoever.
Prepare an ext4 file system✍ on this partition: mkfs.ext4 -Fm0 /dev/sdb1.
Now that the sdb1 partition is organised as a file system, create a mount point /mnt/data2 and mount this partition there.

Use the new storage /mnt/data2 by copying files to it, as was done with /mnt/data.
Note that, even if we have successfully increased the storage capacity with a new partition, the various partitions must be associated with separate mount points.
It is therefore necessary to choose whether a file should be placed in /mnt/data or /mnt/data2.

The previous remark highlighted the fact that extending storage capacity by adding new disks and partitions leads to treating these storage spaces as separate directories.
However, it may be useful to have a single directory whose capacity can be extended as required; this is the purpose of logical volume management.
It involves aggregating the storage capacity of multiple physical volumes into just a few logical volumes that use them to appear as larger storage volumes.

Unmount the sda2 partition with umount /mnt/data, then change its type (previously “83-Linux”) to “8e-Linux LVM” with sfdisk -q --part-type /dev/sda 2 0x8e.
Enable logical volume management with vgchange -ay.
Check with pvs that no physical volume is declared, then declare this physical volume with pvcreate -f /dev/sda2 and check again with pvs.

To be used, physical volumes must belong to a volume group.
Check with vgs that no volume group exists, then create a vg_data volume group containing sda2 with vgcreate vg_data /dev/sda2 and check again with vgs and pvs.

A volume group is able to use the physical volumes it consists of in order to allocate storage to logical volumes.
Check with lvs that no logical volume exists, then create a lv_data logical volume in vg_data with lvcreate -n lv_data -l 100%FREE vg_data and check again with lvs, vgs and pvs.
You should observe that all the available space in vg_data, and therefore in sda2, has been used to create lv_data.

The newly created lv_data volume can then be formatted with mkfs.ext4 -Fm0 /dev/vg_data/lv_data.
You can now mount /dev/vg_data/lv_data on /mnt/data.
Resume copying /boot/initramfs-linux.img to /mnt/data/file1, /mnt/data/file2, and so on until the volume is full; check with df.
Edit the /etc/fstab file and replace /dev/sda2 with /dev/vg_data/lv_data for the /mnt/data mount point; reboot the system to verify that this volume is properly mounted at startup.
As it stands, the situation is no different from mounting sda2 directly, but logical volumes will make it possible to go beyond this.

Unmount the /dev/sdb1 partition, then change its type (previously “83-Linux”) to “8e-Linux LVM” with sfdisk -q --part-type /dev/sdb 1 0x8e.
Declare this new physical volume with pvcreate -f /dev/sdb1 and check with pvs.

Add this new physical volume to the existing volume group with vgextend vg_data /dev/sdb1; check with vgs and pvs.
You should observe that vg_data now contains free space provided by sdb1.

Extend the logical volume lv_data so that it uses this space with lvextend -l +100%FREE /dev/vg_data/lv_data; check with lvs and vgs.
However, df appears to ignore this additional space for lv_data; this is because the extra bytes are not taken into account by the initial formatting.
You must then instruct the filesystem to adapt its layout to the new available space in the volume it contains using resize2fs /dev/vg_data/lv_data; check again with df.
Continue filling /mnt/data with copies of /boot/initramfs-linux.img in order to observe the newly available space.

It is also possible to combine multiple physical storage devices to reduce the risk of data loss through redundancy.
RAID 1 is the simplest variant presented here, but RAID offers other ways of aggregating disks.

Start by undoing everything done in the previous step: then check with df, lvs, vgs, and pvs that nothing remains.

Change the type of the sda2 and sdb1 partitions (previously “8e-Linux LVM”) to “fd-Linux raid autodetect” with sfdisk -q --part-type /dev/sda 2 0xfd and sfdisk -q --part-type /dev/sdb 1 0xfd.

Create the RAID 1 volume from these two partitions with mdadm -C -e0 -b none -l1 -n2 /dev/md0 /dev/sda2 /dev/sdb1.
Check the RAID status with cat /proc/mdstat and mdadm -D /dev/md0.
Ensure this volume is automatically recreated at boot by running mdadm -D -s >/etc/mdadm.conf.

The newly created md0 volume can then be formatted with mkfs.ext4 -Fm0 /dev/md0.
You can now mount /dev/md0 on /mnt/data.
Copy some files into /mnt/data and check with df.
Edit the /etc/fstab file and replace /dev/vg_data/lv_data with /dev/md0 for the /mnt/data mount point; reboot the system to verify that this volume is properly mounted at startup.
As it stands, the situation is no different from mounting sda2 or sdb1 directly, but RAID 1 will reduce the risk of data loss.

Simulate a temporary failure on sda2 with mdadm -f /dev/md0 /dev/sda2.
Check the RAID volume status with cat /proc/mdstat and mdadm -D /dev/md0; you will see that the sda2 partition is faulty and therefore unusable.
Remove it from the RAID volume with mdadm -r /dev/md0 /dev/sda2 and check again to verify that only sdb1 remains.
Verify that the files are still present in /mnt/data.
Reintroduce sda2 with mdadm -a /dev/md0 /dev/sda2 and check the RAID volume status again; everything should be back to normal.

Now shut down the virtual machine with poweroff.
On the host system, delete the file A_sdb.img to simulate its failure.
Restart the virtual machine with s7nsa_machine.py A; note that at reboot the system takes some time trying to recreate the RAID volume.
Check the RAID volume status with cat /proc/mdstat and mdadm -D /dev/md0; observe that it is degraded since only the sda2 partition is present.
Verify that the files are still present in /mnt/data.

Without shutting down the virtual machine, prepare a new extra disk✍ on the host system that will be used by your virtual machine: qemu-img create -f qcow2 A_sdb.img 40M.
In the “View” menu of the QEMU window, choose the “compatmonitor0” tab.
At the (qemu) prompt, enter the following commands✍: This has nothing to do with the guest system; it simply tells the QEMU emulation software that the A_sdb.img disk has just been connected to the virtual machine.
Return to the guest system display with “View/VGA”.

Check with lsblk for the presence of a new disk named vda.
Create a vda1 partition of type “fd-Linux raid autodetect” with echo -e 'label: dos\nstart=2048, size=-, type=fd' | sfdisk -q /dev/vda.
Add this partition to the existing RAID volume with mdadm -a /dev/md0 /dev/vda1.
Check the RAID volume status with cat /proc/mdstat and mdadm -D /dev/md0; you will see that the sda2 and vda1 partitions are now synchronized.
As expected, the files are still present in /mnt/data.

You have just verified that in a RAID 1 volume, either of the two constituent partitions can fail and then be replaced without data loss.
Of course, you must not lose both partitions simultaneously!