Write behavior in Linux

When a write () call is returned, the kernel has forwarded the data provided by the buffer zone to the buffer zone of the kernel, but it cannot guarantee that the data has been written to its intended destination. Indeed, the speed returned by the write call is too fast, and there may be no time to complete the work of the project. The performance difference between the processor and the hard disk makes such a headache obvious.

 

In fact, if a user space application sends a write () system call, the Linux kernel first performs several checks and then copies the data into the buffer zone. Later, the kernel will collect all "dirty" buffers (with data written) in the background (the content is different from all the buffers of the corresponding disk block), arrange them in the optimal order, and then write them into the disk. This allows the write call to be executed as fast as lightning and returns almost immediately. This also allows the kernel to delay the write operation until it is idle, multiple write operations are performed in the whole batch.

 

The delayed write operation does not change the POSIX syntax. For example, if the data has just been written to the buffer but has not been written back to the disk, if a read request is sent, the request can be satisfied from the buffer and will not read the old data on the site. This behavior actually improves performance because read requests can be satisfied from the buffer in the memory, rather than from the disk. When read and write requests alternate as expected, the results are the same as expected. That is to say, the system will not crash before data is written back to the disk! Even if the application believes that the write request has been successfully completed, the data has not actually been written back to the disk.

 

Another problem with delayed writing is that the write order cannot be arranged, even though the application may arrange the order of write requests so that they can write back to the disk in a specific order, the kernel will reschedule the order of write requests in what it deems appropriate, mainly based on the new energy. Unless the system crashes, this is generally not a problem because all the buffers are written back to the disk, so everything is fine. Even so, the vast majority of applications do not actually care about the order of write requests.

 

The last issue that must be addressed when writing delayed data is reporting I/O errors. During data writing back to a disk, any I/O errors that cannot be reported to processes that send write requests, such as disk drive failures, may occur. Indeed, the buffer zone has nothing to do with these processes. If there are multiple processes that are "dirty" (writing data to) a single buffer, these processes may stay in the buffer after the data is written and before the data is written back to the disk.

 

The kernel tries to minimize the risk of delayed writing. In order to ensure that data can be written in time, the kernel has no buffer limit, and all "dirty" buffers will be written before the time limit is exceeded. You can set this value through/proc/sys/Vm/dirty_expire_centiseconds, in the unit of 1% seconds.