存储进阶:怎么才能保证 IO 数据的安全?

Posted CSDN云计算

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了存储进阶:怎么才能保证 IO 数据的安全?相关的知识,希望对你有一定的参考价值。

来源 | 奇伢云存储

头图 | 下载于视觉中国

写成功了数据就安全了吗?

思考一个问题:写数据做到什么程度才叫安全了?

就是:用户发过来一个写 IO 请求,只要你给他回复了 “写成功了”,那么无论机器发生掉电,还是重启等等之类的,数据都还能读出来。

所以,在我们不考虑数据静默错误的前提下,数据安全的最本质要求是什么?

划重点:那就是数据一定要在非易失性的存储介质里,你才能给用户回复“写成功”。请一定要记住这句话,做存储开发的人员,80% 的时间都在思考这句话。

那么常见的易失性介质和非易失性介质有哪些呢?

易失性介质:寄存器,内存 等;非易失性介质:磁盘,固态硬盘 等;

从上到下,速度递减,容量递增,价格递减。

Linux IO 简述

我们前面提到一个文件的读写方式,标准库的方式和系统调用的方式。无论是哪一种,本质上都是基于文件的一种形式,下面承接了一层文件系统,主要层次:系统调用 -> vfs -> 文件系统 -> 块设备 -> 硬件驱动 。



我们 open 了这个文件,然后 write 数据进去。好,现在思考一个问题,当 write 返回成功之后,数据到磁盘了吗?

答案是:不确定。

因为有文件系统的 cache ,默认是 write back 的模式,数据写到内存就返回成功了,然后内核根据实际情况(比如定期或者脏数据达到某个阈值),异步刷盘。

这样的好处是保证了写的性能,貌似写的性能非常好(可不好嘛,数据写内存的速度),坏处是存在数据风险。因为用户收到成功的时候,数据可能还在内存,这个时候整机掉电,由于内存是易失性介质,数据就丢了。丢数据 是存储最不能接受的事情,相当于丢失了存储的生命线。

动画演示:

那么,怎么保证数据的可靠?

划重点:还是那句话,一定要确保数据落盘之后,才向用户返回成功。

那么怎么才能保证这一点?有以下 3 种方法。

  1. open 文件的时候,用 O_DIRECT 模式打开,这样 write/read 的时候,文件系统的 IO 会绕过 cache,直接跟磁盘 IO;

  2. open 文件的时候,使用 O_SYNC 模式,确保每一笔 IO 都是同步落盘的。或者 write 之后,主动调用一把 fsync ,强制数据落盘;

  3. 读写文件的另一种方式是通过 mmap 函数把文件映射到进程的地址空间,读写进程内存的地址的数据其实是转发到磁盘上去读写,write 之后主动调用一把 msync 强制刷盘;

三种安全的 IO 姿势

 1   O_DIRECT 模式

DIRECT IO 模式能够保证每次 IO 都直接访问磁盘数据,而不是数据写到内存就向用户返回成功的结果,这样才能确保数据安全。因为内存是易失性的,掉电就丢了,数据只有写到持久化的介质才能安心。

动画演示:

读的时候也是直接读磁盘,而不会缓存到内存中,从而也能节省整机内存的使用。

缺点也同样明显,由于每次 IO 都要落盘,那么性能肯定看起来差(但你要明白,其实这才是真实的磁盘性能)。

划重点:使用了 O_DIRECT 模式之后,必须要用户自己保证对齐规则,否则 IO 会报错,有 3 个需要对齐的规则:

  1. 磁盘 IO 的大小必须扇区大小(512字节)对齐

  2. 磁盘 IO 偏移按照扇区大小对齐;

  3. 内存 buffer 的地址也必须是扇区对齐;

c 语言示例:

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <stdint.h>

extern int errno;
#define align_ptr(p, a) \\
    (u_char *)(((uintptr_t)(p) + ((uintptr_t)a - 1)) & ~((uintptr_t)a - 1))
int main(int argc, char **argv)
{
    char timestamp[8192] = {0,};
    char *timestamp_buf = NULL;
    int timestamp_len = 0;
    ssize_t n = 0;
    int fd = -1;

    fd = open("./test_directio.txt", O_CREAT | O_RDWR | O_DIRECT, 0644);
    assert(fd >= 0);

    // 对齐内存地址
    timestamp_buf = (char *)(align_ptr(timestamp, 512));
    timestamp_len = 512;

    n = pwrite(fd, timestamp_buf, timestamp_len, 0);
    printf("ret (%ld) errno (%s)\\n", n, strerror(errno));

    return 0;
}

编译命令:

gcc -ggdb3 -O0 test.c -D_GNU_SOURCE

