Dosya değişikliklerinin doğrudan diske kaydedildiğini, yani dosyayı kapatıp kaydetmeyi seçip / seçmeye karar verdiğimde düşünürdüm. Ancak, son bir konuşmada, bir arkadaşım bana bunun genellikle doğru olmadığını söyledi; İşletim sistemi (özellikle Linux sistemleri hakkında konuşuyorduk) bellekteki değişiklikleri koruyor ve içeriği gerçekten bellekten diske yazan bir cine sahip.

Harici flaş sürücülerine örnek bile verdi: bunlar sisteme monte edildi (belleğe kopyalandı) ve bazen veri kaybı olur çünkü arka plan programı içeriği flash belleğe kaydetmedi; bu yüzden flash sürücüleri çıkardık.

İşletim sistemlerinin işleyişi hakkında hiçbir bilgim yok ve bu yüzden bunun doğru ve hangi durumlarda olduğu hakkında hiçbir fikrim yok. Asıl sorum şu: bu Linux / Unix sistemlerinde (ve belki de diğer işletim sistemlerinde) anlatıldığı gibi oluyor mu? Örneğin, bu, bir dosyayı düzenledikten ve kaydettikten hemen sonra bilgisayarı kapatırsam , değişikliklerimin büyük olasılıkla kaybolacağı anlamına mı geliyor? Belki de disk tipine bağlıdır - geleneksel sabit diskler ve katı hal diskler?

Bu soru özellikle, herhangi bir açıklama veya kıyaslama yapılsa bile, bilgiyi saklamak için bir diske sahip olan dosya sistemlerini ifade eder.

bir dosyayı düzenledikten ve kaydettikten hemen sonra bilgisayarı kapatırsam, değişikliklerim büyük olasılıkla kaybolacak mı?

Olabilirler. "En muhtemel" demem ama ihtimal bir çok şeye bağlı.

Dosya yazmalarının performansını artırmanın kolay bir yolu, işletim sisteminin yalnızca verileri önbelleğe alması, yazmanın geçtiği uygulamayı anlatması (yalandırması) ve daha sonra aslında yazma işlemini yapmasıdır. Bu, aynı anda başka bir disk aktivitesi devam ederse özellikle yararlıdır: İşletim sistemi okumaları öncelik sırasına koyabilir ve daha sonra yazma yapabilir. Ayrıca, örneğin geçici bir dosyanın daha sonra hızlı bir şekilde kaldırılması durumunda gerçek bir yazma ihtiyacını tamamen kaldırabilir.

Önbelleğe alma sorunu, depolama alanı yavaşsa daha belirgindir. Dosyaları hızlı bir SSD'den yavaş bir USB çubuğuna kopyalamak muhtemelen çok fazla yazma önbelleği gerektirir; çünkü USB bellek yetişemez. Ancak cpkomutunuz daha hızlı geri döner, böylece çalışmaya devam edebilirsiniz, muhtemelen yeni kopyalanan dosyaları bile düzenleyebilirsiniz.

Tabii ki, böyle önbelleğe alma notu olumsuz vardır, aslında kaydedilmeden önce bazı veriler kaybolabilir. Editörlerine yazma işleminin başarılı olduğunu söylemesi durumunda kullanıcı etkilenecek, ancak dosya diskte değildi. Bu nedenle , yalnızca dosya diske çarptıktan sonra geri dönmesi beklenen fsync()sistem çağrısı var. Editörünüz bunu, yazının başarılı olduğunu kullanıcıya bildirmeden önce verilerin iyi olduğundan emin olmak için kullanabilir.

Dedim ki, "söylenmesi gerekiyor", çünkü sürücünün kendisi de işletim sistemine aynı yalanları söyleyebilir ve yazmanın tamamlandığını söylerken dosya gerçekten de sürücü içindeki geçici bir yazma önbelleğinde bulunur. Sürücüye bağlı olarak, bunun hiçbir yolu olmayabilir.

