Kann bash nicht mit dem Dateisystem synchronisiert werden?

12

Ich werde meine Frage vielleicht nicht richtig formulieren, aber ich werde mein Bestes tun, um die Symptome zu erklären, die ich durchmache. Zuerst führe ich für den Kontext einen Ubuntu-Server (keine GUI), Version 12.04.3 LTS (gemäß dem Dienstprogramm lsb_release). Im Allgemeinen mache ich alle meine Arbeit in tmux, ich verbinde mich über Putty mit dem Server, und ich benutze vim für alle meine Textbearbeitung.

Nun zu den Symptomen. Da ich tmux verwende, habe ich normalerweise immer ein paar Fenster offen. Einer von ihnen beherbergt einen Knotenserver, mit dem ich gespielt habe, und er befindet sich in einem Unterverzeichnis meines Benutzerkontos (speziell ~/battleship ). Der Server interagiert mit einer Web-Seite, die ich auch vom Server gehostet habe, mit nginx, und der gesamte Code der Website lebt in /usr/share/nginx/www/bs (ich habe auch ein separates Fenster geöffnet, um die Client-Quelle zu bearbeiten). Was passiert, ist, dass nach einigen Stunden des Verlassens des Serverfensters im Leerlauf und unangetastet scheint, nicht mehr synchron zu sein. Ich kann ls ausführen und die Dateien sehen, und ich kann sie zum Bearbeiten öffnen ( vim server.js ). Wenn ich das tue, unabhängig davon, ob ich Änderungen vornehme oder einfach sofort auschecke, wenn ich ls erneut ausführe, sehe ich eine .server.js.swp Datei und keine meiner Änderungen (wenn ich welche gemacht habe) fortdauern. Wenn ich aus diesem Verzeichnis heraus und dann wieder zurück gehe, repariert es sich selbst - ich kann die Datei öffnen und erfolgreich bearbeiten, ohne ein .swp zu hinterlassen, wenn ich es schließe. Ich erwähnte die Client-Quelle die Hälfte der Dinge, weil ich bemerkt habe, dass nicht im Ordner / www passiert (vermutlich, weil es sich außerhalb des Home-Verzeichnisses meines Benutzerkontos befindet).

Nach dieser Textwand lautet meine Frage: Weiß jemand warum das geschieht und wie kann man das verhindern? Ich kann mir nur vorstellen, dass es einen Weg gibt, wenn man bedenkt, dass dies nicht der einzige Linux-Server ist, mit dem ich über Putty eine Verbindung herstelle und tmux / vim benutze, und doch ist es das einzige, wo dieses seltsame Verhalten passiert. Jede Hilfe wäre willkommen.

Hinweis: Ich habe dies mit bash, tmux und putty getaggt, weil ich annehme, dass einer von ihnen schuld ist, aber ich habe wirklich keine Ahnung, was.

Update: Dies ist die Ausgabe von cat /proc/mount wie von Gilles angefordert (allerdings mit meinem Benutzernamen und den Werten von ecryptfs_fnek_sig und ecryptfs_sig zensiert, weil ich es eigentlich nicht weiß Was diese beiden Dinge sind, scheinen sie verschlüsselungsrelevant und besser als Nachsicht zu sein.

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

Update 2: Hier ist die Ausgabe von 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

Update 3: Ich habe einen memtest bestanden. Das ist das Ergebnis dieses Tests . Scheint, ohne Fehler abgeschlossen zu haben, also bin ich nicht sicher, ob es am Ende mit irgendetwas helfen wird. Sie können auch einige Hardwaredetails sehen, falls das irgendwie hilft.

    
Alex 06.09.2013, 22:13
quelle

3 Antworten

1

Die einzige Erfahrung, die ich mit so etwas gesehen habe, war, als ein Verzeichnis entfernt und ein neues erstellt wurde. AIX und Solaris hatten dieses Problem schon vor Jahren. Wenn Sie eine offene Shell-Sitzung in einem entfernten Verzeichnis haben, können Sie unvorhersehbare Ergebnisse erhalten, die wie ein Dateisystem aussehen, das nicht mehr synchron ist.

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

Das verschlüsselte Dateisystem klingt nach etwas, das auch überprüft werden sollte. Hast du es in einem unverschlüsselten Dateisystem versucht?

Leider kann ich noch keine Kommentare posten. Nicht genug Punkte.

    
Michael McGarrah 18.03.2014 17:37
quelle
0

Sie könnten versuchen, den sync-Befehl zwischen Ihren bash-Befehlen auszuführen.

sync - flush file system buffers

Ich habe das nie selbst gefunden, aber ich habe mindestens eine Person gekannt, die es praktisch wie jeden zweiten Befehl eingegeben hat! Muß in der Vergangenheit mit langsamer Festplatte schlecht gebrannt worden sein.

Das Internet scheint eine Diskussion über die Verwendung des Befehls sync zu führen. Hier ist ein Link zu einem sehr kurzen manuellen Eintrag für sync : Link

sync garantiert, dass Daten vom Speicher auf das Festplattenlaufwerk geschrieben werden. Die Daten könnten sich immer noch im Cache des Plattengeräts befinden und nicht auf die Festplatte geschrieben werden, wenn das Plattenlaufwerk selbst langsam ist oder ein Problem hat.

Sie führen einen Ubuntu-Server aus. . . Ist das eine Maschine auf Ihrem Desktop? Oder ist es in einer Wolke? Oder . . . etwas anderes? Siehe hier: link langsame Synchronisierung vom Speicher auf die Festplatte, die mit Festplattenproblemen ODER vielleicht mit Amazon verbunden ist AWS kleinere Instanzen.

    
gaoithe 23.03.2014 22:52
quelle
0

FWIW Das Problem wird durch den Befehl ls angezeigt, nicht durch bash.

Die Tatsache, dass Sie die Datei sehen, bedeutet, dass sie immer noch da ist. Nichts ist mit anderen Dingen nicht synchron und keine Menge an laufender Synchronisierung hindert Sie daran, die einzige zwischengespeicherte Kopie der relevanten Dateisystemdaten zu verwenden. Die Synchronisierung bewirkt lediglich, dass die Daten in den permanenten Speicher übertragen werden, ohne dass Sie Ihre Ansicht ändern.

Verwenden Sie VIM-Sitzungen? Ich kenne die VIM-Sitzung nicht, habe sie nie selbst benutzt, aber ich kann mir vorstellen, dass tmux dazu führen könnte, dass der VI-Sitzungsmanager nicht erkennt, dass die Datei geschlossen ist und dass die Änderungen verfolgt werden.

    
Johan 15.04.2014 15:11
quelle

Tags und Links