linux监控文件系统:inotify

p__n

官方介绍:https://man7.org/linux/man-pa...

inotify events
IN_ACCESS +
文件被访问 read, execve

IN_ATTRIB *
元数据该表,例如权限,timestamp,链接数,user/group ID等等。

IN_CLOSE_WRITE +
可写文件被关闭

IN_CLOSE_NOWRITE *
非可写的文件或者目录被关闭

IN_CREATE +
文件或者目录在监控目录中被创建(也就是说这个事件只可能在
监控目录时才可能产生)

IN_DELETE +
文件或目录在监控目录中被删除(同上)

IN_DELETE_SELF
监控的目录/文件本身被删除(如果一个对象被移动到其他文件系统,
此事件也会被触发),此外一个IN_IGNORED事件随后会产生在对应的watch descriptor上。这样我们就可以知道具体哪个监控的对象被删除了。

IN_MODIFY +
文件被修改 write, truncate

IN_MOVE_SELF
关注的文件/目录本身被move了。(目前不清楚具体事件指的是什么)

IN_MOVED_FROM +
当文件被rename时,产生在包含老文件名称的目录上。

IN_MOVED_TO +
当文件被rename时,产生在包含新文件名称的目录上。

例如官方的例子:
rename("dir1/myfile", "dir2/myfile");
对dir1产生IN_MOVED_FROM事件,对dir2产生IN_MOVED_TO事件,
对对myfile产生IN_MOVE_SELF事件。
inotify_event结构中的cookie字段在这里有用处,FROM和TO这连个事件的cookie值被设置为相同,为了将一次mv操作产生的多个事件关联到一起。

IN_OPEN *
文件或目录被打开。

IN_MOVE = IN_MOVED_FROM | IN_MOVED_TO.

IN_CLOSE = IN_CLOSE_WRITE | IN_CLOSE_NOWRITE

NOTE

  1. 由于event queue可能产生溢出,因此事件可能溢出。故可靠性要求高的程序需要周期性的进行一致性校核和重构。
  2. inotify可以和io复用机制一起使用(select poll epoll).
  3. 事件可能有合并操作产生,故不能用inotify精确记录事件发生数目。
  4. rename操作保证事件的顺序(因为事件是由ordered queue存储)。
  5. 可以在目录/proc/[pid]/fdinfo目录下查看watch descriptors的详细信息。

Limitations and caveats

细节略,可直接查看原文。

BUGS

  • 文档中提到了一个关于watch descriptor重用的bug,当文件被删除或者文件系统被unmount,或者调用inotify_rm_watch取消监控,未读事件中对应的watch descriptor仍然是可读的,如果这个时候内核将watch descriptor分配给新的监控对象,就可能出现一个watch descriptor对应着两个对象,一个是删除监控但未读事件中存在,一个是新分配的监控对象,造成逻辑错误。文档中说这个错误出现的概率很低,目前没有收到相关的报告,故3.15版之前还没有处理这个可能的bug。

个人建议:可以将新增监控对象这个操作缓存起来,在每次read到没有数据时,确保当前event queue中不可能有过时的watch descriptor时,再进行监控操作分配新的wd,避免这个bug描述的情况产生。

阅读 793

科学告诉你什么是不可能的;工程则告诉你,付出一些代价,可以把它变成可行,这就是科学和工程不同的魅力。

396 声望
3 粉丝
0 条评论
你知道吗?

科学告诉你什么是不可能的;工程则告诉你,付出一些代价,可以把它变成可行,这就是科学和工程不同的魅力。

396 声望
3 粉丝
宣传栏