streamfilesink inprocess状态时间较长 stale file handle 原因

转载

mob64ca13faa4e6 2024-02-12 22:00:23

log里报：

1:M 13 Jan 2022 21:00:43.015 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
1:M 13 Jan 2022 21:00:52.137 # Fail to fsync the AOF file: Stale file handle
1:M 13 Jan 2022 21:12:24.529 # Error writing to the AOF file: Stale file handle

Stale file handle是一个文件系统的普遍问题，主要是linode变了，但外部没变。相当于元信息没了，但外部文件还在，成了野指针。

而特别在nfs里又是个普遍问题。

1.问题描述

这个英文的虽然说的NFS，但是实际上不仅仅NFS系统会遇到这个问题。当然如果你的系统就是NFS的，那么你排查这个问题会简单很多。本文不是针对NFS系统。

Stale NFS file handle具体是什么意思，为还没有看到中文是怎么解释的。英文的意思：文件是变得不可用了。当使用ls， stat，cat等等命令去查看文件的时候会发现无法看到文件的任何信息。

有个问题大家都很熟悉的，就是写程序的时候经常会避免野指针的问题，这个问题与此类似，只是这个野指针是存在于磁盘上的。

2.复现该问题的方法

要重现这个问题不是一般般的简单的，光靠运气会搞死人的。下面给出一种为知道的重现方法：

假设文件系统是/dev/sda2，则可以进行如下操作：

debugfs -w /dev/sda2

这时候会进入到debugfs的命令行中，假设坏掉的文件是/dev/sda2中的file文件，那么使用

stat ./file 命令查看出文件对应的inode，假设是62345

然后使用命令 mi <62345>

修改该文件的Link count数为0

然后quit。

这时候ls去看/dev/sda2的file文件就会出现Stale NFS file handle的报错了（如果不出现，重启系统必定出现）。

3.问题分析

从重现方法就大概知道，是Link count计数不对导致的这个问题。这个报错是系统保持来的。是的没错，就是文件的引用计数出现问题了。一般的，对linux系统来说，文件的引用计数为0表示文件被删除了。这个时候它占用的inode节点要被回收，被它所在目录要去除改文件的目录项。（不清楚文件存储方法的请自行查阅）。

然后，通过debugfs的修改，我们发现，目录还是有这个文件的目录项，但是由于文件的引用计数是0，文件系统认为改文件已经被删除了，那么就意味着根据目录项的该文件的记录是找不到该文件的，即这个目录项是一个野指针。