☰

文件系统命令仅挂在目录中的特定文件上

tag-icon • tag-icon linux shell virtual-machine nfs
文件系统命令仅挂在目录中的特定文件上

我在通过 NFS 安装的 VM 上有一个文件系统。此问题在 VM 本身上复制，因此我不再认为它与 NFS 有关。

文件系统的格式为：

/
  dir_a
    file_a
    file_b
    ...
    special.csv
  dir_b
    file_a
    file_b
    ...
    special.csv

每个目录下的这些文件几乎同时写入，special.csv最后写入。special.csv写法如下：

import pandas as pd
import os
df = pd.Dataframe()
# populate small dataframe (~30 rows of 5 columns of ints/doubles and 1 column of 60char str)
hidden_path = os.path.join(base_dir, '.special.csv')
actual_path = os.path.join(base_dir, 'special.csv')
df.to_csv(hidden_path, index=False)
os.replace(hidden_path, actual_path)

运行时rm -rf dir_a，我注意到它花费的时间比预期要长得多（对于包含约 30 个文件、总大小约 5GB 的目录，大约为分钟数量级）。经过进一步调查发现，除了该special.csv文件之外，目录中的所有其他文件都被立即删除。

运行时strace -T rm -Rf special.csv发现unlinkat系统调用正在~89s完成。

我不确定为什么该special.csv文件的行为与目录中的其他文件不同，特别是因为目录中的其他文件是以类似的方式创建的（关于os.replace）。我能想到的唯一区别是其他文件在写入之前被触及，并且它们是使用pyarrow.

似乎任何类型的修改或删除都special.csv需要更长的时间，例如touch special.csv可能需要一分钟多的时间。然而，如果我touch special.csv然后rm special.csv，只是touch special.csv需要很长时间，而这rm special.csv是瞬间的。不确定这是否与磁盘缓存有关。

编辑： 存储介质是Linux文件系统挂载而不是NAS。根本原因尚未确定，但重新启动存储介质似乎已解决了该问题。

答案1

我建议仔细查看您使用 NFS 连接的 NAS。它有“垃圾”能力吗？是否已开启？

NFS 挂载实际上并不删除文件，而是请求远程系统删除它们。 NAS（很可能）将这些大文件移至垃圾箱，以便 NAS 稍后可以根据需要将其恢复。远程系统向您的 NFS 报告文件已被删除，但此时它们实际上正在删除过程中。

相关内容