linuxIO刷新机制fsync和fdatasync详细解释

简介:

前言:

        Linux,unix在内核中设有 缓冲区快速缓冲或页面快速缓冲。大多数磁盘I/O都通过缓冲进行,採用延迟写技术。
sync:将全部改动过的快缓存区排入写队列。然后返回。并不等待实际写磁盘操作结束
fsync:仅仅对有文件描写叙述符制定的单一文件起作用,而且等待些磁盘操作结束,然后返回。


fdatasync:类似fsync,但它仅仅影响文件的数据部分。

fsync还会同步更新文件的属性。


fflush:标准I/O函数(如:fread,fwrite)会在内存建立缓冲。该函数刷新内存缓冲。将内容写入内核缓冲。要想将其写入磁盘,还须要调用fsync。

(先调用fflush后调用fsync。否则不起作用)。


前面介绍函数write()时,我们觉得该函数一旦返回。数据便已经写到了文件里。

可是这样的概念仅仅是宏观上的。实际上,操作系统实现某些文件I/O时(如磁盘文件)。为了保证I/O的效率。在内核一般会用到一片专门的区域(内存或独立的I/O地址空间)作为I/O数据缓冲区。

应用程序能够将这片内核区域看成是I/O数据的一个高速中转站(图3-5)。当调用write()函数写出数据时。数据一旦写到该缓冲区。函数便马上返回。此时写出的数据能够用read()读回,也能够被其它进程读到,可是并不意味着它们已经被写到了外部永久存储介质上,即使调用close()关闭文件后也可能如此。内核I/O数据缓冲区中的数据仅仅在适当的时候才由操作系统启动外设进行传输,真正的传输动作由独立于CPU的外设控制器或者外设本身(Linux称之为DMA引擎)来完毕。因此。从数据被实际写到磁盘的角度来看,用write()写出的文件数据与外部存储设备并非全然同步的。在现代计算机系统中,这样的不同步的时间间隔非常短,一般仅仅有几秒或十几秒。详细取决于写出的数据量和I/O数据缓冲区的状态。虽然不同步的时间间隔非常短,可是假设在此期间发生掉电或者系统崩溃。则会导致所写数据来不及写至磁盘而丢失的情况。

因为现代计算机通常都十分稳定可靠。出现掉电或系统崩溃的情况极少。因此多数应用在写文件时能够忽略这种瞬间不同步情况。可是,有些应用存在着这种一些同步点,在这些点上所写的数据很关键。或者必须及时保证文件的一致性。为了防备万一。这些应用须要确保全部写出的数据都已经传送到了外部永久存储介质上。

为此,UNIX提供了两种手段来实现这一目的。当中一种方法是对文件设置O_SYNC标志(表3-1)。这样能够保证每次写数据都直接写到磁盘。假设设置了这个标志,write()调用将直到数据已安全地写到磁盘后(而不不过系统的I/O缓冲区)才返回。可是这样每次写数据都保持同步的效率比較低。


 

还有一种方法是仅仅在须要时调用函数fsync()或者fdatasync()
#include <unistd.h>
int fsync(int fildes);
int fdatasync(int fildes)

fsync()强制与描写叙述字fildes相连文件的全部改动过的数据(包含核内I/O缓冲区中的数据)传送到外部永久介质。即刷新fildes给出的文件的全部信息。调用 fsync()的进程将堵塞直到设备报告传送已经完毕。这里“全部改动过的数据”包含用户写出的数据以及文件本身的特征数据(4.1.1节和表4-1)。如文件的訪问时间、改动时间、文件的属主等。

fdatasync()的功能与fsync()类似,仅仅是它仅仅强制传送用户已写出的数据至物理存储设备,不包含文件本身的特征数据。这样能够适当降低文件刷新时的数据传送量。只是有的系统并不支持fdatasync()。在这样的系统上,fdatasync()等价于fsync()。

一个程序在写出数据之后,假设继续进行兴许处理之前要求确保所写数据已写到磁盘,则应当调用fsync()。比如,数据库应用一般会在调用write()保存关键交易数据的同一时候也调用fsync()。

