Chapter 17: Data Synchronization...........................................
Synchronization between memory/cache and backing store is split into two conceptually different parts:
❑ Policyroutines controlwhendata are exchanged. System administrators can set various parame-
ters to help the kernel decide when to exchange data as a function of system load.
❑ The technical implementation deals with the hardware-related details of synchronization
between cache and backing store and ensures thatthe instructions issued by the policy routines
are carried out.
Synchronizationandswappingmust not be confused with each other. Whereas
synchronizationsimply aligns the data held in RAM and in the backing store,
swappingresults in the flushing of data from RAM to free space for higher-priority
items. Before data are cleared from RAM, they are synchronized with the data in the
associated backing store.
The mechanisms for flushing data are triggered for different reasons and at different times:
❑ Periodic kernel threads scan the lists of dirty pages and pick some to be written back based on
the time at which they became dirty. If the system is not too busy with write operations, there is
an acceptable ratio between the number of dirty pages and the load imposed on the system by
the hard disk access operations needed to flush the pages.
❑ If there are too many dirty pages in the system as a result, for example, of a massive write opera-
tion, the kernel triggers further mechanisms to synchronize pages with the backing store until
the number of dirty pages returns to an acceptable level. What is meant by ‘‘too many dirty
pages‘‘ and ‘‘acceptable level‘‘ is a moot point, discussed below.
❑ Various components of the kernel require that data must be synchronized when a special event
has happened, for instance, when a filesystem is re-mounted.
The first two mechanisms are implemented by means of the kernel threadpdflushwhich exe-
cutes the synchronization code, while the third alternative can be triggered from many points in
the kernel.
Since the implementation of data synchronization consists of an unusually large number of intercon-
nected functions, an overview of what lies ahead of us precedes a detailed discussion of everything
in detail. Figure 17-1 show the dependence among the functions that constitute the implementation.
The figure is not a proper code flow diagram, but just shows how the functions are related to each
other and which code paths are possible. The diagram concentrates on synchronization operations
originating from thepdflushthread, system calls, and explicit requests from filesystem-related kernel
components.
The kernel can start to synchronize data from various different places, but all paths save one end
up insync_sb_inodes. The function is responsible to synchronize all dirty inodes belonging to a
given superblock, andwriteback_single_inodeis used for each inode. Both thesyncsystem call
and numerous generic kernel layers (like the partition code or the block layer) make use of this
possibility.
On the other hand, the need to synchronize the dirty inodes ofallsuperblocks in the system can also
arise. This is especially required for periodic and forced writeback. When dirtying data in filesystem
code, the kernel additionally ensures that the number of dirty pages does not get out of hand by starting
synchronization before this happens.
