Nov
12
最近和sandy一起在做的项目中,对文件系统有些纠结的地方。主要都是一致性问题。
比较简单的一个问题是,往某个文件末尾追加内容,希望保证断电数据不丢失,又想速度快。fsycn可以保证缓存被刷到存储设备;但是在机械硬盘上执行fsync又变成了瓶颈。经过测试,在某机器上fsync大约每秒可以执行1100次左右。虽然目前能够满足业务需求,但是的确是项目中最大的瓶颈。解决办法就是花钱,买SSD。
还有几个麻烦的问题。
====
首先,记录锁。APUE 14.3 记录锁 中提到一个"锁的隐含和释放"
因为fd2是dup出来的,所以跟fd1实际上指向的是同一个文件。如果fd2被关闭,那么fd1上的锁被释放。这一点比较好理解。但是后面跟着一个坑爹的情况:
大坑。
经过编码测试,的确dup或者再次open的fd2(即使OPEN的时候用的是不同的flag)被关闭后,的确会出现记录锁的释放。一个进程中的另一个pthread线程(其他线程库没有测试过)关闭fd2效果是一致的(说明是用pid来识别锁的归属)。不过,如果使用flock(fd, LOCK_**)对整个文件进行加锁,则不会出现这个问题。
====
其次,write的原子性#1:进程a在调用write的期间,进程b是否可以往相同的文件中写数据?
《IEEE Std 1003.1, 2004 Edition》里面提到,当count<PIPE_BUF,如果write成功返回,write对pipe/FIFO的写入是原子的。但是对普通文件的写入呢?没有说明。
翻了一下 linux-2.6.38.8.tar.bz2 ,源码在 fs/read_write.c 中定义了 write 系统调用:
vfs_write调用的是 file->f_op->write , 如果这个指针是NULL,那么调用 do_sync_write。
以ext2为例,ext2/file.c 中定义了
也就是说,实际上调用的还是 do_sync_write 函数,蛋疼。更蛋疼的是,do_sync_write 在一个for循环里面(虽然是循环,但是没看出分段写入的意思) 调用的是 file->f_op->aio_write ,也就是上面的 generic_file_aio_write @ mm/filemap.c。这个函数获取了 file->f_mapping->inode, 然后对该inode加锁,调用 __generic_file_aio_write , 对inode解锁,然后根据文件的属性决定是否需要sync数据。(之所以有这么蛋疼的调用链,应该是不同的文件系统/内核其他功能模块在调用各个函数的时候,希望做一些包装,完成一些额外的事情)。
__generic_file_aio_write 大概有100行,kernel.org的<部分>说明是:
这个函数完成了将数据写入文件的所有必需操作。它要做的事情包括各种基本检查(可能被schedule)、删除文件的SUID、修改文件更新时间、调用更底层的操作(取决于是Direct IO还是Buffered Write)。
This function does all the work needed for actually writing data to a file. It does all basic checks, removes SUID from the file, updates modification times and calls proper subroutines depending on whether we do direct IO or a standard buffered write.
它期望 inode 的mutex已经被获取,除非是不需要锁的块设备或其它对象。(这个在generic_file_aio_write里面的确获取了)
It expects i_mutex to be grabbed unless we work on a block device or similar object which does not need locking at all.
从内核源码来看,只要 __generic_file_aio_write 没有返回,对同一个inode的写入是排斥的。但是写了个多线程的程序,每次对文件APPEND 1MB数据,各写1G。检查后发现并不是写入互斥的。(求kernel hacker解答……)
只是,每次原子写入的数据大小到底是多少?这个值会影响到很多应用的正确性,比如,日志文件的写入一般是追加的,如果一次追加的数据多于这个值,那么多个进程写同一个日志文件会很BUGGY。
====
再有,write的原子性#2:进程a在调用write的期间,进程b是否可以从相同的文件中读取数据?
读取的时候,一路从 read -> vfs_read -> do_sync_read -> generic_file_aio_read 没有需要获取 i_mutex 的地方。再到 do_generic_file_read 这个函数的时候,就是各种内存页面的处理,包括从页表找出实际的页,或者从磁盘中读取、换页之类(这个过程中可能被schedule)。当页面可用的时候,调用传入的 file_read_actor,这个函数使用硬件体系相关的 __copy_to_user(to, from, n) ...
看起来写操作和读操作并不是互斥的,这个也比较符合平时对文件操作的逻辑。不过从上一个问题可以看出的是,write并不是原子的,它是一段一段往内核BUFF里面写的,在每一段完成之前,read获取到的这一段数据还是旧数据。
====
最后,接上个问题,调用write写文件的时候,写入顺序是否是按地址顺序写入?如果不是的话,read可能先读到一段旧数据,再读到一段新数据,这个会让人崩溃的……
在这里,[写入]有两层意思:a. 写入缓存; b. 刷回存储设备。
对于写入缓存,实际上就是从用户空间将数据拷贝到内核空间,调用的是 __copy_from_user(to,from,n) 这个宏。这个宏的实现是在 arch 目录下,不同硬件平台的具体汇编代码。虽然没有去具体了解每个平台的实现方式(代价太大了,各种汇编啊……),但是几乎可以肯定,绝大部分平台下这个顺序是按照地址顺序写入的。虽然内核可以选择不顺序拷贝数据,但是开发者应该不会这么蛋疼吧……
对于刷回设备,调用的[应该](未考证,求证实)就是具体的fsync函数了,比如ext3下面是 fs/ext3/fsync.c 中的 ext3_sync_file 这个函数。这个由于跟具体设备相关,考证更困难了。。不过sandy同学举了个例子,磁带,就有可能是根据磁头目前的位置来刷写的,在有些时候逆向写效率更高(当然,同样未考证具体实现)。
应用程序调用read,实际上是从内核的缓存中获取数据的,所以一般的应用程序只需要关心 a. 写入缓存 的顺序就行了。从实现的合理性来判断,内核应该是按照顺序拷贝的。
我在stackoverflow.com问了最后这个问题,有人推荐了 http://flamingspork.com/talks/ 里面的 Eat My Data: How Everybody Gets File IO Wrong ,值得一看。
好吧。今天一整天就废在这上面了,本篇暂时到此为止,欢迎各种评论拍砖。
转载请注明出自 ,如是转载文则注明原出处,谢谢:)
RSS订阅地址: https://www.felix021.com/blog/feed.php 。
比较简单的一个问题是,往某个文件末尾追加内容,希望保证断电数据不丢失,又想速度快。fsycn可以保证缓存被刷到存储设备;但是在机械硬盘上执行fsync又变成了瓶颈。经过测试,在某机器上fsync大约每秒可以执行1100次左右。虽然目前能够满足业务需求,但是的确是项目中最大的瓶颈。解决办法就是花钱,买SSD。
还有几个麻烦的问题。
====
首先,记录锁。APUE 14.3 记录锁 中提到一个"锁的隐含和释放"
fd1 = open(filename, ...);
read_lock(fd1, ...); //这个是APUE自带的apue.h中定义的一个宏,调用fcntl(fd, F_SETLK, ...)
fd2 = dup(fd1);
close(fd2);
read_lock(fd1, ...); //这个是APUE自带的apue.h中定义的一个宏,调用fcntl(fd, F_SETLK, ...)
fd2 = dup(fd1);
close(fd2);
因为fd2是dup出来的,所以跟fd1实际上指向的是同一个文件。如果fd2被关闭,那么fd1上的锁被释放。这一点比较好理解。但是后面跟着一个坑爹的情况:
fd1 = open(filename, ...);
read_lock(fd1, ...);
fd2 = open(filename, ...);
close(fd2);
注意:APUE说,这个情况和上一个情况是相同的。read_lock(fd1, ...);
fd2 = open(filename, ...);
close(fd2);
大坑。
经过编码测试,的确dup或者再次open的fd2(即使OPEN的时候用的是不同的flag)被关闭后,的确会出现记录锁的释放。一个进程中的另一个pthread线程(其他线程库没有测试过)关闭fd2效果是一致的(说明是用pid来识别锁的归属)。不过,如果使用flock(fd, LOCK_**)对整个文件进行加锁,则不会出现这个问题。
====
其次,write的原子性#1:进程a在调用write的期间,进程b是否可以往相同的文件中写数据?
《IEEE Std 1003.1, 2004 Edition》里面提到,当count<PIPE_BUF,如果write成功返回,write对pipe/FIFO的写入是原子的。但是对普通文件的写入呢?没有说明。
翻了一下 linux-2.6.38.8.tar.bz2 ,源码在 fs/read_write.c 中定义了 write 系统调用:
SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf,
size_t, count)
{
struct file *file;
ssize_t ret = -EBADF;
int fput_needed;
file = fget_light(fd, &fput_needed); //根据fd获取struct file;如果refcnt>0,加锁
if (file) {
loff_t pos = file_pos_read(file); //获取文件当前位置
ret = vfs_write(file, buf, count, &pos); //调用vfs层进行写入
file_pos_write(file, pos); //更新文件位置
fput_light(file, fput_needed); //如果fget_light加锁了,解锁
}
return ret;
}
size_t, count)
{
struct file *file;
ssize_t ret = -EBADF;
int fput_needed;
file = fget_light(fd, &fput_needed); //根据fd获取struct file;如果refcnt>0,加锁
if (file) {
loff_t pos = file_pos_read(file); //获取文件当前位置
ret = vfs_write(file, buf, count, &pos); //调用vfs层进行写入
file_pos_write(file, pos); //更新文件位置
fput_light(file, fput_needed); //如果fget_light加锁了,解锁
}
return ret;
}
vfs_write调用的是 file->f_op->write , 如果这个指针是NULL,那么调用 do_sync_write。
以ext2为例,ext2/file.c 中定义了
const struct file_operations ext2_file_operations = {
.llseek = generic_file_llseek,
.read = do_sync_read,
.write = do_sync_write,
.aio_read = generic_file_aio_read,
.aio_write = generic_file_aio_write,
........
.llseek = generic_file_llseek,
.read = do_sync_read,
.write = do_sync_write,
.aio_read = generic_file_aio_read,
.aio_write = generic_file_aio_write,
........
也就是说,实际上调用的还是 do_sync_write 函数,蛋疼。更蛋疼的是,do_sync_write 在一个for循环里面(虽然是循环,但是没看出分段写入的意思) 调用的是 file->f_op->aio_write ,也就是上面的 generic_file_aio_write @ mm/filemap.c。这个函数获取了 file->f_mapping->inode, 然后对该inode加锁,调用 __generic_file_aio_write , 对inode解锁,然后根据文件的属性决定是否需要sync数据。(之所以有这么蛋疼的调用链,应该是不同的文件系统/内核其他功能模块在调用各个函数的时候,希望做一些包装,完成一些额外的事情)。
__generic_file_aio_write 大概有100行,kernel.org的<部分>说明是:
这个函数完成了将数据写入文件的所有必需操作。它要做的事情包括各种基本检查(可能被schedule)、删除文件的SUID、修改文件更新时间、调用更底层的操作(取决于是Direct IO还是Buffered Write)。
This function does all the work needed for actually writing data to a file. It does all basic checks, removes SUID from the file, updates modification times and calls proper subroutines depending on whether we do direct IO or a standard buffered write.
它期望 inode 的mutex已经被获取,除非是不需要锁的块设备或其它对象。(这个在generic_file_aio_write里面的确获取了)
It expects i_mutex to be grabbed unless we work on a block device or similar object which does not need locking at all.
从内核源码来看,只要 __generic_file_aio_write 没有返回,对同一个inode的写入是排斥的。但是写了个多线程的程序,每次对文件APPEND 1MB数据,各写1G。检查后发现并不是写入互斥的。(求kernel hacker解答……)
只是,每次原子写入的数据大小到底是多少?这个值会影响到很多应用的正确性,比如,日志文件的写入一般是追加的,如果一次追加的数据多于这个值,那么多个进程写同一个日志文件会很BUGGY。
====
再有,write的原子性#2:进程a在调用write的期间,进程b是否可以从相同的文件中读取数据?
读取的时候,一路从 read -> vfs_read -> do_sync_read -> generic_file_aio_read 没有需要获取 i_mutex 的地方。再到 do_generic_file_read 这个函数的时候,就是各种内存页面的处理,包括从页表找出实际的页,或者从磁盘中读取、换页之类(这个过程中可能被schedule)。当页面可用的时候,调用传入的 file_read_actor,这个函数使用硬件体系相关的 __copy_to_user(to, from, n) ...
看起来写操作和读操作并不是互斥的,这个也比较符合平时对文件操作的逻辑。不过从上一个问题可以看出的是,write并不是原子的,它是一段一段往内核BUFF里面写的,在每一段完成之前,read获取到的这一段数据还是旧数据。
====
最后,接上个问题,调用write写文件的时候,写入顺序是否是按地址顺序写入?如果不是的话,read可能先读到一段旧数据,再读到一段新数据,这个会让人崩溃的……
在这里,[写入]有两层意思:a. 写入缓存; b. 刷回存储设备。
对于写入缓存,实际上就是从用户空间将数据拷贝到内核空间,调用的是 __copy_from_user(to,from,n) 这个宏。这个宏的实现是在 arch 目录下,不同硬件平台的具体汇编代码。虽然没有去具体了解每个平台的实现方式(代价太大了,各种汇编啊……),但是几乎可以肯定,绝大部分平台下这个顺序是按照地址顺序写入的。虽然内核可以选择不顺序拷贝数据,但是开发者应该不会这么蛋疼吧……
对于刷回设备,调用的[应该](未考证,求证实)就是具体的fsync函数了,比如ext3下面是 fs/ext3/fsync.c 中的 ext3_sync_file 这个函数。这个由于跟具体设备相关,考证更困难了。。不过sandy同学举了个例子,磁带,就有可能是根据磁头目前的位置来刷写的,在有些时候逆向写效率更高(当然,同样未考证具体实现)。
应用程序调用read,实际上是从内核的缓存中获取数据的,所以一般的应用程序只需要关心 a. 写入缓存 的顺序就行了。从实现的合理性来判断,内核应该是按照顺序拷贝的。
我在stackoverflow.com问了最后这个问题,有人推荐了 http://flamingspork.com/talks/ 里面的 Eat My Data: How Everybody Gets File IO Wrong ,值得一看。
好吧。今天一整天就废在这上面了,本篇暂时到此为止,欢迎各种评论拍砖。
欢迎扫码关注:
转载请注明出自 ,如是转载文则注明原出处,谢谢:)
RSS订阅地址: https://www.felix021.com/blog/feed.php 。