Ek olarak fsync(), aynı zamanda orada sync()ve syncfs()belirli bir dosya sistemi üzerinde emin tüm sistem genelinde yazma veya tüm yazıyor diski isabet yapmak için sistem sormak sistem çağrıları. Yardımcı program syncbunları çağırmak için kullanılabilir.

Daha sonra “G / Ç’nin önbellek etkilerini bu dosyaya ve bu dosyadan en aza indirmeye çalışılması” gereken O_DIRECTbayrakopen() da var . Önbelleğe almanın kaldırılması performansı azaltır, bu yüzden çoğunlukla kendi önbelleğe alma yapan ve denetimini kontrol etmek isteyen uygulamalar (veritabanları) tarafından kullanılır. ( O_DIRECTsorunları olmadan değil, man sayfasındaki hakkındaki yorumlar biraz eğlenceli.)

Güç çıkışında ne olacağı da dosya sistemine bağlıdır. Sadece endişelenmeniz gereken dosya verileri değil, dosya sistemi meta verileridir. Dosya verilerini diskte bulundurmak, bulamazsanız çok kullanmaz. Bir dosyayı daha büyük bir boyuta genişletmek, yeni veri blokları tahsis etmeyi gerektirir ve bir yere işaretlenmeleri gerekir.

Bir dosya sisteminin meta verilerle nasıl başa çıktığı ve meta veriler ile veri yazması arasındaki sıralamanın önemi çok fazladır. Örneğin, ext4eğer mount bayrağını ayarlarsanız data=journaltüm yazarlar - hatta veri yazarlar - günlükten geçer ve oldukça güvenli olmalıdır. Bu aynı zamanda iki kez yazdıkları anlamına gelir, bu yüzden performans düşer. Varsayılan seçenekler, verileri, meta veriler güncelleştirilmeden önce diskte olacak şekilde yazmaya çalışır. Diğer seçenekler veya diğer dosya sistemleri daha iyi veya daha kötü olabilir; Kapsamlı bir çalışma bile yapmam.

Uygulamada, hafif yüklü bir sistemde, dosya diske birkaç saniye içinde basmalıdır. Çıkarılabilir depolama ile uğraşıyorsanız, verilerin gerçekten sürücüye gönderildiğinden emin olmak için medyayı çekmeden önce dosya sisteminin bağlantısını kesin ve başka bir işlem yapılmadığından emin olun. (Veya GUI ortamınızın sizin için yapmasını sağlayın.)

Bir yoktur derece o kanıtlamak için basit bir yolu olamaz dosya düzenlemeleri her zaman doğrudan, diske dosya sistemleri olduğunu yani aslında kaydedilir bu doğru ilk etapta bir diske tarafından desteklenen değildir . Bir dosya sistemi vermezse sahip ilk etapta bir disk, o zaman muhtemelen olamaz , değişiklikleri diske yazma hiç .

Bazı örnekler:

• tmpfsyalnızca RAM'de (veya daha doğrusu tampon belleğinde) var olan bir dosya sistemi
• ramfs, yalnızca RAM’de bulunan bir dosya sistemi
• herhangi bir ağ dosya sistemi (NFS, CIFS / SMB, AFS, AFP,…)
• Herhangi bir sanal dosya sistemi ( sysfs, procfs, devfs, shmfs, ...)