生成二进制文件,执行下就知道了,这个是成功的。

sh-4.4# ./a.out
ret (512) errno (Success)

如果为了验证对齐导致的错误,读者朋友可以故意让 io 的偏移或者大小,或者内存 buffer 地址不按照 512 对齐(比如故意让 timestamp_buf 对齐之后的地址减 1,再试下运行),会得到如下:

sh-4.4# ./a.out
ret (-1) errno (Invalid argument)

思考问题:有些童鞋可能会好奇问了?IO 大小和偏移按照 512 对齐我会,但是怎么才能保证 malloc 的地址是 512 对齐的呢?

是啊,我们无法用 malloc 来控制生成的地址。这对这个需求,我们有两个解决办法:

方法一:分配大一点的内存,然后在这个大块内存里找到对齐的地址,只需要确保 IO 大小不会超过最后的边界即可;

我上面的 demo 例子就是如此,分配了 8192 的内存块,然后从里面找到 512 对齐的地址。从这个地址开始往后 512 个字节是绝对到不了这个大内存块的边界的。对齐的目的安全达成。


这种方式实现简单且通用,但是比较浪费内存。

方法二:使用 posix 标准封装的接口 posix_memalign 来分配内存,这个接口分配的内存能保证对齐;

如下,分配 1 KiB 的内存 buffer,内存地址按照 512 字节对齐。

ret = posix_memalign (&buf, 512, 1024);
if (ret) {
    return -1;
}

思考一个问题:O_DIRECT 模式 的 IO 一般是哪些应用场景?

  • 最常见的是数据库系统,数据库有自己的缓存体系和 IO 优化,无需内核消耗内存再去完成相同的事情,并且可能好心办坏事;

  • 不格式化文件系统,而是直接管理块设备的场景;

 2   标准 IO + sync

sync 功能:强制刷新内核缓冲区到输出磁盘。

在 Linux 的缓存 I/O 机制中,用户和磁盘之间有一层易失性的介质——内核空间的 buffer cache

  • 读的时候会 cache 一份到内存中以便提高后续的读性能;

  • 写的时候用户数据写到内存 cache 就向用户返回成功,然后异步刷盘,从而提高用户的写性能。

读操作描述如下

  1. 操作系统先看内核的 buffer cache 有缓存不?有,那么就直接从缓存中返回;

  2. 否则从磁盘中读取,然后缓存在操作系统的缓存中;

写操作描述如下

  1. 将数据从用户空间复制到内核的内存 cache 中,这时就向用户返回成功,对用户来说写操作就已经完成;

  2. 至于内存的数据什么时候才真正写到磁盘由操作系统策略决定(如果此时机器掉电,那么就会丢失用户数据);

  3. 所以,如果你要保证落盘,必须显式调用了 sync 命令,显式把数据刷到磁盘(只有刷到磁盘,机器掉电才不会导致丢数据);

划重点:sync 机制能保证当前时间点之前的数据全部刷到磁盘。。而关于 sync 的方式大概有两种:

  1. open 的使用使用 O_SYNC 标识;

  2. 显式调用 fsync 之类的系统调用;

方法一:open 使用 O_SYNC 标识

c 语言示例:

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <stdint.h>

extern int errno;

int main(int argc, char **argv)
{
    char buffer[512] = {0,};
    ssize_t n = 0;
    int fd = -1;

    fd = open("./test_sync.txt", O_CREAT | O_RDWR | O_SYNC, 0644);
    assert(fd >= 0);

    n = pwrite(fd, buffer, 512, 0);
    printf("ret (%ld) errno (%s)\\n", n, strerror(errno));

    return 0;
}

这种方式能保证每一笔 IO 都是同步 IO,一定是刷到磁盘才返回,但是这种使用姿势一般少见,因为这个性能会很差,并且不利于批量优化。

动画演示:

方法二:单独调用函数 fsync

这个则是在 write 之后 fsync 一把数据到磁盘,这种方式实际生产环境用的多些,因为方便业务优化。这种方式对程序员提出了更高的要求,要求必须自己掌握好 fsync 的时机,达到既保证安全又保证性能的目的,这里通常是个权衡点。

比如,你可以 write 10 次之后,最后才调用一把 fsync,这样既能保证刷盘,又达成了批量 IO 的优化目的。

关于这种使用姿势,有几个类似函数,其中有些差异,各自体会下:

// 文件数据和元数据部分都刷盘
int fsync(int fildes);
// 文件数据部分都刷盘
int fdatasync(int fildes);
// 整个内存 cache 都刷磁盘
void sync(void);

动画演示:

 3   mmap + msync

