Diske veri yazmayı geciktirmenin ardındaki felsefe nedir?

Linux'ta, bir komutun bitmesi cpveya böyle bir komutun yürütülmesi dd, verilerin cihaza yazıldığı anlamına gelmez. Örneğin, syncsürücüdeki "Güvenle Kaldır" veya "Çıkar" işlevini çağırmanız veya çağırmanız gerekir.

Böyle bir yaklaşımın ardındaki felsefe nedir? Veriler neden bir kerede yazılmıyor? Bir G / Ç hatası nedeniyle yazmanın başarısız olma tehlikesi yok mu?

Böyle bir yaklaşımın ardındaki felsefe nedir?

Verimlilik (disk özelliklerinin daha iyi kullanılması) ve performans (uygulamanın bir yazma işleminden hemen sonra devam etmesine izin verir).

Veriler neden bir kerede yazılmıyor?

Temel avantaj, işletim sisteminin bant genişliği kullanımını geliştirmek için bitişik yazma işlemlerini yeniden düzenlemek ve birleştirmek için ücretsiz olmasıdır (daha az işlem ve daha az arama). Sabit diskler, çok sayıda küçük işlem gerektiğinde daha iyi performans gösterirken, uygulamalarda çok sayıda küçük işlem yapılması gerekebilir. Diğer bir net optimizasyon, işletim sisteminin aynı blok kısa bir süre içinde birden fazla kez yazıldığında son yazılanların hepsini kaldırabilmesi veya etkilenen dosya bu arada kaldırılırsa bazı yazmaların hepsini kaldırabilmesidir.

Bu eşzamansız yazma , sistem çağrısı geri geldikten sonra yapılır write. Bu, ikinci ve en kullanıcı tarafından görülebilir avantajdır. Eşzamansız yazma, verilerin aslında diskte olmasını beklemeden çalışmalarına devam etmekte özgür oldukları için uygulamaları hızlandırır. Aynı tür tamponlama / önbellekleme, yakın zamanda veya sıklıkla okuma bloklarının diskten tekrar okumak yerine bellekte tutulduğu okuma işlemleri için de uygulanır.

Bir GÇ hatası nedeniyle yazma işleminin başarısız olması tehlikesi yok mu?

Şart değil. Bu, kullanılan dosya sistemine ve yerinde fazlalığa bağlıdır. Veriler başka bir yere kaydedilebiliyorsa, bir G / Ç hatası zararsız olabilir. ZFS gibi modern dosya sistemleri kendiliğinden kötü disk bloklarını iyileştirir. Ayrıca, G / Ç hatalarının modern işletim sistemlerinde bozulmadığını unutmayın. Veri erişimi sırasında meydana gelirlerse, etkilenen uygulamaya basitçe bildirilirler. Yapısal meta veri erişimi sırasında meydana gelirler ve dosya sistemini riske sokarlarsa, salt okunur şekilde yeniden bağlanabilir veya erişilemez duruma getirilebilir.

Ayrıca bir işletim sistemi çökmesi, elektrik kesintisi veya donanım arızası durumunda hafif bir veri kaybı riski vardır. Verilerin diskte olduğundan emin olmak için% 100 olması gereken uygulamaların (örn. Veritabanları / finansal uygulamalar) daha az verimli ancak daha güvenli eşzamanlı yazmalar yapmasının nedeni budur. Performans etkisini azaltmak için, çoğu uygulama hala eşzamansız yazma kullanır, ancak kullanıcı açıkça bir dosya kaydettiğinde (örneğin vim, kelime işlemciler) bunları senkronize eder.

Öte yandan, kullanıcıların ve uygulamaların çok büyük bir çoğunluğu, senkronize yazmaların sağladıkları güvenliğe ihtiyaç duymamakta ya da bakım gerektirmemektedir. Bir çarpma veya elektrik kesintisi varsa, tek risk genellikle son 30 saniyedeki verilerin en kötü ihtimalle kaybedilmesidir. İlgili bir finansal işlem veya zamanlarının 30 saniyesinden daha büyük bir maliyet anlamına gelmeyen benzer bir işlem olmadığı sürece, performanstaki (yani bir yanılsama değil ama gerçek olan) devasa kazanç, asenkronize yazmaların büyük ölçüde riski aşmasını sağlar.

