Bash có thể không đồng bộ với hệ thống tập tin?

Tôi có thể không nói đúng câu hỏi của mình, nhưng tôi sẽ cố hết sức để giải thích các triệu chứng tôi gặp phải. Đầu tiên, đối với ngữ cảnh, tôi đang chạy một máy chủ Ubuntu (không có GUI), phiên bản 12.04.3 LTS (theo tiện ích lsb_release). Tôi thường làm tất cả công việc của mình trong tmux, tôi kết nối với máy chủ qua Putty và tôi sử dụng vim cho tất cả các chỉnh sửa văn bản của mình.

Bây giờ cho các triệu chứng. Vì tôi sử dụng tmux, tôi thường có một vài cửa sổ mở mọi lúc. Một trong số họ chứa một máy chủ nút mà tôi đã chơi xung quanh và nó sống trong một thư mục con của nhà tài khoản người dùng của tôi (cụ thể, ~/battleship). Máy chủ tương tác với một trang web tôi cũng đang lưu trữ trên máy chủ bằng nginx và tất cả các mã trang web đều tồn tại /usr/share/nginx/www/bs(Tôi cũng giữ một cửa sổ riêng mở để chỉnh sửa nguồn máy khách). Điều gì xảy ra là sau vài giờ rời khỏi cửa sổ máy chủ không hoạt động và không được chạm, nó dường như không đồng bộ. Tôi có thể chạy lsvà xem các tệp và tôi có thể mở chúng để chỉnh sửa ( vim server.js). Tuy nhiên, khi tôi làm điều đó, bất kể tôi có thay đổi và lưu hay thoát ngay lập tức, khi tôi chạylsmột lần nữa tôi thấy tệp .server.js.swp và không có thay đổi nào của tôi (nếu tôi thực hiện). Nếu tôi di chuyển ra khỏi thư mục đó và sau đó quay lại, nó sẽ tự sửa - tôi có thể mở tệp và chỉnh sửa thành công mà không để lại một .swp khi tôi đóng nó. Tôi đã đề cập đến một nửa nguồn khách hàng vì tôi nhận thấy rằng điều này không xảy ra trong thư mục / www (có lẽ vì nó nằm ngoài thư mục chính của tài khoản người dùng của tôi).

Sau bức tường văn bản đó, câu hỏi của tôi là: Có ai biết tại sao điều này lại xảy ra không, và làm thế nào để ngăn chặn nó? Tôi chỉ có thể tưởng tượng có một số cách, xem xét rằng đây không phải là máy chủ Linux duy nhất tôi kết nối qua Putty và sử dụng tmux / vim trên đó, và đây là nơi duy nhất xảy ra hành vi kỳ lạ này. Bất kỳ trợ giúp sẽ được đánh giá cao.

Lưu ý: Tôi đã gắn thẻ này bằng bash, tmux và putty vì tôi cho rằng một trong số chúng là đáng trách nhưng tôi thực sự không có manh mối nào.

Cập nhật: Đây là đầu ra cat /proc/mounttheo yêu cầu của Gilles (mặc dù với tên người dùng của tôi và các giá trị ecryptfs_fnek_sigvà ecryptfs_sigbị kiểm duyệt, bởi vì trong khi tôi thực sự không biết hai thứ đó là gì, chúng có vẻ liên quan đến mã hóa và an toàn tốt hơn là xin lỗi).

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

Cập nhật 2: Đây là đầu ra của 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

Cập nhật 3: Tôi đã hoàn thành một vượt qua memtest. Đây là kết quả của bài kiểm tra nói . Có vẻ như đã hoàn thành mà không có lỗi, vì vậy tôi không chắc liệu nó có giúp được gì không. Bạn cũng có thể thấy một số chi tiết phần cứng trong trường hợp giúp theo bất kỳ cách nào.

Trải nghiệm duy nhất tôi từng thấy với một thứ như thế này là khi một thư mục bị xóa và một thư mục mới được tạo. AIX và Solaris đã có vấn đề này nhiều năm trước. Nếu bạn có một phiên shell mở trong một thư mục bị xóa, bạn có thể nhận được kết quả không thể đoán trước trông giống như một hệ thống tệp không đồng bộ.

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

Hệ thống tập tin được mã hóa có vẻ như là một cái gì đó để xem xét là tốt. Bạn đã thử trong một hệ thống tập tin không được mã hóa?

Xin lỗi tôi không thể gửi bình luận nào. Không đủ điểm.

Bạn có thể thử chạy lệnh đồng bộ ở giữa các lệnh bash của mình.

sync - flush file system buffers

Bản thân tôi chưa bao giờ tìm thấy nhu cầu đó nhưng đã biết ít nhất một người đã gõ nó thực tế như mỗi mệnh lệnh thứ hai! Phải bị đốt cháy tồi tệ trong quá khứ với đĩa chậm.

Internet dường như là ánh sáng về thảo luận về việc sử dụng synclệnh. Đây là một liên kết đến mục nhập thủ công rất ngắn cho sync: http://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html

syncđảm bảo dữ liệu được ghi từ bộ nhớ vào thiết bị đĩa. Dữ liệu vẫn có thể nằm trong bộ nhớ đệm của thiết bị đĩa và không được ghi vào đĩa nếu bản thân thiết bị đĩa bị chậm hoặc có vấn đề.

Bạn đang chạy một máy chủ Ubuntu. . . đó là một máy trên máy tính để bàn của bạn? Hay là trong một đám mây? Hoặc là . . . thứ gì khác? Xem tại đây: /server/534627/what-does-the-sync-command-do đồng bộ hóa chậm từ bộ nhớ sang đĩa liên quan đến các sự cố đĩa cứng HOẶC có thể với các phiên bản nhỏ hơn của Amazon AWS.

FWIW vấn đề được hiển thị bằng lệnh ls, không phải bởi bash.

Thực tế là bạn thấy tập tin có nghĩa là nó vẫn còn đó. Không có gì không đồng bộ với bất cứ điều gì khác và không có số lượng đồng bộ hóa đang chạy sẽ ngăn bạn sử dụng bản sao được lưu trong bộ nhớ cache của dữ liệu hệ thống tệp có liên quan. đồng bộ hóa sẽ chỉ khiến dữ liệu cam kết lưu trữ vĩnh viễn, không thay đổi quan điểm của bạn về nó.

Bạn đang sử dụng phiên VIM? Tôi không biết phiên VIM, bản thân tôi không bao giờ sử dụng nó, nhưng tôi tưởng tượng tmux có thể khiến trình quản lý phiên VI không nhận ra tệp bị đóng và để theo dõi các thay đổi của bạn.