Crash consistency ve durability üzerine
HTML-код
- Опубликовано: 18 окт 2024
- Bu yayında tek dosya üzerinde persistence ve durability işlemlerine bakacagız.
► Kanala Abone olup bildirimleri açmayı unutmayın!
► Sorularınızı videolara yorum olarak ekleyin ve tartışalım.
► Canlı yayınlardan haberdar olmak için:
Twitter: / ahmetb 'den beni takip edebilirsiniz.
Discord: bit.ly/ahmetb-... üzerinden gruba sorular sorabilirsiniz.
Videolara geriden geliyorum, ama yayinlarin hem anlatim tarzin hem de anlattiklarindan dolayi cok keyifli :) Tesekkurler Ahmet.
şu chat yorumları bile ayrı seviyede. açıkçası ne kadar ingilizce tüketsek de böyle içerikleri, türkçe olarak görmek, dinlemek çok gururlandırıcı.
Sabah dışarıda bir fincan kahve içmek için oturduğumda kaydı açtım ve 2,5 saat sonra 3 fincan kahve ile kalktım. Yol gösterici bir içerik olmuş. Ben de yeni şeyler öğrendim.
İki ilave yapmak isterim.
Dk 54 civarı geçen ve write işlemlerinin hardware bacağıyla ilgili önemli bir bileşen de server/storage disk controller battery modülleridir. Bir write isteği OS kernel'dan çıkıp driver üzerinden storage controller'a geldiğinde genelde veri gerçekte diske yazılmış gibi OS'e hemen bir complete sinyali döner ve Kernel artık o write işleminin peşini bırakır. Ama aslında çoğu zaman bu veri hemen fiziksel diske yazılmamış olur ve hardware vendor’ın optimzasyon politikasına göre zamanı gelene kadar controller'ın memory buffer'ında biriktirilir. Bu sırada bir hardware failure ya da bir power failure yaşanırsa? Bu gibi durumlarda cihaz kapalı ve enerji alamıyor olsa dahi ilgili memory buffer alanı özel bir battery modülü tarafından beslendiği için failure sonrası cihaz tekrar açıldığında memory buffer'da yaşamaya devam eden ve henüz diske yazılmamış veri kaldığı yerden tutarlı bir şekilde diske yazabilir. Bu yüzden write işleminde görev alan bileşenleri crash consistency açısından tehlike potansiyellerine göre bir sıraya dizmek gerekseydi, bu sıralama verinin doğduğu nokta olan application'dan başlayarak app > fs > kernel > driver > hardware controller > disk şeklinde olurdu diye düşünüyorum. Yani ilginçtir ki bence veriyi write ederken izlenen yolda alt bileşenlere inildikçe güven/garanti artıyor...
Bir diğer konu son bölümde write'ların araya girmemesi meselesi. Bence sebebi şöyle:
f.WriteString() ile deneme yapılan senaryoda alt paketteki file descriptor zaten bir Mutex'e sahip olduğu için, io.Write() methodunu implement eden bu file descriptor bir syscall.Write() yapmadan önce zaten lock/unlock operasyonunu işletiyor ve haliyle goroutine'leri write için sıraya almış oluyor [1]. Bu yüzden de write işlemleri sıralı gerçekleşiyor.
[1] cs.opensource.google/go/go/+/refs/tags/go1.21.4:src/internal/poll/fd_unix.go;l=366-370
bufio pkg ile buffered olan senaryoda ise payload size ayarlanan buffer size'dan büyük olduğu için, bufio pkg tasarımı gereği, parça parça yazmak yerine yine bir bütün olarak kendi io.Write() implementasyonuna paslanıyor ve haliyle üstteki senaryo ile aynı kapıya çıkmış oluyor [2]. Yani gün sonunda yine aynı file descriptor'ın lock/unlock operasyonuna tabi şekilde syscall.Write() yapılıyor.
[2] cs.opensource.google/go/go/+/master:src/bufio/bufio.go;l=677-679
Ek bir bilgi de şu: Her iki write yönteminde de yer alan bu file descriptor'ın Write() methodu, diske yazılmak üzere gelen veri boyutunu kontrol eder ve eğer maxRW=1GB boyutundan büyük ise payload byte slice'dan yalnızca maxRW kadar kısmı alarak yazmak üzere syscall yapar, taşan kısmı discard eder yani diske yazamaz ve haliyle geriye n < len(p) döneceği için de ortaya "io.ErrShortWrite" hatası çıkar. Buradan hareketle, bir çok OS max 2GB size desteklese de, "net" ve "os" paketleri için tek atışta yazma işlemleri 1GB size ile sınırlıdır diyebiliriz [3].
[3] cs.opensource.google/go/go/+/refs/tags/go1.21.4:src/internal/poll/fd_unix.go;l=137
Dedigin gibi yasadigimiz sikintilari acikliyor. Kodu yakindan okuyacagim. Teşekkürler.
komiksin gerçekten, disk işlemleri işletim sistemlerinin en temel görevidir. bu görevleri işletim sistemi yapar, uygulama yapmaz, yapamaz, yapmaya çalışırsa işletim sistemi engeller. diske doğrudan erişemez uygulama yazılımları. dolayısı ile golang da erişemez. nasıl erişmez dersen korumalı mod mimarisini öğrenmeni tavsiye ederim.
dosyayı kilitleyen işletim sistemi, golang değil !!!
şu kalitede bilgi veren insan sayısı o kadar az ki... veri mühendisi olarak çok eğlenerek öğrenerek izledim. çok teşekkür ederiz.
teşekkür ederim bilgiler için :)
Cok bilgilendirici bir yayindi, agzina saglik. Bu sekilde youtube icerikleri devam etsin lutfen 👍
I love your great energy during this stream, thanks for sharing abi.
Muazzam bilgiler, teşekkürler.
Çok teşekkürler, ağzına sağlık. 🙏
uh. yeni konsept harika. kisa zamanda kanali yurutmeyecek belki ama uzuun bur surecte internetin derinliklerinde yer edinmis, CS ile ilgilenenlerin kutsal kanali olacaktir.
Cok guzel bir yayindi izleyemedigim kisimlar icin tekrarini yuklemen mukemmel olmus :)
harika
abi ufuk açıyorsun ağzına sağlık
işletim sistemi kurallarına takılmışsın, o kullandığın fscan gibi fonksiyonlar işletim sisteminin fonksiyonları ( interrupt veya os api), golang sana işletim sistemi fonksiyonlarına erişmeni sağlar, yeniden yazmaz. ! os lara göre bir dosya açıldı ise başka biri o dosyayı açamaz, en azından yazma erişimi ile.