Son olarak, senkronize yazma işlemleri zaten yazılmış verileri korumak için yeterli değildir. Uygulamanızın ne olursa olsun verilerinin kaybedilmeyeceğinden emin olması gerekiyorsa, yangın, sel vb. Felaketlere karşı koymak için birden fazla diskte ve birden fazla coğrafi konumda veri çoğaltması yapılması gerekir.

Sadece yazma işlemi tamamlanıncaya kadar beklemesi gerekmeyen programlara hız illüzyonu verir. Dosya sistemlerinizi senkronize modda (size anında yazmanızı sağlayan) bağlayın ve her şeyin ne kadar yavaş olduğunu görün.

Bazen dosyalar yalnızca geçici olarak var olur ... bir program biraz iş yapar ve iş bittikten hemen sonra dosyayı siler. Bu yazıları geciktirdiyseniz, ilk başta onları hiç yazmamış olmaktan kurtulabilirsiniz.

Bir GÇ hatası nedeniyle yazma işleminin başarısız olması tehlikesi yok mu?

Ah, kesinlikle. Böyle bir durumda, genellikle tüm dosya sistemi salt okunur moda geçer ve her şey korkunçtur. Ancak bu nadiren olur, genel olarak performans avantajlarından mahrum kalmanın anlamı yoktur.

Eşzamansız, tamponlanmış G / Ç Linux'tan önce ve hatta Unix'ten önce kullanılıyordu. Unix vardı, ve böylece tüm offhootlar var.

İşte Ritchie ve Thompson'ın CACM makaleleri UNIX Zaman Paylaşma Sistemi'nde yazdıkları :

Kullanıcıya, dosyaları okumak ve yazmak hem senkronize hem de tamponlanmamış görünmektedir. Bu, bir okuma çağrısından geri döndükten hemen sonra, veriler kullanılabilir durumdadır ve bunun tersine bir yazmadan sonra kullanıcının çalışma alanı yeniden kullanılabilir. Aslında sistem, bir dosyaya erişmek için gereken G / Ç işlemlerinin sayısını büyük ölçüde azaltan oldukça karmaşık bir tamponlama mekanizması sağlar.

Sorunuzda ayrıca şunları yazdınız:

Bir GÇ hatası nedeniyle yazma işleminin başarısız olması tehlikesi yok mu?

Evet, yazma başarısız olabilir ve program bu konuda hiçbir şey bilemeyebilir. Hiçbir zaman iyi bir şey olmamasına rağmen, bunun bir G / Ç hatasının sistem paniği oluşturduğu durumlarda en aza indirgenebilir (bazı işletim sistemlerinde bu yapılandırılabilir - paniklemek yerine, sistem çalışmaya devam edebilir ancak etkilenen dosya sistemi takılı değil veya salt okunur) Kullanıcılara daha sonra bu dosya sistemindeki verilerin şüpheli olduğu bildirilebilir. Ve bir sürücü, bozuk hata listesinin hızla artıp artmadığını görmek için proaktif olarak izlenebilir , bu sürücünün arızalandığının bir göstergesidir.

BSD fsyncsistem çağrısını ekledi, böylece bir program devam etmeden önce dosya verilerinin tamamen diske yazıldığından emin olacaktı ve sonraki Unix sistemleri senkronize yazma işlemleri için seçenekler sunmuştu. GNU gd, conv=fsynctüm verilerin komut çıkmadan önce yazıldığından emin olma seçeneğine sahiptir. Arabelleğe alınan verilerin yazılması birkaç dakika sürebilir yavaş çıkarılabilir flash sürücülere yazarken kullanışlıdır.

Başka bir dosya bozulması kaynağı, örneğin güç kaybından kaynaklanan ani bir sistem kapatmadır. Hemen hemen tüm mevcut sistemler , dosya sistemlerinde temiz / kirli bayrağını destekler . Yazılacak daha fazla veri olmadığında ve tipik olarak sistemin kapanması sırasında veya manuel olarak arayarak dosya sistemi sökülmek üzere olduğunda , bayrak temizlenirumount . fsckDosya sistemlerinin temiz bir şekilde kapanmadığını tespit ederlerse, sistemler genellikle yeniden başlatılır.

Pek çok iyi cevap var, ama bir tane daha ekleyeyim ... Unix'in çok işlemli ve çok kullanıcılı bir sistem olduğunu hatırlayın, bu nedenle potansiyel olarak birçok kullanıcı dosya işlemlerini (özellikle de) yazmayı dener. aynı zamanda. Eski yavaş sabit disklerle (belki de ağa monte edilmiş) bu yalnızca zaman alır (programlar için temelde kilitlenecek ve kullanıcılar beklemek zorunda kalacaklardı) değil, aynı zamanda ileri geri disk.

