Bash 会与文件系统不同步吗?

Bash 会与文件系统不同步吗?

我可能没有正确表述我的问题,但我会尽力解释我遇到的症状。首先,为了便于理解,我正在运行 Ubuntu 服务器(无 GUI),版本 12.04.3 LTS(根据 lsb_release 实用程序)。我通常在 tmux 中完成所有工作,通过 Putty 连接到服务器,并使用 vim 进行所有文本编辑。

现在来看看症状。由于我使用 tmux,我通常会一直打开几个窗口。其中一个窗口包含我一直在使用的节点服务器,它位于我的用户帐户主目录(具体来说,~/battleship)的子目录中。该服务器与我也使用 nginx 在服务器上托管的网页进行交互,并且所有网站代码都位于其中/usr/share/nginx/www/bs(我还打开了一个单独的窗口来编辑客户端源代码)。发生的事情是,在几个小时内让服务器窗口处于空闲状态且未进行任何操作后,它似乎不同步了。我可以运行ls并查看文件,并且可以打开它们进行编辑(vim server.js)。但是,当我这样做时,无论我进行更改并保存还是立即退出,当我ls再次运行时,我都会看到一个 .server.js.swp 文件,并且我的任何更改(如果我做了任何更改)都不会保留。如果我移出该目录然后再​​返回,它会自行修复 - 我可以打开文件并成功编辑它,而不会在关闭它时留下 .swp。我提到了客户端来源的一半,因为我注意到这个没有发生在 /www 文件夹中(大概是因为它在我的用户帐户的主目录之外)。

读完那段文字后,我的问题是:有谁知道为什么这种情况正在发生,如何防止它发生?我只能想象有某种方法,考虑到这不是我通过 Putty 连接并使用 tmux/vim 的唯一 Linux 服务器,但它是唯一发生这种奇怪行为的服务器。任何帮助都将不胜感激。

注意:我用 bash、tmux 和 putty 标记了这个问题,因为我假设其中一个是罪魁祸首,但我真的不知道哪一个。

更新:cat /proc/mount这是Gilles 要求的输出(尽管包含我的用户名以及ecryptfs_fnek_sig和的值ecryptfs_sig,因为虽然我实际上不知道这两个东西是什么,但它们似乎与加密有关,而且谨慎一点总是好的)。

rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=2008532k,nr_inodes=502133,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=807840k,mode=755 0 0
/dev/disk/by-uuid/2da27263-f079-47ba-90ad-66e4c3a53810 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
/home/[username]/.Private /home/[username] ecryptfs rw,relatime,ecryptfs_fnek_sig=[censored],ecryptfs_sig=[censored],ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0

更新 2:以下是 的输出uname -a

Linux [server-name] 3.5.0-39-generic #60~precise1-Ubuntu SMP Wed Aug 14 15:38:41 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

更新 3:我已完成一次内存测试。这是上述测试的结果。似乎已经完成,没有任何错误,所以我不确定它最终是否会有所帮助。您还可以查看一些硬件详细信息,以防万一有帮助。

答案1

我见过的唯一类似情况是删除目录并创建新目录。AIX 和 Solaris 几年前就出现过这个问题。如果您在已删除的目录中打开 shell 会话,您可能会得到不可预测的结果,看起来像文件系统不同步。

bash1: mkdir test1
bash2: cd test1
bash1: touch test1/testfile
bash1: ls test1
testfile
bash2: ls
testfile
bash1: rm -rf test1
bash2: ls
???(unknown results)???

加密文件系统听起来也值得审查。你试过未加密的文件系统吗?

抱歉,我暂时还不能发表评论。积分不够。

答案2

值得一提的是,该问题是由 ls 命令显示的,而不是由 bash 显示的。

您看到文件这一事实意味着它仍在那里。没有任何东西与其他任何东西不同步,并且无论运行多少次同步都不会阻止您使用相关文件系统数据的唯一缓存副本。同步只会导致数据提交到永久存储,而不会改变您对它的视图。

您是否在使用 VIM 会话?我不知道 VIM 会话,自己从未使用过,但我认为 tmux 可能会导致 VI 会话管理器无法意识到文件已关闭并继续跟踪您的更改。

答案3

您可以尝试在 bash 命令之间运行同步命令。

sync - flush file system buffers

我自己从未发现需要这样做,但至少认识一个人,他几乎每输入一条命令就输入一次!一定是过去磁盘速度慢导致的。

互联网上似乎很少讨论该sync命令的使用。以下是该命令的简短手动输入链接synchttp://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html

sync确保数据从内存写入磁盘设备。如果磁盘设备本身速度较慢或出现问题,数据可能仍位于磁盘设备缓存中,而不会写入磁盘。

您正在运行 ubuntu 服务器...那是您桌面上的机器吗?还是在云端?还是...别的什么?请参见此处: https://serverfault.com/questions/534627/what-does-the-sync-command-do内存与磁盘的同步速度很慢,这可能与硬盘问题有关,或者可能与 Amazon AWS 较小的实例有关。

相关内容