我们在2.7节曾讨论了标准I/O流缓冲区的问题以及函数fflush()。那么,这两个缓冲区有何不同?回答是。内核I/O缓冲区是由操作系统管理的空间。而流缓冲区是由标准I/O库管理的用户空间。fflush()仅仅刷新位于用户空间中的流缓冲区。fflush()返回后,仅仅保证数据已不在流缓冲区中,并不保证它们一定被写到了磁盘。此时,从流缓冲区刷新的数据可能已被写至磁盘,也可能还待在内核I/O缓冲区中。要确保流I/O写出的数它已被写入磁盘,然后调用fflush()还应当之后调用的fsync()。

版权声明:本文博客原创文章,博客,未经同意,不得转载。






本文转自mfrbuaa博客园博客,原文链接:http://www.cnblogs.com/mfrbuaa/p/4747188.html,如需转载请自行联系原作者


相关文章
|
25天前
|
存储 编译器 C语言
如何在 C 语言中判断文件缓冲区是否需要刷新?
在C语言中,可以通过检查文件流的内部状态或使用`fflush`函数尝试刷新缓冲区来判断文件缓冲区是否需要刷新。通常,当缓冲区满、遇到换行符或显式调用`fflush`时,缓冲区会自动刷新。
|
6月前
|
存储 缓存 中间件
中间件Read-Through Cache(直读缓存)策略工作原理
【5月更文挑战第11天】中间件Read-Through Cache(直读缓存)策略工作原理
72 3
|
6月前
|
canal 缓存 NoSQL
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-03 Refresh Ahead + SingleFlight + 删除缓存 + 延迟双删
【5月更文挑战第11天】Refresh Ahead模式通过CDC异步刷新缓存,但面临缓存一致性问题,可借鉴Write Back策略解决。SingleFlight限制并发加载,减少数据库压力,适合热点数据。删除缓存模式在更新数据库后删除缓存,一致性问题源于读写线程冲突。延迟双删模式两次删除,理论上减少不一致,但可能降低缓存命中率。选用模式需权衡优劣,延迟双删在低并发下较优。装饰器模式可用于实现多种缓存模式,无侵入地增强现有缓存系统。
126 2
|
6月前
|
缓存 数据库 NoSQL
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-02 Write Through + Write Back
【5月更文挑战第10天】`Write Through`是一种缓存策略,写操作仅需写入缓存,缓存负责更新数据库。异步版本可能丢失数据,而同步变种先写数据库再异步刷新缓存,减少丢数据风险。`Write Back`模式数据先写入缓存,过期时才写入数据库,可能导致数据丢失,但若使用Redis并确保高可用,可部分解决一致性问题。在特定条件下,如使用SETNX命令,能缓解一致性挑战。
79 0
【后端面经】【缓存】33|缓存模式:缓存模式能不能解决缓存一致性问题?-02 Write Through + Write Back
|
Go 数据库
sync.Once-保证运行期间的某段代码只会执行一次
sync.Once-保证运行期间的某段代码只会执行一次
81 0
|
存储 关系型数据库 API
应用PMDK修改WAL操作使之适配持久化内存
应用PMDK修改WAL操作使之适配持久化内存
122 0
|
存储 缓存 分布式计算
Spark 缓存和检查点机制
Spark 缓存和检查点机制
132 0
|
存储 编译器 C语言
缓冲区刷新在 C++ 中意味着什么?
缓冲区刷新是将计算机数据从临时存储区域传输到计算机的永久内存。例如,如果我们对文件进行任何更改,我们在一台计算机屏幕上看到的更改会临时存储在缓冲区中。
177 0
|
NoSQL Redis 开发工具
持久化-AOF重写概念与命令执行|学习笔记
快速学习持久化-AOF重写概念与命令执行
持久化-AOF重写概念与命令执行|学习笔记
|
存储 缓存 Java
【Android 逆向】函数拦截 ( 使用 cache_flush 系统函数刷新 CPU 高速缓存 | 刷新 CPU 高速缓存弊端 | 函数拦截推荐时机 )
【Android 逆向】函数拦截 ( 使用 cache_flush 系统函数刷新 CPU 高速缓存 | 刷新 CPU 高速缓存弊端 | 函数拦截推荐时机 )
163 0
【Android 逆向】函数拦截 ( 使用 cache_flush 系统函数刷新 CPU 高速缓存 | 刷新 CPU 高速缓存弊端 | 函数拦截推荐时机 )