Ancak, disk destekli dosya sistemleri için bile bu genellikle doğru değildir. Sayfa Nasıl Bozulur? Bir SQLite Veritabanının , yazma işleminin (bu durumda bir SQLite veri tabanına gönderilmesi) diske ulaşamadığı birçok farklı yolu tanımlayan , Eşitleme başarısızlığı adlı bir bölüm vardır . SQLite ayrıca Atomic Commit In SQLite'ı garanti altına almak için atlamanız gereken birçok çemberin açıklandığı bir bildiriye sahiptir . (Not Atom Yaz sadece daha sorun çok daha zordur yaz , ama tabii ki diske yazma atomik yazının alt problem olduğunu ve bu kağıttan da böyle bir sorun hakkında çok şey öğrenebilir.) Bu yazı, bir var bölüm Yanlış Go Can Things hakkında bir alt bölüm içerirYazmaların diske ulaşmasını engelleyebilecek bazı karmaşık karmaşıklık örnekleri veren eksik Disk Basmaları (örneğin, HDD denetleyicisi, diskete yazılmadığını bildirdiğini bildirir - evet, bunu yapan HDD üreticileri vardır) ve ATA şartnamesine göre bile yasal olabilir, çünkü bu konuda belirsizce ifade edilmiştir).

Unix, Linux ve Windows dahil olmak üzere çoğu işletim sisteminin işlemleri hızlandırmak için yazma önbelleği kullandığı doğrudur. Bu, bilgisayarı kapatmadan kapatmanın kötü bir fikir olduğu ve veri kaybına neden olabileceği anlamına gelir. Aynı şey, bir USB depolama biriminin çıkarılmaya hazır olmadan önce çıkarılması durumunda da geçerlidir.

Çoğu sistem aynı zamanda yazma işlemlerini senkronize etme seçeneği de sunar. Bu, bir uygulamanın daha yavaş olma pahasına bir başarı onayı almadan önce verilerin diskte olacağı anlamına gelir.

Kısacası, bilgisayarınızı düzgün bir şekilde kapatmanız ve USB depolama aygıtını çıkarmaya uygun biçimde hazırlamanızın bir nedeni vardır.

1. Flash tabanlı depolama

