Linux Kernel Architecture

Chapter 17: Data Synchronization

Block layer, partition

handling, fsync system

call, filesystems...

File systems

Forced

writeback

pdflush

Data integrity synchronization Flushing synchronization

Periodic

writeback

Pages were

dirtied

For a single superblock

For all superblocks

can place inodes on s_io

can place inodes on

os_more_io

can wait for inode to

become unlocked or for

writeback to be completed

(∗) (+)

(∗)

(+) (∗) (∼)

(∼) (∗) (∼)

_ _fsync_super

sync_inodes_sb

sys_sync

sync_blockdev

_ _sync_inodes

wb_kupdate background_writeout

writeback_inodes

sync_sb_inodes

writeback_single_inode

write_inode

_ _sync_single_inode

balance_dirty_

pages

Figure 17-1: Overview of some functions involved in data synchronization.

Synchronizing all dirty inodes of a superblock is often much too coarse grained for filesystems. They

often require synchronizing a single dirty inode and thus usewriteback_single_inodedirectly.

Even if the synchronization implementation is centered around inodes, this does not imply that the

mechanisms just work for data contained in mountedfilesystems. Recall that raw block devices are

represented by inodes via the bdev pseudo-filesystem as discussed in Section 10.2.4. The synchronization

methods therefore also affect raw block devices in the same way as regular filesystem objects — good

news for everyone who wants to access data directly.

One remark on terminology: When I talk about inode synchronization in the following, I always mean

synchronization of both the inode metadata and the raw data managed by the inode. For regular files,

this means that the synchronization code’s aim is to both transfer time stamps, attributes, and the like, as

well as the contents of the file to the underlying block device.

17.2 The pdflush Mechanism

Thepdflushmechanism is implemented in a single file:mm/pdflush.c. This contrasts with the frag-

mented implementation of the synchronization mechanisms in earlier versions.