Может ли bash выйти из синхронизации с файловой системой?

Возможно, я не правильно формулирую свой вопрос, но я приложу все усилия, чтобы объяснить симптомы, которые я испытываю. Во-первых, для контекста я использую сервер Ubuntu (без графического интерфейса), версия 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 (предположительно, потому что он находится за пределами домашнего каталога моей учетной записи пользователя).

После этой стены текста у меня возникает вопрос: кто-нибудь знает, почему это происходит и как это предотвратить? Я могу только представить, что есть какой-то способ, учитывая, что это не единственный сервер Linux, к которому я подключаюсь через Putty и использую tmux / vim, и все же это единственный, где происходит это странное поведение. Любая помощь будет оценена.

Примечание: я пометил это с помощью bash, tmux и putty, потому что я предполагаю, что один из них виноват, но я действительно понятия не имею, что.

Обновление: это вывод, cat /proc/mountзапрошенный Жилем (хотя с моим именем пользователя и значениями 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: я прошел проход memtest. Это результат указанного теста . Кажется, что все закончилось без ошибок, поэтому я не уверен, что в конечном итоге это поможет. Вы также можете увидеть некоторые детали оборудования в случае, если это поможет в любом случае.

Единственный опыт, который я видел с чем-то подобным, был, когда каталог удалялся и создавался новый. AIX и Solaris имели эту проблему лет назад. Если у вас есть открытый сеанс оболочки в удаленном каталоге, вы можете получить непредсказуемые результаты, которые выглядят как синхронизация файловой системы.

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)???

Зашифрованная файловая система звучит как что-то, что нужно пересмотреть. Вы пробовали в незашифрованной файловой системе?

Извините, я не могу оставлять комментарии. Недостаточно очков.

Вы можете попробовать запустить команду sync между вашими командами bash.

sync - flush file system buffers

Я никогда не находил в этом необходимости, но знал хотя бы одного человека, который вводил его практически как каждую вторую команду! Должно быть, в прошлом сильно сгорел на медленном диске.

Кажется, в интернете обсуждается вопрос об использовании syncкоманды. Вот ссылка на очень короткую ручную запись для sync: http://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html

syncгарантирует, что данные записываются из памяти на диск. Данные могут все еще находиться в кэш-памяти дискового устройства и не записываться на диск, если само дисковое устройство работает медленно или имеет проблемы.

Вы работаете на сервере Ubuntu. , , это машина на вашем рабочем столе? Или это в облаке? Или . , , что-то другое? См. Здесь: /server/534627/what-does-the-sync-command-do медленная синхронизация из памяти на диск, связанная с проблемами жесткого диска ИЛИ, возможно, с мелкими экземплярами Amazon AWS.

FWIW проблема отображается командой ls, а не bash.

Тот факт, что вы видите файл, означает, что он все еще там. Ничто не синхронизировано ни с чем другим, и никакая синхронизация не помешает вам использовать единственную кэшированную копию соответствующих данных файловой системы. синхронизация просто заставит данные фиксироваться в постоянном хранилище, а не изменит ваше представление об этом.

Вы используете сеансы VIM? Я не знаю сессию VIM, никогда не использовал ее сам, но я думаю, что tmux может привести к тому, что менеджер сессий VI не поймет, что файл закрыт, и будет следить за вашими изменениями.