Disk tipine (geleneksel sabit diskler ve katı hal diskleri) veya bilmediğim başka bir değişkene bağlı mı? Sadece (Linux'ta) oluyor mu, yoksa diğer işletim sistemlerinde mevcut mu?

Bir seçeneğiniz olduğunda, flaş tabanlı depolamanın temiz bir kapanma olmadan güç kaybetmesine izin vermemelisiniz.

SD kartlar gibi düşük maliyetli depolamada, tüm silme bloklarını (4KB'den birkaç kez daha büyük) kaybetmeyi, farklı dosyalara veya dosya sisteminin temel yapılarına ait olabilecek verileri kaybetmeyi bekleyebilirsiniz.

Bazı pahalı SSD'ler, elektrik kesintisi karşısında daha iyi garantiler sunabileceğini iddia edebilir. Bununla birlikte, üçüncü taraf testleri, birçok pahalı SSD'nin bunu yapamadığını göstermektedir. "Aşınma dengelemesi" için blokları tekrarlayan katman karmaşık ve tescillidir. Olası arızalar sürücüdeki tüm verilerin kaybolmasını içerir.

Test çerçevemizi uygulayarak, toplamda üç binden fazla hata enjeksiyon çevrimi kullanarak altı farklı üreticiden 17 emtia SSD'sini test ediyoruz. Deneysel sonuçlarımız, test edilen 17 SSD cihazının 14'ünün, elektrik kesintileri, bit bozulması, çakıl yazma, seri hale getirilmeyen yazma, meta veri bozulması ve toplam aygıt hatası dahil olmak üzere şaşırtıcı hata davranışları gösterdiğini ortaya koyuyor.

2017: https://dl.acm.org/citation.cfm?id=2992782&preflayout=flat

2013: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf?wptouch_preview_theme=enabled

2. Dönen sabit disk sürücüleri

Dönen HDD'ler farklı özelliklere sahiptir. Güvenlik ve basitlik için, flash tabanlı depolama ile aynı pratik belirsizliğe sahip olduklarını varsaymanızı öneririm.

Açıkça bilmediğin özel kanıtların yoksa. Dönen HDD'ler için karşılaştırmalı rakamlara sahip değilim.

Bir HDD, tamamlanmamış yazılı bir sektörü kötü bir sağlama toplamı ile bırakabilir ve bu da daha sonra bize güzel bir okuma hatası verir. Genel olarak konuşursak, bu HDD'lerin başarısızlık modu tamamen bekleniyor; yerli Linux dosya sistemleri akılda tutularak tasarlanmıştır. fsync()Bu tür bir elektrik kesintisi arızası karşısında sözleşmesini korumayı amaçlar . (Bunu SSD'lerde garantili görmek isteriz).

Bununla birlikte, Linux dosya sistemlerinin bunu her durumda başardığından veya bunun mümkün olup olmadığından emin değilim.

Bu tür bir arızadan sonraki bir sonraki önyükleme bir dosya sistemi onarımı gerektirebilir. Bu Linux'tur, dosya sistemi onarımının anlamadığınız bazı soruları sorması mümkündür, burada sadece Y'ye basabilirsiniz ve bunun çözüleceğini umarsınız.

2.1 Eğer fsync () sözleşmesinin ne olduğunu bilmiyorsanız

Fsync () sözleşmesi hem iyi haberlerin hem de kötü haberlerin bir kaynağıdır. Önce iyi haberi anlamalısınız.

İyi haber: fsync()örneğin "kaydet" e bastığınızda dosya verilerini yazmanın doğru yolu olarak belgelenmiştir. Ve örneğin metin editörlerinin atomik olarak mevcut dosyaları değiştirmeleri gerektiği yaygın olarak anlaşılmaktadır rename(). Bu, her zaman eski dosyayı sakladığınızdan veya yeni dosyayı ( fsync()yeniden adlandırmadan önce basılan) aldığınızdan emin olmak içindir . Yeni dosyanın yarı yazılı sürümüyle bırakılmak istemezsiniz.

Kötü haber: Uzun yıllar boyunca, en popüler Linux dosya sistemine fsync () yöntemini çağırmak tüm sistemi etkin bir şekilde onlarca saniye bekletebilir. Uygulamalar bu konuda hiçbir şey yapamadığından, bu dosya sisteminde nispeten güvenilir görünen fsync () olmadan rename () yöntemini iyimser kullanmak çok yaygındı.

Bu nedenle, fsync () işlevini doğru kullanmayan uygulamalar var.

Bu dosya sisteminin bir sonraki sürümü genellikle fsync () 'nin askıya alınmasından kaçınır - aynı zamanda fsync ()' nin doğru kullanımına dayanarak başlar.

Bunların hepsi oldukça kötü. Bu tarihi anlamak, muhtemelen çelişkili çekirdek geliştiricilerin çoğu tarafından kullanılan küçümseyen ton ve inatçı tarafından desteklenmiyor.

Mevcut çözünürlük şu anda en popüler Linux dosya sisteminin fsync () işlevini gerektirmeden rename () desenini desteklemeye varsayılanlarönceki sürümle birlikte "bug-to-bug uyumluluğu" uygular. Bu, mount seçeneğiyle devre dışı bırakılabilir noauto_da_alloc.

Bu tam bir koruma değil. Temel olarak, bekleyen IO'yu rename () zamanında temizler, ancak yeniden adlandırmadan önce IO'nun tamamlanmasını beklemez. Bu, örneğin 60 saniyelik bir tehlike penceresinden çok daha iyidir! Ayrıca mevcut bir dosyayı rename () ile değiştirirken kilitlenme emniyeti için hangi dosya sistemlerinin fsync () istediğine verilen cevaba bakınız.

Bazı daha az popüler dosya sistemleri koruma sağlamaz. XFS bunu yapmayı reddediyor . Ve UBIFS de uygulamamıştır, görünüşe göre kabul edilebilir, ancak bunu mümkün kılmak için çok fazla çalışmaya ihtiyaç duyar. Aynı sayfa, UBIFS'in güç kaybı dahil olmak üzere veri bütünlüğü için başka birkaç "TODO" sorunu olduğunu da göstermektedir. UBIFS, doğrudan flash depolamada kullanılan bir dosya sistemidir. UBIFS'in flash depolamanın bahsettiği bazı sorunların SSD hatalarıyla ilgili olabileceğini hayal ediyorum.

Hafif yüklenen bir sistemde, çekirdek, yeni write()silinen dosya verilerinin kısa süre sonra tekrar silindiği veya değiştirildiği durumda en iyi duruma getirmek için diski temizlemeden önce a'dan 30 saniye sonra sayfa önbelleğinde kalmasına izin verecektir .

Linux dirty_expire_centisecsvarsayılan olarak 3000 (30 saniye) değerindedir ve yeni yazılan verilerin ne kadar süre önce "sona ereceğini" kontrol eder. (Bkz. Https://lwn.net/Articles/322823/ ).

Daha fazla ilgili ayarlayıcı için https://www.kernel.org/doc/Documentation/sysctl/vm.txt adresine ve daha fazlası için google'a bakın. (ör. google on dirty_writeback_centisecs).

Linux varsayılanı /proc/sys/vm/dirty_writeback_centisecs500'dür (5 saniye) ve PowerTop, güç tüketimini azaltmak için 1500 (15 saniye) olarak ayarlamanızı önerir.

Gecikmeli geri yazma, çekirdeğin diske yazmaya başlamadan önce bir dosyanın ne kadar büyük olacağını görmesi için de zaman kazandırır. Gecikmeli tahsisi olan dosya sistemleri (XFS gibi ve muhtemelen bugünlerde diğerleri), yeni yazılmış bir dosyanın verilerini gerektiğinde, inode için yer ayırmaktan ayrı olarak nereye koyacaklarını bile seçmez. Bu, örneğin diğer dosyalar arasındaki 1 megapara büyük bir dosyanın başlangıcını koymaktan kaçınmalarını sağlayarak parçalanmayı azaltır.

Çok fazla veri yazılıyorsa, diske yazma işlemi, disk belleği önbelleğinde ne kadar kirli (henüz diske senkronize edilmemiş) olabileceğinin bir eşiği ile tetiklenebilir.

Ancak, çok fazla bir şey yapmıyorsanız, sabit disk etkinlik ışığınız küçük bir dosyada tasarruftan sonra 5 (veya 15) saniye boyunca yanmaz.

Editörünüz fsync()dosyayı yazdıktan sonra kullandıysa , çekirdek gecikmeden diske yazar. ( fsyncVeriler gerçekten diske gönderilinceye kadar ve geri dönmeyecek).

Yaz önbelleğe alma içindeki diskin aynı zamanda bir şey olabilir, ama diskler normalde Linux'un sayfa önbellek algoritmaları aksine, en kısa sürede kalıcı depolama için kendi yazma-önbelleğini işlemeye çalışıyoruz. Disk yazma önbellekleri, daha küçük yazma patlamalarını absorbe etmek için daha fazla mağaza tamponudur, ancak belki de yazmaları okuma lehine geciktirmek ve bir arama düzenini optimize etmek için disklere ürün yazılımı odasını vermek (örneğin, bir tane yapmak yerine, yakındaki iki yazma veya okuma yapmak) , sonra uzağa, sonra geriye.

Dönen (manyetik) bir diskte, bir SATA yazma komutundan gelen veriler, yazılmadan önce bekleyen / okunan yazılar olsaydı, her birinin 7 ila 10 ms'lik gecikme arama gecikmelerini görebilirsiniz. (Bu soruya ilişkin diğer bazı cevaplar disk yazma önbellekleri hakkında ayrıntılı bilgi veriyor ve FSA'nın yolsuzluktan kaçınmak için kullanabileceği engeller yazıyor.)