Bunun yerine, yazılmayı bekleyen dosyalar bir süre bellekte tutuldu ve diskin üzerinde bitmeleri gereken yere göre sıralandı ... ve arabellek dolduğunda - ya da disk senkronizasyonu arka plan programı bekledi. gerekli saniye sayısı (genellikle yaklaşık 30 saniye olduğunu düşünüyorum) - tüm tampon diske "sırayla" yazılmıştı, yazma kafası sadece bir sürekli süpürme hareketi yapmak zorunda kalıyordu, dosyaları diske yazıyordu. her yere ... atlamak yerine gitti.

Günümüzün hızlı disklerine bağlı olarak - katı halli cihazlardan bahsetmiyorum bile - kazanç çok daha az ... özellikle de bir anda çalışan bir linux sisteminde, bir anda sadece bir kullanıcının çalıştığı ve sadece birkaç programın olduğu.

Her neyse, tahmin edilme kombinasyonu, (önbellek / tampon belleğe) istenenden daha fazlasını okuyarak ve yazılmayı bekleyen verileri sıralayarak okur, bu nedenle "tek harekette" yazılabilir - aslında çok iyi bir fikirdi. Özellikle birçok kullanıcı tarafından çok fazla okuma ve yazma olan sistemlerde.

Linux'a özgü değildir ve sayfa önbelleği olarak adlandırılır (Linux'un oldukça iyi yaptığı). Ayrıca bkz. Http://linuxatemyram.com/ ; bir dosya yazılırsa, birkaç saniye sonra tekrar okuyun, çoğu zaman disk G / Ç gerekli değildir.

Ana avantaj, birçok sistemde çok fazla RAM bulunması ve bir kısmının çekirdek tarafından önbellek olarak kullanılabilmesidir. Bu yüzden bazı dosya işlemleri bu önbellekleme işleminden faydalanabilir. Ayrıca, disk G / Ç süresi RAM'den çok daha yavaştır (genellikle SDD için binlerce kez ve mekanik sabit diskler için yaklaşık bir milyon kez daha yavaş).

Uygulama kodu bu önbelleklemeye ilişkin ipuçları verebilir: bakınız örneğin posix_fadvise (2) & madvise (2)

Dönen plakalar RAM'den daha yavaştır. Bu gerçeği 'gizlemek' için okuma / yazma önbelleğini kullanıyoruz.

IO yazma ile ilgili faydalı olan şey, IO'nun hemen gerçekleşmesini gerektirmemesidir - bir okumadan farklı olarak, diskte okuma tamamlanana kadar veriyi kullanıcıya veremezsiniz.

Bu nedenle yazarlar yumuşak bir zaman kısıtlaması altında çalışır - sürekli verimimiz diskimizi geçmediği sürece, performans önleme cezalarının çoğunu yazma önbelleğinde gizleyebiliriz.

Ve önbellek yazmamız gerekiyor - dönen diskler nispeten yavaş. Ancak, modern RAID tiplerinin yapılabilmesi için operasyonda önemli bir ceza var.

Bir RAID 6 örneğin, bir yazma IO'sunu tamamlamak için:

• Güncelleme bloğunu oku
• parite1 oku
• parite 2'yi oku
• yeni blok yaz
• parite yazmak 1
• parite 2'yi yaz

Dolayısıyla her yazma aslında 6 GÇ işlemidir - ve özellikle büyük SATA sürücüleri gibi yavaş diskleriniz olduğunda, bu oldukça pahalı bir hale gelir.

Ancak güzel ve kolay bir çözüm var - birleştirme yaz. Tamponda 'tam şerit' yazmak oluşturabiliyorsanız, diskinizden eşliği okumak zorunda değilsiniz - bellekte ne olduğuna göre hesaplayabilirsiniz.

Bunu yapmak çok arzu edilir çünkü o zaman artık yazma güçlendirmeniz yok. Gerçekten de, RAID 1 + 0'dan daha düşük yazma cezası alabilirsiniz.

Düşünmek:

RAID 6, 8 + 2 - 10 iş milleri.

