☰

mv 命令中的奇怪行为 - 也许是开放系统调用问题？

tag-icon • tag-icon fedora filesystems rhel rename open-files
mv 命令中的奇怪行为 - 也许是开放系统调用问题？

我注意到“mv”命令的非常奇怪的行为可能（或可能不）与“open”系统调用相关。我们正在运行 RedHat v5。有两个独立的存储设备，一个安装到“/diskTo”，另一个安装到“/diskFrom”（对于本例）。

在正常操作中，我们将数百个（如果不是数千个）文件从 /diskFrom 移动（移动）到 /diskTo。大多数文件移动良好。然而，在 1000 个文件中，有 1-5 个失败。该失败是权限被拒绝错误。当我们检查文件目的地时，一个文件存在，但 inode 内容是垃圾。例如，时间戳是垃圾（“1969”，但有所不同），权限是“0”。

因此，我认为我们应该对 mv 命令运行 strace 并捕获失败的输出。这是我发现的：

munmap(0x2b0328770000, 4096)            = 0
geteuid()                               = 31169
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff90de9500) = -1 ENOTTY (Inappropriate ioctl for device)
stat("/diskTo/foo.dat", 0x7fff90de95d0) = -1 ENOENT (No such file or directory)
lstat("/diskFrom/bar.dat", {st_mode=S_IFREG|0444, st_size=234632119, ...}) = 0
lstat("/diskTo/foo.dat", 0x7fff90de9370) = -1 ENOENT (No such file or directory)
rename("/diskFrom/bar.dat", "/diskTo/foo.dat") = -1 EXDEV (Invalid cross-device link)
unlink("/diskTo/foo.dat") = -1 ENOENT (No such file or directory)
open("/diskFrom/bar.dat", O_RDONLY|O_NOFOLLOW) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=234632119, ...}) = 0
open("/diskTo/foo.dat", O_WRONLY|O_CREAT|O_EXCL, 0400) = -1 EEXIST (File exists)
write(2, "mv: ", 4)                     = 4
write(2, "cannot create regular file `/diskTo"..., 76) = 76
write(2, ": File exists", 13)           = 13
write(2, "\n", 1)                       = 1

如您所见，取消链接被调用，它返回-1，这表明该文件不存在。然后，“mv”尝试打开文件并收到 EEXIST 错误。但该文件不可能存在！我不会在这里展示这一点，但创建此测试用例的脚本正在使用唯一的数字来构建目录 - 因此该文件不太可能（如果不是不可能）真正存在。更不用说，取消链接证明该文件不存在。

这可能是一个如何解决的问题打开正在创建inode 内容？我不知道现在该看哪里。也许更多地研究“mv”，或者“open”系统调用？

答案1

在磁盘上运行一个完整的文件fsck(8)，看起来有些混乱的索引节点漂浮在周围（或者是动态创建的）。运行badblocks(8)看看磁盘是否有问题。查看日志（或其他磁盘诊断）是否有相关说明。

所有软件都是最新的吗？

这些是什么文件系统？还有其他diskTo可能干扰的活动吗？磁盘是否几乎已满（空间、索引节点）？日志中还有其他报告吗？

还要彻底检查机器，内存错误可能导致类似的情况，也可能导致过热。这是一个不太可能的原因，但将其拆开并检查风扇并没有什么坏处，因此工作正常，并且内部没有足够的土壤来容纳中型农场。如果机器未连接到 UPS 或类似设备，电压波动也可能导致随机错误。

相关内容