Bash può non sincronizzarsi con il filesystem?

Potrei non esprimere correttamente la mia domanda, ma farò del mio meglio per spiegare i sintomi che sto vivendo. Innanzitutto, per il contesto, sto eseguendo un server Ubuntu (senza GUI), versione 12.04.3 LTS (secondo l'utility lsb_release). In genere faccio tutto il mio lavoro in tmux, mi collego al server tramite Putty e utilizzo vim per tutte le mie modifiche al testo.

Ora per i sintomi. Da quando uso tmux, di solito ho sempre alcune finestre aperte. Uno di questi ospita un server nodo con cui sto giocando, e vive in una sottodirectory della casa del mio account utente (in particolare ~/battleship). Il server interagisce con una pagina web che sto ospitando anche fuori dal server usando nginx, e tutto il codice del sito Web vive /usr/share/nginx/www/bs(tengo anche aperta una finestra separata per modificare l'origine del client). Quello che succede è che dopo alcune ore di lasciare la finestra del server inattiva e intatta, sembra non essere sincronizzata. Posso correre lse vedere i file e posso aprirli per la modifica ( vim server.js). Quando lo faccio, tuttavia, indipendentemente dal fatto che apporti modifiche e salvi o che esca all'istante, quando corrolsdi nuovo vedo un file .server.js.swp e nessuna delle mie modifiche (se ne ho apportata una) persiste. Se esco da quella directory e poi rientro, si risolve da solo: posso aprire il file e modificarlo correttamente, senza lasciare un .swp quando lo chiudo. Ho citato la metà delle cose del client perché ho notato che ciò non accade nella cartella / www (presumibilmente perché è al di fuori della home directory del mio account utente).

Dopo quel muro di testo, la mia domanda è questa: qualcuno sa perché questo sta accadendo e come prevenirlo? Posso solo immaginare che c'è un modo, considerando che questo non è l'unico server Linux a cui mi connetto tramite Putty e su cui uso tmux / vim, eppure è l'unico in cui si verifica questo strano comportamento. Qualsiasi aiuto sarebbe apprezzato.

Nota: l'ho etichettato con bash, tmux e putty perché presumo che sia colpa di uno di loro, ma non ne ho idea.

Aggiornamento: questo è l'output cat /proc/mountrichiesto da Gilles (anche se con il mio nome utente e i valori di ecryptfs_fnek_sige ecryptfs_sigcensurato, perché mentre non so davvero quali siano queste due cose, sembrano legate alla crittografia e più sicure che dispiaciute).

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

Aggiornamento 2: ecco l'output di 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

Aggiornamento 3: ho completato un passaggio di memtest. Questo è il risultato di detto test . Sembra aver completato senza errori, quindi non sono sicuro che finirà per aiutare con qualcosa. Puoi anche vedere alcuni dettagli hardware nel caso in cui ciò aiuti in alcun modo.

L'unica esperienza che ho visto con qualcosa del genere è stata quando una directory veniva rimossa e ne veniva creata una nuova. AIX e Solaris avevano questo problema anni fa. Se si dispone di una sessione di shell aperta in una directory rimossa, è possibile ottenere risultati imprevedibili che sembrano un file system non sincronizzati.

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

Anche il file system crittografato sembra qualcosa da rivedere. Hai provato in un file system non crittografato?

Spiacenti, non posso ancora pubblicare commenti. Non abbastanza punti.

Potresti provare a eseguire il comando sync tra i tuoi comandi bash.

sync - flush file system buffers

Non ne ho mai trovato la necessità, ma ho conosciuto almeno una persona che l'ha digitata praticamente come ogni secondo comando! Deve essere stato bruciato male in passato con disco lento.

Internet sembra essere leggero nella discussione sull'uso del synccomando. Ecco un link per l'inserimento manuale molto breve di sync: http://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html

syncgarantisce che i dati vengano scritti dalla memoria sul dispositivo disco. I dati potrebbero essere ancora nella memoria cache del dispositivo disco e non scritti sul disco se il dispositivo disco stesso è lento o presenta un problema.

Stai eseguendo un server Ubuntu. . . è una macchina sul tuo desktop? O è in una nuvola? O . . . qualcos'altro? Vedi qui: /server/534627/what-does-the-sync-command-do sincronizzazione lenta dalla memoria al disco associata a problemi del disco rigido O forse con istanze più piccole di Amazon AWS.

FWIW il problema viene visualizzato dal comando ls, non da bash.

Il fatto che vedi il file significa che è ancora lì. Nulla è non sincronizzato con qualcos'altro e nessuna quantità di sincronizzazione in esecuzione ti impedirà di utilizzare l'unica copia memorizzata nella cache dei dati del file system pertinenti. la sincronizzazione causerà solo il commit dei dati nella memoria permanente, non cambierà la tua visione di esso.

Stai usando sessioni VIM? Non conosco la sessione VIM, non l'ho mai usata da solo, ma immagino che tmux potrebbe impedire al gestore della sessione VI di rendersi conto che il file è chiuso e di tenere traccia delle modifiche.