Shut down actions order: write buffers after RO root remount
Exploring amazing Book How Linux Works by Brian Ward I usually have no question. But this one. At the "6.7.0 Shutting Down Your System" there is an ordered list of jobs.
After remount root file system in ReadOnly mode (6) write buffered data by the sync program (7).
How is it possible to write data in a file system after mount in in ReadOnly mode?
May be it is an error, correct order is first write buffers (7) then unmount (5) and ro remount (6)?
1. init asks every process to shut down cleanly.
2. If a process doesn’t respond after a while, init kills it, first
trying a TERM signal.
3. If the TERM signal doesn’t work, init uses the KILL signal on any
stragglers.
4. The system locks system files into place and makes other preparations
for shutdown.
5. The system unmounts all filesystems other than the root.
6. The system remounts the root filesystem read-only.
7. The system writes all buffered data out to the filesystem with the
sync program.
8. The final step is to tell the kernel to reboot or stop with the
reboot(2) system call. This can be done by init or an auxiliary program
such as reboot, halt, or poweroff.
P.S. The book is amazing it is an only question usolved during several chapters.
There’s the filesystem driver (which translates blocks on some block storage medium into directories and files), and there’s a caching layer beneath that (so that you can quickly write data to the storage medium, and continue doing other things, while the kernel actually takes care of getting the data written to the storage device in the background, because that typically is relatively slow).
sync makes sure anything that’s still in that caching layer is written to storage.
So, this is about data "below" the filesystem, if you will.
How is it possible to write data in a file system after mount in in ReadOnly mode?
Read only is an attribute of the mount(point). In other words, you cannot make changes to the filesystem via the mount(point). It does not mean that no changes can be made to the filesystem by a lower layer, such as the block layer or the caching layer. (Probably there’s not really such thing as the caching layer. More like the block layer takes care of the caching, I guess.)
To prevent any potential change made to the filesystem, the partition or drive itself will need to be by some means read-only. (Probably not even the effect of blockdev --setro would "cut off" any buffered data from being flush onto the device. It will likely require the the device itself to forbid write access to any of its logical blocks.)
From the point of view of the files and directories, changes you made to them do not differ depending on whether they have been written to the actual storage. In other words, unless the filesystem driver is made to run in some "synchronous mode" (if it’s a thing), what you read from a file may still be in the write buffer / cache, until a flush all the way down from the filesystem driver (e.g. sync -f path/to/mountpoint) is requested. (The flush could occur behind the scene because of other reasons though.)
I do wonder if in Linux you actually need any explicit sync / flush after you remount a mount in read-only mode. I would be slightly surprised that it does not cause an implicit one like unmounting.