Bash, dosya sistemiyle senkronize olabilir mi?

Sorumu doğru bir şekilde ifade etmiyor olabilirim, ancak yaşadığım belirtileri açıklamak için elimden geleni yapacağım. İlk olarak, bağlam için, bir Ubuntu sunucusu (GUI yok), sürüm 12.04.3 LTS (lsb_release yardımcı programına göre) çalıştırıyorum. Genelde tüm işlerimi tmux'da yapıyorum, Putty ile sunucuya bağlanıyorum ve tüm metin düzenlemelerim için vim kullanıyorum.

Şimdi belirtiler için. Tmux kullandığım için genellikle her zaman açık birkaç pencerem var. Bunlardan birinde oynadığım bir düğüm sunucusu var ve kullanıcı hesabımın evinin (özellikle ~/battleship) bir alt dizininde yaşıyor . Sunucu aynı zamanda nginx kullanarak sunucu dışında barındıran bir web sayfası ile etkileşime giriyor ve tüm web sitesi kodu yaşıyor /usr/share/nginx/www/bs(Ayrıca istemci kaynağını düzenlemek için ayrı bir pencere açık tutuyorum). Olan şey, sunucu penceresini boşta ve dokunulmamış bıraktıktan birkaç saat sonra, senkronizasyondan düşüyor gibi görünüyor. lsDosyaları çalıştırabilir ve görebilirim ve düzenlemek için açabilirim ( vim server.js). Ancak bunu yaptığımda, değişiklik yapıp kaydetmememe veya kaydetmeme veya hemen bırakmamıza bakılmaksızın, çalıştırdığımdalsYine bir .server.js.swp dosyası görüyorum ve yaptığım değişikliklerin hiçbiri kalmadı. Eğer o dizinin dışına çıkar ve sonra geri gelirse, kendi kendini düzeltir - Dosyayı açıp kapattığımda bir .swp arkasında bırakmadan başarıyla düzenleyebilirim. Bu fark ettik çünkü şeylerin müşteri kaynağı yarısını söz etmez (muhtemelen çünkü benim kullanıcı hesabının ev dizininin 's dışında) / www klasörüne olur.

Bu metin duvarından sonra sorum şu: Bunun neden olduğunu ve nasıl önleneceğini bilen var mı? Putty ile bağlandığım ve tmux / vim kullandığım tek Linux sunucusu olmadığını düşünerek bir yol olduğunu hayal edebiliyorum ve yine de bu garip davranışın gerçekleştiği tek şey. Herhangi bir yardım mutluluk duyacağız.

Not: Bunu bash, tmux ve macunla etiketledim çünkü bunlardan birinin suçlamak olduğunu varsayıyorum ama gerçekten hiçbir ipucum yok.

Güncelleme: Bu cat /proc/mountGilles tarafından istendiği gibi çıktı (benim kullanıcı adı ve değerleri ecryptfs_fnek_sigve ecryptfs_sigsansür de olsa , çünkü ben aslında bu iki şey ne olduğunu bilmiyorum, onlar şifreleme ile ilgili ve üzgünüm daha güvenli görünüyor).

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

Güncelleme 2: İşte çıktı 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

Güncelleme 3: Memtest sınavını tamamladım. Bu, söz konusu testin sonucudur . Hatasız tamamlanmış gibi görünüyor, bu yüzden bir şeyle yardımcı olacağından emin değilim. Herhangi bir şekilde yardımcı olması durumunda bazı donanım ayrıntılarını da görebilirsiniz.

bash putty tmux

— Alex
kaynak

Hayır, bash “dosya sistemiyle senkronizasyondan kurtulamaz” ve yine de olan bu değil. Daha çok dosya sistemi dosya sistemiyle senkronize olmuyor. Bu kesinlikle bir sorun ve garip bir sorun. Hangi dosya sistemlerini kullanıyorsunuz (çıktısını yazınız cat /proc/mounts)? Bu muhtemelen sanallaştırılmış bir sunucudur, ne tür bir sanallaştırma kullanıyor?

— Gilles 'SO- kötü olmayı bırak'

@Gilles Soruyu cat /proc/mountssizin için çıktıyı içerecek şekilde güncelledim . Umarım bu sizin için bir şey ifade edecektir - Linux için hala oldukça yeniyim, bu yüzden yaparak çok fazla öğrenme oldu ve henüz dosya sistemi ile uğraşmadım (kullanmanın ötesinde).

— Alex

Yani sorun bir ecryptfs dosya sisteminde oluşur. Bu, ecryptfs'de veya çekirdeğin diğer bölümlerinde veya varsa sanallaştırma yazılımında bir hataya veya bir donanım hatasına benziyor. Bu, kendi donanımınızda bir kutuda mı yoksa rafta mı çalışıyor yoksa bu, bazı barındırma sağlayıcılarıyla sanallaştırılmış bir sunucu mu? Çıktısı nedir uname -a? Donanımınızsa, bir konsolu takın ve bir sonraki önyüklemede bir bellek testi yapın. Barındırılıyorsa, barındırma sağlayıcınıza başvurun ve bu belirtileri açıklayın.

— Gilles 'SO- kötü olmayı bırak'

Çalıştırırsanız sudo syncdosyalar güncellenir mi?

— Braiam

Senkronizasyon komutunu deneyin. Ayrıca df cmd dir dir nerede yaşadığını göstermek için kullanışlıdır. / Proc / mount gibi ama daha okunabilir çıktı. Yap df -h /www ~/battleship /usr/share/nginx/www/bs. Encryptfs bağlantılarıyla ilgili sorun var mı? Bu diske yazma işlemleri için ekstra sw işlemesi gerekebilir, bu nedenle önbellekleme veya bununla ilgili bir şey var mı?

— Mart'ta gaoithe

Yanıtlar:

Böyle bir şeyle gördüğüm tek deneyim, bir dizinin kaldırılması ve yeni bir dizinin oluşturulmasıydı. AIX ve Solaris bu sorunu yıllar önce yaşadılar. Kaldırılan bir dizinde açık bir kabuk oturumunuz varsa, bir dosya sisteminin senkronizasyondan çıkmış gibi görünmesi beklenmeyen sonuçlar elde edebilirsiniz.

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

Şifrelenmiş dosya sistemi de gözden geçirilecek bir şey gibi geliyor. Şifrelenmemiş bir dosya sisteminde denediniz mi?

Üzgünüm henüz yorum gönderemiyorum. Yeterli puan yok.

— Michael McGarrah
kaynak

Bu, var olmayan bir varsayılan dizinin bırakıldığı ve içinde dosya oluşturmanın imkansız olduğu bir bash kabuğu ile ilgilidir.

— ubfan1

Bu küçük deneyi deneyebilirim, ancak bu noktada bunun bir ecryptfs sorunu olduğuna oldukça eminim. Söz konusu dizinler kesinlikle mevcut; cd .Bir süre sonra bir oturuma geri döndüğümde basit bir işten sonra normal çalışabilirim . Bu noktada dürüst olmak gerekirse, her şeyi yedeklemeyi, sunucuyu silmeyi ve şifrelenmiş bir dosya sistemi olmadan yeniden yüklemeyi düşünüyorum. Üzerinde uzaktan önemli bir şey tutmuyorum, bu yüzden dosyalarımı şifrelemekten endişe etmiyorum.

— Alex

Ubuntu'daki eCryptfs sürdürücüsü / yazarı hata raporlarına çok duyarlı. Bir çözüm bulamazsanız, muhtemelen ona sormaya veya bir hata raporu göndermeye değer.

— blujay

Senkronizasyon komutunu bash komutlarınız arasında çalıştırmayı deneyebilirsiniz.

sync - flush file system buffers

Buna hiç ihtiyacım olmadı ama pratik olarak her ikinci komut olarak yazan en az bir kişiyi tanıyordum! Yavaş disk ile geçmişte kötü yanmış olmalı.

İnternet, synckomutun kullanımıyla ilgili tartışmalara ışık veriyor gibi görünüyor . İşte için çok kısa manuel giriş bağlantısıdır sync: http://www.gnu.org/software/coreutils/manual/html_node/sync-invocation.html

syncverilerin bellekten disk aygıtına yazılmasını garanti eder. Disk aygıtının önbelleğinde hala veri olabilir ve disk aygıtının kendisi yavaşsa veya bir sorun varsa diske yazılmayabilir.

Bir ubuntu sunucusu çalıştırıyorsunuz. . . masaüstünüzdeki bir makine mi? Yoksa bir bulutun içinde mi? Veya. . . başka bir şey? Buraya bakın: /server/534627/what-does-the-sync-command-do bellekten sabit disk sorunları ile ilişkili diske yavaş senkronizasyon VEYA belki Amazon AWS daha küçük örneklerle.

— gaoithe
kaynak

syncHerhangi bir faydası olup olmayacağından emin değilim ; Bunu yapmanın cd .sorunu zaten hafiflettiğini gördüm . Bunun için bir takma ad refyaptım (biliyorum, bir karakteri kaydetmek biraz aptalca) ve şimdi eski bir oturuma her geldiğimde kullanma alışkanlığım var. Sunucunun ne olduğuna gelince, şimdi Ubuntu dağıtımını çalıştıran oturma odamın köşesinde yaşayan eski masaüstü kulem (geçen yıl yeni bir tane yaptım), bu yüzden çalışanlara donanım ve güce tam erişimim var üstünde.

— Alex

FWIW sorunu bash tarafından değil ls komutu ile görüntülenir.

Dosyayı görmeniz hala orada olduğu anlamına gelir. Hiçbir şey başka bir şeyle senkronize edilemez ve çalışan senkronizasyonun hiçbir miktarı ilgili dosya sistemi verilerinin önbelleğe alınmış tek kopyasını kullanmanızı engellemez. senkronizasyon, verilerin görünümünüzü değiştirmemesi için yalnızca kalıcı depolama işlemine neden olur.

VIM oturumları mı kullanıyorsunuz? VIM oturumunu bilmiyorum, hiç kullanmadım, ama tmux'un VI oturum yöneticisinin dosyanın kapalı olduğunu fark etmemesine ve değişikliklerinizi takip etmesine neden olabileceğini hayal ediyorum.

— Johan
kaynak