这是一个非常有趣的 IO 模式,通过 mmap 函数将硬盘上文件与进程地址空间大小相同的区域映射起来,之后当要访问这段内存中一段数据时,内核会转换为访问该文件的对应位置的数据。从使用姿势上,就跟操作内存一样,但从结果上来看,本质上是文件 IO


void *
mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset)

int
munmap(void *addr, size_t len);

mmap 这种方式可以减少数据在用户空间和内核空间之间的拷贝操作,当数据大的时候,采用内存映射方式去访问文件会获得比较好的效率(因为可以减少内存拷贝量,并且聚合 IO,数据批量下盘,有效的减少 IO 次数)。

当然,你 write 数据也还是异步落盘的,并没有实时落盘,如果要保证落盘,那么必须要调用 msync ,调用成功,才算持久化落盘。

mmap 的优点:

  • 减少系统调用的次数。只需要 mmap 一次的系统调用,后续的操作都是内存拷贝操作姿势,而不是 write/read 的系统调用;

  • 减少数据拷贝次数;

c 语言示例:

#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/stat.h>
#include <assert.h>
#include <fcntl.h>
#include <string.h>

int main()
{
    int ret = -1;
    int fd = -1;

    fd = open("test_mmap.txt", O_CREAT | O_RDWR, 0644);
    assert(fd >= 0);

    ret = ftruncate(fd, 512);
    assert(ret >= 0);

    char *const address = (char *)mmap(NULL, 512, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    assert(address != MAP_FAILED);

    // 神奇在这里(看起来是内存拷贝,其实是文件 IO)
    strcpy(address, "hallo, world");
    ret = close(fd);
    assert(ret >= 0);

    // 落盘确保
    ret = msync(address, 512, MS_SYNC);
    assert(ret >= 0);

    ret = munmap(address, 512);
    assert(ret >= 0);

    return 0;
}

编译运行看看吧。

gcc -ggdb3 -O0 test_mmap.c -D_GNU_SOURCE

是不是生成了一个 test_mmap.txt 文件,里面有一句 “hello,world”。

动画演示:

硬件缓存

以上方式保证了文件系统那一层的落盘,但是磁盘硬件其实本身也有缓存,这个属于硬件缓存,这层缓存也是易失的。所以最后一点是,为了保证数据的落盘,硬盘缓存也要关掉。

# 查看写缓存状态;
hdparm -W  /dev/sda 
# 关闭 HDD Cache,保证数据强一致性;避免断电时数据未落盘;
hdparm -W  0 /dev/sda
# 打开 HDD Cache(断电时可能导致丢数据)
hdparm -W  1 /dev/sda

按照内核保证数据落盘,硬件保证关闭缓存,综合以上的 IO 姿势,当你写一笔 IO 落盘之后,才能说数据写到磁盘了,才能保证数据是掉电非易失的。

总结

  1. 数据一定要写在非易失性的存储介质里,你才能给用户回复“写成功”。其他的取巧的方式都是耍流氓、走钢丝;

  2. 本文总结 3 种最根本的 IO 安全的方式,分别是 O_DIRECT 写,标准 IO + Sync 方式,mmap 写 + msync 方式。要么每次都是同步写盘,要么就是每次写完,再调用 sync 主动刷,才能保证数据安全

  3. O_DIRECT 对使用者提出了苛刻的要求,必须要满足 IO 的 offset,length 扇区对齐,内存 buffer 地址也要扇区对齐;

  4. 注意硬盘也有缓存,这个也是易失性的,必须要考虑在内,可以通过 hdparm 命令开关;

终于,你可以安心了,数据经过层层险阻来到磁盘了。嘿嘿,你以为数据就安全了吗?里面的名堂还多着呢,磁盘静默错误坏了怎么办?数据还能抢救一下吗?怎么保证网络传输过程不出问题?怎么保证内存拷贝过程不出问题?以后慢慢跟你说。





☞再见 Nacos,我要玩 Service Mesh 了!☞急!CPU 被挖矿,该怎么找进程?☞从 0 到 1,高德 Serverless 平台建设及实践☞听完姚期智的一句“嘟囔”,他开始第二次创业
点分享点收藏点点赞点在看

以上是关于存储进阶:怎么才能保证 IO 数据的安全?的主要内容,如果未能解决你的问题,请参考以下文章

说话时怎样才能保证不被别人打断?

区块链百问百答区块链中分布式数据存储是什么意思? 区块链的分布式存储是怎么保证安全性的? (第35章)

我的Android进阶之旅NDK开发之在C++代码中使用Android Log打印日志,打印出C++的函数耗时以及代码片段耗时详情

大数据时代,如何才能保证数据安全?

JVM进阶之沙箱安全模型

JVM进阶之沙箱安全模型