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,如需转载请自行联系原作者


相关文章
|
大数据 Java C语言
什么是CPU密集型、IO密集型?
CPU密集型(CPU-bound) CPU密集型也叫计算密集型,指的是系统的硬盘、内存性能相对CPU要好很多,此时,系统运作大部分的状况是CPU Loading 100%,CPU要读/写I/O(硬盘/内存),I/O在很短的时间就可以完成,而CPU还有许多运算要处理,CPU Loading很高。
4827 0
|
缓存 小程序 前端开发
【Uniapp】小程序携带Token请求接口+无感知登录方案2.0
【Uniapp】小程序携带Token请求接口+无感知登录方案2.0
1047 0
|
Linux 网络安全 数据安全/隐私保护
linux 本地终端 SSH 连接 gcp (Google Cloud Platform ) 配置教程
linux 本地终端 SSH 连接 gcp (Google Cloud Platform ) 配置教程
10251 0
|
缓存 Linux 数据安全/隐私保护
Linux环境下如何通过手动调用drop_caches命令释放内存
总的来说,记录住“drop_caches” 命令并理解其含义,可以让你在日常使用Linux的过程中更加娴熟和自如。
2121 23
|
缓存 前端开发 Linux
PAS工具分享 - FrameScope与RTRadar
本次分享的主题是PAS工具分享 - FrameScope与RTRadar,由阿里云基础软件系统研发团队工程师刘依男、苏峰分享。主要分为三个部分: 1. PAS性能分析套件综述 2. PAS FrameScope 3. PAS RTRadar
593 0
|
存储 关系型数据库 分布式数据库
PolarDB PG 版冷热数据分层功能介绍
本文介绍了云原生数据库PolarDB PG版的冷热数据分层存储功能,涵盖其原理、特性及最佳实践。冷热分层存储通过将冷数据归档至OSS(对象存储服务),实现低成本高效存储,同时保持SQL操作透明性和性能优化。支持多种分层模式,如表与索引分层、大字段独立归档等,并提供压缩和缓存机制以提升访问速度。此外,还介绍了如何通过DDL语句轻松转存数据至OSS,以及一系列最佳实践,包括自动冷热分层、无锁表转存和一键转存等功能。
1219 36
|
缓存 关系型数据库 MySQL
【MySQL】read_rnd_buffer_size=4M,是干什么的?底层原理是什么?
【MySQL】read_rnd_buffer_size=4M,是干什么的?底层原理是什么?
1708 0
|
存储 机器学习/深度学习 人工智能
【AI系统】昇腾 AI 核心单元
本文深入解析了华为昇腾AI处理器的核心——AI Core及其达芬奇架构。AI Core采用特定域架构(DSA),专为深度学习算法优化,通过矩阵、向量和标量计算单元的高效协作,实现了对深度学习算法的加速。文章详细介绍了AI Core的计算单元、存储系统及控制单元的设计,展示了其如何通过优化数据通路和控制流程,显著提升计算性能。
2544 3
|
监控 安全 网络安全
|
测试技术 C# 图形学
掌握Unity调试与测试的终极指南:从内置调试工具到自动化测试框架,全方位保障游戏品质不踩坑,打造流畅游戏体验的必备技能大揭秘!
【9月更文挑战第1天】在开发游戏时,Unity 引擎让创意变为现实。但软件开发中难免遇到 Bug,若不解决,将严重影响用户体验。调试与测试成为确保游戏质量的最后一道防线。本文介绍如何利用 Unity 的调试工具高效排查问题,并通过 Profiler 分析性能瓶颈。此外,Unity Test Framework 支持自动化测试,提高开发效率。结合单元测试与集成测试,确保游戏逻辑正确无误。对于在线游戏,还需进行压力测试以验证服务器稳定性。总之,调试与测试贯穿游戏开发全流程,确保最终作品既好玩又稳定。
1476 4