lock`，并处理inode限制

我有一种情况，我需要为并发控制创build数百个成千上万个0字节的locking文件。

我testing了使用以下方法创build它们：

for i in `seq 1 50000`; do touch "/run/lock/${i}.lock"; done

由于这些文件是0字节，所以在分区中没有任何空间。看着df -h ：

 Filesystem Size Used Avail Use% Mounted on tmpfs 50M 344K 49M 1% /run none 5.0M 0 5.0M 0% /run/lock none 246M 0 246M 0% /run/shm none 100M 0 100M 0% /run/user

0%数字在/run/lock行中根本不会改变。

但是，每个锁文件的内存大小平均增加大约1KB。我通过在/run/lock内创build70,000个锁文件之前和之后比较free -h发现了这一点。这种内存增加反映在实际内存使用情况（虚拟内存减去缓冲区/caching）中。

后来我发现这个1KB的增长很可能是由于inode。所以我使用df -i检查了inode的使用情况：

 Filesystem Inodes IUsed IFree IUse% Mounted on tmpfs 62729 322 62407 1% /run none 62729 50001 12728 80% /run/lock none 62729 1 62728 1% /run/shm none 62729 2 62727 1% /run/user

正如你所看到的，lockfiles增加了/run/lock分区内的inode。

我目前在Ubuntu上， /run安装不反映在/etc/fstab 。运行mount给我：

 tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) none on /run/shm type tmpfs (rw,nosuid,nodev) none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)

我有几个问题关于这个（但是第一个是最重要的）：

如何为/run/lock永久增加inode限制？所以这个限制幸存重启？
对我来说，创build自己的目录并在其上挂载tmpfs来代替使用/run/lock会更好吗？
每个分区的大小限制是否完全独立？即将文件存储在/run中似乎不会影响/run/lock ，反之亦然。
是从inode派生的1KB？我注意到当创build非空文件时，每个文件的基本块是4KB。
为什么/run给定tmpfs的文件系统types，但是/run/lock ， /run/shm ， /run/user给文件系统types为“none”，尤其是因为它们都是由TMPFS支持的？他们为什么不把它们都作为Filesystem列中的tmpfs ？
如果所有目录都是独立约束的，那么OOM杀手如何在有多个完整的TMPFS分区的情况下进行处理，每个分区的大小都是RAM的50％，还有哪些进程还在竞争RAM。显然，不能使用超过100％的内存。根据https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt提到系统会死锁。这是如何运作的？

回答你的一些问题，按顺序：

您可以在应用程序启动脚本中使用mount -o remount,nr_inodes=NUM /run/lock （以防uid = 0运行）。把相关的行添加到/ etc / fstab也是安全的，但是还没有testing过。
分离在这里是有意义的，因为在填满所有inode的情况下不会干扰系统的其余部分。
是的，完全独立。
[…]
使用虚拟（基于非块设备的）文件系统，您可以将任何设备作为设备放在mount命令中，这只是重要的types。
[…]

不知道您的应用程序是否通过打开空文件（以及多长时间）来创build空文件，但您也可以考虑增加打开文件的限制（检查ulimit ），以避免耗尽。

你正在朝着错误的方向前进。您可以使用文件系统语义来强化一致性。

当你想读取一个文件，只需打开并阅读。您应该始终使用open ，永远不会access此操作。如果你正在使用一个PHP库来做到这一点，检查它只是调用open而不是access文件 – 但fopen应该正常工作。
当你想刷新或创build一个新的文件，你执行以下操作： –
- 使用临时文件创build机制创build一个新文件。如果不存在 – 创build一个不太可能存在的新文件名（filename.XXXXXX，其中X用随机字符replace）。确保在O_EXCL中打开。
- 将相关数据写入文件。
- 重命名文件的旧文件的名称。

这在操作上是安全的，因为重命名被定义为primefaces的。打开文件的阅读器将看到旧文件或新文件 – 但从来没有一个不存在的caching文件。

在最糟糕的情况下，每个文件的许多并发检查将会有很多作者短暂地重写。但是这种方式比对每个文件使用文件locking要便宜。

或者，不要为每个文件都有一个锁文件 – 实际上只需要直接locking每个单独的caching对象。我仍然不认为这会扩大规模。

在这种情况下使用rename和link语义保证了与caching的一致性，并且比locking文件更便宜。