8 arka arkaya veri bloğu yazmak - önbellekteki eşliği hesaplamak ve her diske bir blok yazmak. 8 başına 10 yazma, 1,25 yazma cezası anlamına gelir. 10 RAID 1 + 0 disketinde hala 2 yazma cezası var (çünkü her bir göndericiye yazmanız gerekiyor). Dolayısıyla bu senaryoda, RAID 6'nın RAID1 + 0'dan daha iyi performans göstermesini sağlayabilirsiniz. Gerçek dünya kullanımında, karışık bir GÇ profilinden biraz daha fazlasını alırsınız.

Bu nedenle yazma önbelleğe alma, RAID setlerinin algılanan performansında büyük bir fark yaratır - RAM hızında yazma ve düşük bir yazma cezası alma - bunu yaparsanız sürekli veriminizi artırma.

Ve bunu yapmazsanız, SATA'nın yavaş performansına katlanırsınız, ancak bunu 6 ile çarpın ve oraya biraz çekişme ekleyin. Yazma önbelleğe alma olmadan 10 yollu SATA RAID-6, RAID olmadan tek bir sürücüye göre biraz daha hızlı olurdu ... ama çok fazla değil.

Yine de bir risk alırsınız - not ettiğiniz gibi - güç kaybı veri kaybı anlamına gelir. Bunu, önbellek temizleme döngülerinde, önbellekte pil yedeklemede veya SSD veya diğer geçici olmayan önbelleklerde kullanarak azaltabilirsiniz.

Belirtilen diğer cevapların hiçbiri gecikmiş tahsisat değildir . XFS, ext4, BTRFS ve ZFS hepsi bunu kullanır. XFS ext4'ün varlığından beri kullanıyor, bu yüzden örnek olarak kullanacağım:

XFS , yazılana kadar nereye veri koyacağına bile karar vermedi. Gecikmeli tahsisat , tahsisatçıya kararlarına dayanması için daha fazla bilgi verir. Bir dosya ilk kez yazıldığında, bunun bir 4k dosyası mı yoksa 1G-sürekli büyüyen dosya mı olacağını bilmenin bir yolu yoktur. Bir yerde 10 G'lik bitişik boş alan varsa, 4k dosyasını başlangıcına koymak işe yaramaz. Büyük dosyayı boş bir alanın başına koymak parçalanmayı azaltır.

Buradaki diğer tüm cevaplar normal durum için asgari düzeyde doğrudur ve benimkinden önce bunlardan herhangi birini okumanızı tavsiye ederim, ama dd ve dd'nin yazma önbelleğe almayı içermeyen tipik bir kullanım durumundan bahsettiniz. Yazma önbelleği, öncelikle dosya sistemi düzeyinde uygulanır. Ham cihazlar normalde yazma önbelleği yapmaz (baskın veya lvm gibi birden fazla aygıt sürücüsü bir başka balmumu topudur). Dd, çoğu zaman ham blok aygıtlarıyla kullanıldığından, büyük aygıtların ham aygıtlarda daha iyi performans göstermesini sağlamak için bs ve ilgili seçenekler sunar. Bu, her iki uç nokta da normal dosya olduğunda faydalı değildir (bu durumda büyük yazılar daha az sistem çağrısı kullanmasına rağmen). Bunun özellikle görülebildiği diğer ortak yer, bir kullanıcı alanı dosya sistemi uygulaması olan mtools paketidir. Disket sürücülü mtools kullanmak, araçlar tamamen senkronize ve disket sürücüler inanılmaz derecede yavaş olduğundan her zaman inanılmaz derecede halsiz hissediyor. Disketi monte etmek ve çekirdek yağ dosya sistemini kullanmak, senkronize olan miktar dışında (ve özellikle disketler gibi çıkarılabilir aygıtlar için veri kaybını önlemek için bu şekilde olması için) çok daha duyarlıdır. Özel olarak yapılandırılmış veritabanları (kendi yazma önbelleklerini uygulayan), katran ve özel aygıt ve chdsk, mkfs ve mt gibi dosya sistemi araçları gibi ham aygıtlarla düzenli olarak kullanıldığını bildiğim birkaç program var. Disketi monte etmek ve çekirdek yağ dosya sistemini kullanmak, senkronize olan miktar dışında (ve özellikle disketler gibi çıkarılabilir aygıtlar için veri kaybını önlemek için bu şekilde olması için) çok daha duyarlıdır. Özel olarak yapılandırılmış veritabanları (kendi yazma önbelleklerini uygulayan), katran ve özel aygıt ve chdsk, mkfs ve mt gibi dosya sistemi araçları gibi ham aygıtlarla düzenli olarak kullanıldığını bildiğim birkaç program var. Disketi monte etmek ve çekirdek yağ dosya sistemini kullanmak, senkronize olan miktar dışında (ve özellikle disketler gibi çıkarılabilir aygıtlar için veri kaybını önlemek için bu şekilde olması için) çok daha duyarlıdır. Özel olarak yapılandırılmış veritabanları (kendi yazma önbelleklerini uygulayan), katran ve özel aygıt ve chdsk, mkfs ve mt gibi dosya sistemi araçları gibi ham aygıtlarla düzenli olarak kullanıldığını bildiğim birkaç program var.

Felsefe varsayılan olarak güvensizdir.

Mümkün olan iki makul ve açık strateji vardır: yıkamayı hemen diske yazdırın veya yazmayı geciktirin. UNIX tarihsel olarak ikincisini seçti. O yüzden güvenliği sağlayın, fsyncdaha sonra aramanız gerekir .

Ancak, seçeneği syncolan bir cihazı monte ederek veya bunları açarak dosya başına güvenlik ile güvenlik belirleyebilirsiniz O_SYNC.

Unix'in bilgisayar uzmanları için tasarlandığını unutmayın. "Varsayılan olarak güvenli" bir değerlendirme değildi. Güvenlik, G / Ç'nin daha yavaş olması anlamına gelir ve bu erken sistemler fiyatın yüksek olması için gerçekten yavaş G / Ç'ye sahipti. Maalesef, ne UNIX ne de Linux, her ne pahasına olursa olsun değişiklik olsa bile, temerrütlü güvenliğe geçmedi.

Verimlilikte büyük bir artış için az miktarda güvenilirlik sağlar.

Örneğin bir video sıkıştırma programı varsayalım. Gecikmeli yazma ile ("geri yazma"):

1. çerçeve sıkıştırma 10ms harcamak
2. diske yazma çerçevesi verme
3. diskin yazma işleminin tamamlandığını bildirmesi için 10ms bekleyin
4. GOTO 1

E karşı

1. çerçeve sıkıştırma 10ms harcamak
2. diske yazma çerçevesi ver (arka planda tamamlandı)
3. GOTO 1

İkinci sürüm iki kat daha hızlı görünüyor çünkü CPU ve diski aynı anda kullanabiliyor, ilk sürüm ise hep birini bekliyor.

Genel olarak akış işlemleri ve toplu dosya işlemleri için geri yazma ve veritabanları ve veritabanı benzeri uygulamalar için geri yazma istersiniz.

Birçok uygulamada, depolama aygıtları zaman zaman veri okumakla meşgul olacak. Bir sistem, depolama cihazının veri okumakla meşgul olmadığı bir zamana kadar yazma işlemlerini her zaman erteleyebiliyorsa, uygulamanın bakış açısından yazma işleminin tamamlanması sıfır zaman alır. Yazmanın anında gerçekleşmeyeceği tek durum şu durumlarda olacaktır:

1. Yazma arabellekleri, yazma işlemleri gerçekten tamamlanıncaya kadar ertelenen yazma isteklerinin kabul edilemeyeceği kadar doldurur.

2. Yazma işlemi beklemede olan cihazı kapatmak veya kaldırmak gerekir.

3. Bir uygulama özellikle yazmanın gerçekte tamamlandığına dair onay ister.

Nitekim, sadece yazarların bugüne kadar gerçekleşmesi gereken yukarıdaki gerekliliklerden kaynaklanmaktadır. Öte yandan, genellikle bir cihazın boşta kaldığı zamanlarda bekleyen yazmaları yapmamanın hiçbir nedeni yoktur, bu yüzden birçok sistem bunları gerçekleştirir.

Bu da var:

"Merhaba, Joe Moe" yazın
:
"Merhaba,"
"Joe"
yazın "Moe" yazın.

Ve ayrıca:

"Merhaba, nasılsın?" Yaz.
şundan daha hızlı:
"Merhaba, naber?" yaz.
Bu
yazıyı sil "Howdy, nasılsın?"
Bu yazıyı sil
"Merhaba, nasılsın?"

Değişikliklerin ve toplamanın RAM'de gerçekleşmesi diskten daha iyidir. Toplu disk yazma, uygulama geliştiricilerini bu tür endişelerden kurtarır.