Reiser4 dosya sisteminin geliştiricisi Eduard Shishkin ile yapılan ikinci röportaj yayınlandı.
Başlamak için lütfen okuyuculara nerede ve kimin için çalıştığınızı hatırlatın.
Alman Araştırma Merkezi Huawei Technologies'de Baş Depolama Mimarı olarak çalışıyorum. Sanallaştırma departmanında veri depolamanın çeşitli yönleriyle ilgileniyorum. Faaliyetlerim belirli bir işletim sistemiyle ilgili değil.
Şu anda ana çekirdek dalına bağlı mısınız?
Çok nadiren ve yalnızca işverenim bunu gerektiriyorsa. En son yaklaşık üç yıl önceydi, 9p protokolünü (bu işin diğer adı VirtFS) kullanan ana bilgisayarlar üzerinde paylaşılan depolamanın verimini artırmak için yamalar göndermiştim. Burada önemli bir not düşmek gerekiyor: Uzun zamandır Linux ile çalışmama rağmen hiçbir zaman onun hayranı olmadım, yani her şeyde olduğu gibi “düzenli nefes alıyorum”. Özellikle bir kusur fark edersem en fazla bir kez belirtebilirim. Ve böylece birisini takip edip ikna edebilirsiniz - bu olmayacak.
Geçen sefer, on yıl önce, çekirdek geliştirme stilini oldukça eleştirdiğinizi hatırlıyorum. Sizin (veya belki de kurumsal) bakış açınıza göre, herhangi bir şey değişti mi, topluluk daha duyarlı hale geldi mi, gelmedi mi? Değilse, sizce suçlu kim?
Daha iyiye doğru hiçbir değişiklik görmedim. Toplumun temel sorunu bilimin yerini politik teknolojilerin, kişisel ilişkilerin, çoğunluğun görüşünün, popülizmin, “iç seslerden gelen tavsiyelerin”, çürümüş tavizlerin ve bilim dışındaki her şeyin almasıdır. Bilgisayar bilimi, ne derse desin, her şeyden önce kesin bir bilimdir. Ve eğer birisi 2'ten farklı olarak 2x4 için kendi değerini "Linux yolu" bayrağı altında veya başka bir bayrak altında ilan etmeye başlarsa, o zaman bunun zarardan başka bir şey getirmesi pek olası değildir.
Bütün sıkıntılar öncelikle karar verenlerin beceriksizliğinden ve eğitimsizliğinden kaynaklanmaktadır. Bir yönetici beceriksizse objektif ve yeterli bir karar veremez. Eğer kendisi de kültürsüzse, kendisine doğru tavsiyeyi verecek yetkin bir uzman bulamayacaktır. Yüksek olasılıkla seçim, "doğru gibi görünen şeyler" diyen bir dolandırıcıya düşecek. Beceriksiz, yalnız liderlerin etrafında her zaman yozlaşmış bir ortam gelişir. Üstelik tarih bu konuda istisna tanımaz ve toplum da bunun en açık teyididir.
Btrfs'in gelişimindeki ilerlemeyi nasıl değerlendiriyorsunuz? Bu FS çocukluk hastalıklarından kurtuldu mu? Bunu kendiniz için nasıl konumlandırıyorsunuz; “ev için” bir FS olarak mı yoksa kurumsal kullanım için mi?
Ondan kurtulamadım. 11 yıl önce bahsettiğim her şey bugün de geçerliliğini koruyor. Btrfs'yi ciddi ihtiyaçlara uygun hale getirmeyen sorunlardan biri de boş alan sorunudur. Başka herhangi bir FS'nin bölümde çok fazla boş alan göstereceği durumlarda, kullanıcıdan yeni bir disk için mağazaya gitmesinin istendiğinden bahsetmiyorum bile. Boş alan eksikliği nedeniyle mantıksal birimde bir işlemin tamamlanamaması da en kötü şey değildir. En kötüsü, ayrıcalığı olmayan bir kullanıcının neredeyse her zaman disk kotalarını atlayarak herkesi kısa bir süre içinde boş alandan mahrum bırakabilmesidir.
Şuna benzer (Linux çekirdeği 5.12 için test edilmiştir). Yeni kurulan bir sistemde, bir döngü içinde ana dizinde belirli adlara sahip dosyalar oluşturan, bunlara belirli uzaklıklarda veri yazan ve ardından bu dosyaları silen bir komut dosyası başlatılır. Bu betiği bir dakika çalıştırdıktan sonra olağandışı hiçbir şey olmuyor. Beş dakika sonra bölmedeki kaplanan alan miktarı biraz artar. İki ila üç saat sonra %50'ye ulaşır (başlangıç değeri %15'tir). Ve beş veya altı saatlik çalışmanın ardından komut dosyası "bölümde boş alan yok" hatasıyla çöküyor. Bundan sonra artık bölümünüze 4K dosya bile yazamazsınız.
İlginç bir durum ortaya çıkıyor: bölüme hiçbir şey yazmadınız ve tüm boş alan (yaklaşık% 85) bir yerlerde kayboldu. Böyle bir saldırıya maruz kalan bir bölümün analizi, birkaç bayt boyutunda yalnızca bir öğe (anahtarla donatılmış bir nesne) içeren birçok ağaç düğümünü ortaya çıkaracaktır. Yani, daha önce disk alanının% 15'ini kaplayan içeriğin tüm bölüm boyunca eşit şekilde "yayıldığı" ortaya çıktı, böylece yeni bir dosya yazacak yer kalmadı, çünkü anahtarı mevcut olanların hepsinden daha büyük ve ücretsiz bölümdeki bloklar tükendi.
Üstelik tüm bunlar zaten temel Btrfs yapılandırmasında gerçekleşir (herhangi bir anlık görüntü, alt hacim vb. olmadan) ve dosya gövdelerini bu FS'de (bir ağaçtaki "parçalar" olarak veya kapsamlar olarak) nasıl depolamaya karar verdiğiniz önemli değildir. (biçimlendirilmemiş blokların sayısı) - sonuç aynı olacaktır.
Diğer yukarı akışlı dosya sistemlerini bu tür bir saldırıya maruz bırakamazsınız (size ne söylerlerse söylesinler). Sorunun nedenini uzun zaman önce açıklamıştım: Bu, Btrfs'deki B-ağacı kavramının tamamen saptırılmasıdır, bu da onun kendiliğinden veya kasıtlı olarak dejenere olmasını mümkün kılar. Özellikle belirli yükler altında, dosya sisteminiz çalışma sırasında dışarıdan yardım almadan kendi başına sürekli olarak "çökecektir". Her türlü "baskılı" arka plan işleminin yalnızca bireysel masaüstlerinde günü kurtaracağı açıktır.
Toplu sunucularda saldırgan her zaman onların "önüne geçebilir". Sistem yöneticisi ona tam olarak kimin zorbalık yaptığını bile belirleyemeyecek. Btrfs'de bu sorunu çözmenin en hızlı yolu normal bir B ağacının yapısını geri yüklemektir; disk formatının yeniden tasarlanması ve Btrfs kodunun önemli bölümlerinin yeniden yazılması. Geliştiricilerin ilgili algoritmalar ve veri yapılarıyla ilgili orijinal makaleleri sıkı bir şekilde takip etmeleri ve "Linux" ta alışılageldiği (ve teşvik edildiği) gibi "bozuk telefon" oyununu oynamamaları koşuluyla, bu, hata ayıklama dahil 8-10 yıl sürecektir. yol".
Buraya geliştiricilerin tüm bunları anlaması için gereken süreyi de eklememiz gerekiyor. İşte burası daha da zorlaşıyor. Zaten 10 yıl onların anlamasına yetmedi. O zamana kadar bir mucize bekleyemezsin. Bu, "sizin ve benim bilmediğimiz" bir montaj seçeneği veya hazırlanması "sadece iş meselesi" olan bir yama şeklinde gerçekleşmeyecek. Bu tür aceleci "düzeltme"lerin her biri için yeni bir yozlaşma senaryosu sunacağım. B-ağaçları en sevdiğim konulardan biri ve bu yapıların kendi başlarına özgürlüklere tahammül etmediğini söylemeliyim!
Btrfs'i kendim için nasıl konumlandırabilirim? Bırakın kullanılmasını, dosya sistemi olarak bile adlandırılamayacak bir şey olarak. Çünkü tanım gereği FS, Btrfs durumunda görmediğimiz "disk alanı" kaynağının etkin yönetiminden sorumlu bir işletim sistemi alt sistemidir. Peki, işe geç kalmamak için mağazaya saat almaya geldiğinizi ve saat yerine size maksimum 30 dakika zamanlayıcılı elektrikli ızgara sattıklarını hayal edin. Yani Btrfs'nin durumu daha da kötü.
Posta listelerine baktığımda, disk alanını etkili bir şekilde yönetmenin, sürücülerin ucuzluğu nedeniyle artık geçerli olmadığı ifadesiyle sık sık karşılaşıyorum. Bu tamamen saçmalık. Etkili bir disk alanı yöneticisi olmadan işletim sistemi savunmasız ve kullanılamaz hale gelecektir. Makinenizdeki disklerin kapasitesi ne olursa olsun.
Btrfs'in RHEL'deki desteğinin kesilmesine ilişkin yorumunuzu rica ediyorum.
Burada yorumlanacak özel bir şey yok, her şey çok açık. Ayrıca bunu bir “teknoloji ön izlemesi” olarak da yaptılar. Yani bu “önizleme”den geçmedim. Bu etiketin sonsuza kadar asılı kalmasına izin vermeyin! Ancak tasarımı kusurlu bir ürünü tam destekle piyasaya süremezler. RHEL, emtia-para ilişkilerini öngören bir kuruluştur. Red Hat, Btrfs e-posta listesinde olduğu gibi kullanıcılara zorbalık yapamaz. Durumu hayal edin: Zorlukla kazandığı parayı disk için ödeyen bir müşteri ve siz de destek için, hiçbir şey yazmadıktan sonra disk alanının nereye gittiğini anlamak istiyor. Buna ona ne cevap vereceksin?
Daha öte. Red Hat'in müşterileri arasında tanınmış büyük bankalar ve borsalar bulunmaktadır. Btrfs'de bahsedilen güvenlik açığından dolayı DoS saldırılarına maruz kalmaları durumunda ne olacağını bir düşünün. Sizce bunun sorumlusu kim? Yazarın hiçbir şeyden sorumlu olmadığının yazılı olduğu GPL lisansının satırını işaret etmek üzere olanlara hemen şunu söyleyeceğim: "saklayın!" Red Hat cevap verecek, hem de yeterli görünmeyecek şekilde! Ancak zamanında yakın çalışma fırsatı bulduğum QA mühendislerinden oluşan güçlü ekibi göz önüne alındığında, Red Hat'in bu tür bir sorunla karşılaşmadığını biliyorum.
Neden bazı şirketler kurumsal ürünlerinde Btrfs'i desteklemeye devam ediyor?
Ürün adındaki “kurumsal” ön ekinin pek bir anlam ifade etmediğini lütfen unutmayın. Teşebbüs, müşteri ile sözleşmeye dayalı ilişkiye gömülü bir sorumluluk ölçüsüdür. GNU/Linux tabanlı tek bir kuruluş biliyorum - RHEL. Benim bakış açıma göre geri kalan her şey yalnızca bir girişim olarak sunuluyor, ancak bir girişim değil. Ve son olarak, eğer bir şeye talep varsa, o zaman her zaman arz olacaktır (bizim durumumuzda bu, bahsedilen “destektir”). Dahil olmak üzere kesinlikle her şeye talep var. ve kullanılamaz yazılım. Bu talebin nasıl oluştuğu ve kimin körüklediği ise ayrı bir konu.
Bu nedenle, Facebook'un sunucularına Btrfs'i yerleştirdiği söylentisinden sonra herhangi bir sonuca varmak istemem. Ayrıca yukarıdaki nedenlerden dolayı bu sunucuların adreslerinin dikkatli bir şekilde gizli tutulmasını tavsiye ederim.
Son zamanlarda XFS kodunu temizlemek için neden bu kadar çaba harcandı? Sonuçta, başlangıçta bu bir üçüncü taraf dosya sistemidir ve ext4 uzun süredir kararlıdır ve önceki eşit derecede kararlı sürümlerden sürekliliğe sahiptir. Red Hat'in XFS ile ilgisi nedir? Amaç olarak benzer iki dosya sistemini (ext4 ve XFS) aktif olarak geliştirmek mantıklı mı?
Bunu neyin motive ettiğini hatırlamıyorum. Girişimin Red Hat müşterilerinden gelmiş olması oldukça muhtemel. Bu tür araştırmaların yapıldığını hatırlıyorum: Yukarı yöndeki bazı dosya sistemlerinde, yeni neslin ileri teknoloji sürücülerinde devasa sayıda nesne oluşturuldu. Sonuçlara göre XFS, ext4'e göre daha iyi davrandı. Böylece onu en umut verici olarak tanıtmaya başladılar. Her durumda, burada sansasyonel bir şey aramam.
Benim için sanki bız yerine sabun koymuşlar gibi. Ext4 ve XFS geliştirmenin bir anlamı yok. Hem paralel hem de aralarından seçim yapabileceğiniz herhangi biri. Bundan iyi bir şey çıkmayacak. Doğada çoğu zaman büyüme potansiyelinin yüksek olduğu ancak büyümek için yer olmadığı durumlar vardır. Bu durumda, herkesin işaret ettiği çeşitli tuhaf ve çirkin yeni oluşumlar ortaya çıkar ("Ah, bak, bu hayatta ne görmeyeceksin!").
Ext4, F2FS'de (Btrfs'deki RAID'den bahsetmeye bile gerek yok) şifreleme işlevlerinin ortaya çıkmasıyla katman ihlali sorununun (olumsuz anlamda) çözüldüğünü düşünüyor musunuz?
Genel olarak, herhangi bir seviyenin getirilmesi ve bunların ihlal edilmemesine karar verilmesi genellikle bir politika meselesidir ve burada hiçbir şey hakkında yorum yapmayı taahhüt etmiyorum. Katman ihlalinin nesnel yönleri kimseyi pek ilgilendirmiyor, ancak bunlardan bazılarını "yukarıdan" ihlal örneğini, yani blok katmanında zaten mevcut olan işlevselliğin FS'de uygulanmasını kullanarak değerlendirebiliriz. Böyle bir "ihlal" yalnızca nadir istisnalar dışında haklı görülebilir. Bu tür her durumda öncelikle iki şeyi kanıtlamanız gerekir: buna gerçekten ihtiyaç duyulduğunu ve bunu yapmanın sistemin tasarımına zarar vermeyeceğini.
Örneğin, geleneksel olarak blok katmanına yönelik bir etkinlik olan yansıtmanın dosya sistemi düzeyinde uygulanması mantıklıdır. Farklı nedenlerden dolayı. Örneğin disk sürücülerinde “sessiz” veri bozulması (bit çürümesi) meydana gelir. Bu, cihazın düzgün çalıştığı, ancak uzak bir kuasar vb. tarafından yayılan sert bir gama kuantumunun etkisi altında blok verilerinin beklenmedik bir şekilde hasar gördüğü zamandır. En kötüsü, bu bloğun bir FS sistem bloğu (süper blok, bitmap bloğu, depolama ağacı düğümü vb.) olduğunun ortaya çıkmasıdır, çünkü bu kesinlikle bir çekirdek paniğine yol açacaktır.
Blok katmanının (RAID 1 olarak adlandırılan) sunduğu aynaların sizi bu sorundan kurtarmayacağını lütfen unutmayın. Peki, gerçekten: birisinin sağlama toplamlarını kontrol etmesi ve başarısızlık durumunda kopyayı okuması mı gerekiyor? Ek olarak, yalnızca her şeyi değil, yalnızca meta verileri de yansıtmak mantıklıdır. Bazı önemli veriler (örneğin, kritik uygulamaların çalıştırılabilir dosyaları) meta veri olarak saklanabilir. Bu durumda aynı güvenlik garantilerini alırlar. Kalan verilerin korunmasını diğer alt sistemlere (hatta belki kullanıcı uygulamalarına) emanet etmek mantıklıdır - bunun için gerekli tüm koşulları sağladık.
Bu tür "ekonomik" aynaların var olma hakkı vardır ve yalnızca dosya sistemi düzeyinde etkin bir şekilde organize edilebilirler. Aksi takdirde, katmanlama ihlali, bazı mikroskobik faydalar uğruna bir alt sistemin yinelenen kodlarla dolup taşmasına neden olur. Bunun çarpıcı bir örneği, FS kullanılarak RAID-5'in uygulanmasıdır. Bu tür çözümler (dosya sistemindeki kendi RAID / LVM'si) ikincisini mimari açıdan öldürür. Burada, katmanlama ihlalinin çeşitli pazarlama dolandırıcıları tarafından "yayına alındığı" da belirtilmelidir. Herhangi bir fikrin yokluğunda, uzun süredir komşu seviyelerde uygulanan işlevsellik alt sistemlere ekleniyor, bu yeni ve son derece kullanışlı bir özellik olarak sunuluyor ve aktif olarak zorlanıyor.
Reiser4 seviyeleri “aşağıdan” ihlal etmekle suçlandı. Dosya sisteminin diğerleri gibi monolitik değil, modüler olduğu gerçeğine dayanarak, yukarıdaki düzeyin (VFS) yapması gerekeni yaptığına dair asılsız bir varsayımda bulunuldu.
ReiserFS v3.6'nın ve örneğin JFS'nin ölümünden bahsetmek mümkün mü? Son zamanlarda çekirdekte neredeyse hiç ilgi görmediler. Onlar eski mi?
Burada bir yazılım ürününün ölümünün ne anlama geldiğini tanımlamamız gerekiyor. Bir yandan başarıyla kullanılıyorlar (sonuçta bunun için yaratıldılar), yani yaşıyorlar. Öte yandan JFS adına konuşamam (fazla bilgim yok), ancak ReiserFS'nin (v3) yeni trendlere uyum sağlaması çok zor (pratikte test edildi). Bu, gelecekte geliştiricilerin buna değil, uyarlanması daha kolay olanlara dikkat edecekleri anlamına geliyor. Bu taraftan bakıldığında ne yazık ki mimari açıdan ölü olduğu ortaya çıkıyor. "Ahlaki açıdan geçerliliğini yitirmiş" kavramını hiçbir şekilde manipüle etmem. Örneğin bir gardırop için iyi bir şekilde geçerlidir, ancak yazılım ürünleri için geçerli değildir. Bir şeyde aşağılık ve üstünlük kavramı vardır. ReserFS v3'ün artık her şeyde Reiser4'ten daha düşük olduğunu kesinlikle söyleyebilirim, ancak bazı iş yükü türlerinde diğer tüm yukarı akış FS'lerinden üstündür.
FS Tux3 ve HAMMER/HAMMER2'nin (DragonFly BSD için FS) geliştirilmesi hakkında bilginiz var mı?
Evet biliyoruz. Tux3'te bir zamanlar anlık görüntülerin teknolojisine ("sürüm işaretçileri" denir) ilgi duyuyordum, ancak Reiser4'te büyük olasılıkla farklı bir rotaya gideceğiz. Uzun zamandır anlık görüntüleri desteklemeyi düşünüyordum ve bunları basit Reiser4 birimleri için nasıl uygulayacağıma henüz karar vermedim. Gerçek şu ki, Ohad Rodeh tarafından önerilen yeni moda "tembel" referans sayacı tekniği yalnızca B ağaçları için işe yarıyor. Bunlar bizde yok. Reiesr4'te kullanılan veri yapıları için "tembel" sayaçlar tanımlanmamıştır - bunları tanıtmak için henüz kimsenin üstlenmediği belirli algoritmik problemleri çözmek gerekir.
HAMMER'a göre: Yaratıcının bir makalesini okudum. İlgilenmiyorum. Yine B ağaçları. Bu veri yapısı umutsuzca güncelliğini yitirmiştir. Geçen yüzyılda bunu terk ettik.
CephFS/GlusterFS/vb. gibi ağ kümesi FS'lerine yönelik artan talebi nasıl değerlendiriyorsunuz? Bu talep, geliştiricilerin önceliklerinin ağ FS'sine doğru kayması ve yerel FS'ye yeterince ilgi gösterilmemesi anlamına mı geliyor?
Evet, önceliklerde böyle bir değişiklik meydana geldi. Yerel dosya sistemlerinin gelişimi durmuştur. Ne yazık ki, yerel hacimler için önemli bir şey yapmak artık oldukça zor ve bunu herkes yapamıyor. Kimse kendi gelişimine yatırım yapmak istemez. Bu, ticari bir kuruluştan matematiksel araştırmalar için para ayırmasını istemekle hemen hemen aynıdır; hiç heyecan duymadan size yeni bir teoremden nasıl para kazanabileceğinizi soracaklardır. Artık yerel bir FS, sihirli bir şekilde "kutudan çıktığı gibi" görünen ve "her zaman çalışması gereken" bir şeydir ve işe yaramazsa, "Evet, ne düşünüyorlar!" gibi adressiz homurdanmalara neden olur.
Bu alanda hala çok fazla çalışma olmasına rağmen, yerel FS'ye dikkat edilmemesinin nedeni budur. Ve evet, herkes halihazırda mevcut yerel dosya sistemleri temel alınarak oluşturulan dağıtılmış depolamaya yöneldi. Artık çok moda. “Büyük Veri” tabiri birçokları için adrenalin patlamasına neden oluyor ve onu konferanslarla, çalıştaylarla, yüksek maaşlarla vb. ilişkilendiriyor.
Ağ dosya sistemini kullanıcı alanı yerine çekirdek alanına uygulamak prensipte ne kadar mantıklıdır?
Henüz hiçbir yerde uygulanmayan çok makul bir yaklaşım. Genel olarak, bir ağ dosya sisteminin hangi alanda uygulanması gerektiği sorusu "iki ucu keskin bir kılıçtır". Peki, bir örneğe bakalım. İstemci verileri uzaktaki bir makineye kaydetti. Kirli sayfalar şeklinde sayfa önbelleğine düştüler. Bu, çekirdek alanındaki "ince ağ geçidi" ağ dosya sisteminin işidir. Daha sonra işletim sistemi er ya da geç sizden bu sayfaları boşaltmak için diske yazmanızı isteyecektir. Daha sonra IO-forwarding (gönderme) ağı FS modülü devreye giriyor. Bu sayfaların hangi sunucu makinesine (sunucu düğümüne) gideceğini belirler.
Daha sonra ağ yığını görevi devralır (ve bildiğimiz gibi çekirdek alanında uygulanır). Daha sonra, sunucu düğümü veri veya meta veri içeren bu paketi alır ve arka uç depolama modülüne (yani çekirdek alanında çalışan yerel FS'ye) tüm bunları kaydetmesi talimatını verir. Bu yüzden soruyu “gönderme” ve “alma” modüllerinin nerede çalışması gerektiğine indirgedik. Bu modüllerden herhangi biri kullanıcı alanında çalışıyorsa, bu kaçınılmaz olarak içerik değişimine yol açacaktır (çekirdek hizmetlerinin kullanılması ihtiyacından dolayı). Bu tür anahtarların sayısı uygulama ayrıntılarına bağlıdır.
Bu tür anahtarların sayısı çoksa depolama verimi (G/Ç performansı) azalacaktır. Arka uç depolama alanınız yavaş disklerden oluşuyorsa önemli bir düşüş fark etmezsiniz. Ancak hızlı diskleriniz (SSD, NVRAM vb.) varsa, bağlam değiştirme zaten bir "darboğaz" haline gelir ve bağlam değiştirmeden tasarruf ederek performans önemli ölçüde artırılabilir. Paradan tasarruf etmenin standart yolu modülleri çekirdek alanına taşımaktır. Örneğin, 9p sunucusunu QEMU'dan ana makinedeki çekirdeğe taşımanın VirtFS performansında üç kat artışa yol açtığını bulduk.
Bu elbette bir ağ FS'si değil, ancak şeylerin özünü tam olarak yansıtıyor. Bu optimizasyonun olumsuz tarafı taşınabilirlik sorunlarıdır. Bazıları için ikincisi kritik olabilir. Örneğin GlusterFS'nin çekirdekte hiçbir modülü yoktur. Bu sayede artık NetBSD dahil birçok platformda çalışıyor.
Yerel FS'ler ağdakilerden veya yerel FS'lerden hangi kavramları ödünç alabilir?
Günümüzde ağ FS'leri, kural olarak, yerel FS'ler üzerinde eklentilere sahiptir, bu nedenle ikincisinden nasıl bir şey ödünç alabileceğinizi tam olarak anlamıyorum. Aslında, herkesin kendi işini yaptığı 4 çalışanlı bir şirket düşünelim: Biri dağıtıyor, diğeri gönderiyor, üçüncüsü alıyor, dördüncüsü mağazalar. Ve şirketin onu depolayan çalışanından ne ödünç alabileceği sorusu bir şekilde yanlış geliyor (ondan ödünç alabileceği şeye zaten uzun süredir sahipti).
Ancak yerel FS'lerin ağdakilerden öğreneceği çok şey var. Öncelikle mantıksal hacimleri yüksek düzeyde nasıl toplayacağınızı onlardan öğrenmelisiniz. Artık sözde "Gelişmiş" yerel dosya sistemleri, mantıksal birimleri yalnızca LVM'den alınan "sanal cihaz" teknolojisini (ilk olarak ZFS'de uygulanan aynı bulaşıcı katmanlama ihlali) kullanarak toplar. Başka bir deyişle, sanal adreslerin (blok numaraları) gerçek adreslere ve geri çevrilmesi düşük düzeyde gerçekleşir (yani, dosya sistemi bir G/Ç isteği yayınladıktan sonra).
Blok katmanında düzenlenen mantıksal hacimlere (aynalara değil) cihaz ekleme ve çıkarmanın, bu tür "özelliklerin" tedarikçilerinin mütevazı bir şekilde sessiz kaldığı sorunlara yol açtığını lütfen unutmayın. Gerçek cihazlarda canavarca değerlere ulaşabilen parçalanmadan bahsediyorum, sanal cihazda ise her şey yolunda. Ancak çok az kişi sanal cihazlarla ilgileniyor: Herkes gerçek cihazlarınızda olup bitenlerle ilgileniyor. Ancak ZFS benzeri FS (ve ayrıca LVM ile bağlantılı herhangi bir FS) yalnızca sanal disk aygıtlarıyla çalışır (sanal disk adreslerini boş olanlar arasından tahsis edin, bu sanal aygıtları birleştirin vb.). Ve gerçek cihazlarda neler olduğu hakkında hiçbir fikirleri yok!
Şimdi sanal cihazda sıfır parçalanma olduğunu (yani orada yalnızca devasa bir boyutun yaşadığını), mantıksal biriminize bir disk eklediğinizi ve ardından mantıksal biriminizden başka bir rastgele diski çıkardığınızı ve ardından yeniden dengelediğinizi hayal edin. Ve pek çok kez. Sanal cihazda hala aynı ölçüde yaşama sahip olacağınızı, ancak gerçek cihazlarda iyi bir şey görmeyeceğinizi hayal etmek zor değil.
En kötüsü de bu durumu düzeltememeniz! Burada yapabileceğiniz tek şey dosya sisteminden sanal cihazı birleştirmesini istemektir. Ama size orada her şeyin harika olduğunu söyleyecektir - yalnızca tek bir boyut vardır, parçalanma sıfırdır ve daha iyi olamaz! Bu nedenle, blok seviyesinde düzenlenen mantıksal hacimler, cihazların tekrar tekrar eklenmesi/çıkarılması için tasarlanmamıştır. İyi bir anlamda, mantıksal birimi blok düzeyinde yalnızca bir kez birleştirmeniz, onu dosya sistemine vermeniz ve daha sonra onunla başka hiçbir şey yapmamanız gerekir.
Ek olarak, bağımsız FS+LVM alt sistemlerinin birleşimi, mantıksal birimlerin toplandığı sürücülerin farklı yapısının dikkate alınmasına izin vermez. Aslında, HDD ve katı hal aygıtlarından mantıksal bir birim oluşturduğunuzu varsayalım. Ancak bu durumda birincisi birleştirme gerektirecek, ikincisi gerektirmeyecektir. İkincisi için, iptal talepleri göndermeniz gerekir, ancak ilki için değil, vb. Ancak bu kombinasyonda böyle bir seçiciliği göstermek oldukça zordur.
Dosya sisteminde kendi LVM'nizi oluşturduktan sonra durumun pek de iyileşmeyeceğini unutmayın. Üstelik bunu yaparak aslında onu gelecekte daha da geliştirme ihtimaline son vermiş olursunuz. Bu çok kötü. Aynı makinede farklı türdeki sürücüler yaşayabilir. Ve eğer dosya sistemi aralarında ayrım yapmazsa kim yapacak?
Başka bir sorun sözde olanı bekliyor. "Her Yere Yaz" dosya sistemleri (bağlama sırasında uygun işlem modelini belirttiyseniz bu aynı zamanda Reiser4'ü de içerir). Bu tür dosya sistemleri, güçlerinde benzeri görülmemiş birleştirme araçları sağlamalıdır. Ve düşük seviyeli ses seviyesi yöneticisi burada yardımcı olmuyor, yalnızca engel oluyor. Gerçek şu ki, böyle bir yöneticiyle, FS'niz yalnızca bir cihazın - sanal bir cihazın - ücretsiz bloklarının haritasını saklayacaktır. Buna göre yalnızca sanal bir cihazı birleştirebilirsiniz. Bu, birleştiricinizin devasa tek bir sanal adres alanı üzerinde çok uzun bir süre çalışacağı anlamına gelir.
Ve rastgele üzerine yazma işlemi yapan çok sayıda kullanıcınız varsa, bu tür bir birleştiricinin yararlı etkisi sıfıra düşecektir. Sisteminiz kaçınılmaz olarak yavaşlamaya başlayacak ve hayal kırıklığı yaratan "bozuk tasarım" tanısının önünde ellerinizi katlamanız yeterli olacaktır. Aynı adres alanında çalışan birden fazla birleştirici yalnızca birbirine müdahale eder. Her gerçek cihaz için kendi ücretsiz blok haritanızı korursanız, bu tamamen farklı bir konudur. Bu, birleştirme sürecini etkili bir şekilde paralelleştirecektir.
Ancak bu yalnızca üst düzey bir mantıksal birim yöneticiniz varsa yapılabilir. Bu tür yöneticilere sahip yerel dosya sistemleri daha önce mevcut değildi (en azından onları bilmiyorum). Yalnızca ağ dosya sistemlerinde (örneğin GlusterFS) bu tür yöneticiler vardı. Bir diğer çok önemli örnek ise birim bütünlük denetimi (fsck) yardımcı programıdır. Her alt hacim için kendi bağımsız boş blok haritanızı saklarsanız, mantıksal hacmi kontrol etme prosedürü etkili bir şekilde paralelleştirilebilir. Başka bir deyişle, üst düzey yöneticilere sahip mantıksal hacimler daha iyi ölçeklenir.
Ek olarak, düşük seviyeli birim yöneticileriyle tam teşekküllü anlık görüntüleri düzenleyemeyeceksiniz. LVM ve ZFS benzeri dosya sistemleriyle yalnızca yerel anlık görüntüler alabilirsiniz, ancak genel anlık görüntüler alamazsınız. Yerel anlık görüntüler, yalnızca normal dosya işlemlerini anında geri almanıza olanak tanır. Ve orada hiç kimse mantıksal hacimli işlemleri (cihaz ekleme/çıkarma) geri almayacaktır. Buna bir örnekle bakalım. Zamanın bir noktasında, 100 dosya içeren iki A ve B cihazının mantıksal birimine sahip olduğunuzda, S sisteminin anlık görüntüsünü alırsınız ve ardından başka bir yüz dosya daha oluşturursunuz.
Bundan sonra, biriminize C cihazını eklersiniz ve son olarak sisteminizi anlık görüntü S'ye geri döndürürsünüz. Soru: S'ye geri alma işleminden sonra mantıksal biriminiz kaç dosya ve cihaz içerir? Tahmin edebileceğiniz gibi 100 dosya olacak, ancak 3 cihaz olacak - bunlar aynı A, B ve C cihazlarıdır, ancak anlık görüntünün oluşturulduğu sırada sistemde yalnızca iki cihaz vardı (A ve B) ). C cihazını ekleme işlemi geri alınmadı ve şimdi C cihazını bilgisayardan kaldırırsanız, verileriniz bozulacaktır; bu nedenle silmeden önce, cihazı yeniden dengeleme mantıksal biriminden çıkarmak için ilk olarak pahalı bir işlem yapmanız gerekecektir. tüm verileri C cihazından A ve B cihazlarına dağıtacaktır. Ancak FS'niz küresel anlık görüntüleri destekliyorsa, bu tür bir yeniden dengeleme gerekli olmayacaktır ve S'ye anında geri dönüşten sonra C cihazını bilgisayardan güvenli bir şekilde kaldırabilirsiniz.
Bu nedenle, genel anlık görüntüler iyidir çünkü büyük miktarda veri içeren bir cihazın mantıksal bir birimden (mantıksal birime) maliyetli bir şekilde çıkarılmasından (eklenmesinden) kaçınmanıza olanak tanır (tabii ki, sisteminizin "anlık görüntüsünü" almayı hatırlarsanız) doğru zamanda). Anlık görüntüler oluşturmanın ve dosya sistemini onlara geri almanın anlık işlemler olduğunu hatırlatmama izin verin. Şu soru ortaya çıkabilir: Üç gününüzü alan mantıksal bir hacimdeki bir işlemi anında geri almak nasıl mümkün olabilir? Ama bu mümkün! Dosya sisteminizin doğru tasarlanmış olması şartıyla. Bu tür “3 boyutlu anlık görüntüler” fikri üç yıl önce aklıma geldi ve geçen yıl bu tekniğin patentini aldım.
Yerel FS'lerin ağdakilerden öğrenmesi gereken bir sonraki şey, meta verileri, ağ FS'lerinin ayrı makinelerde (meta veri sunucuları olarak adlandırılan) depoladığı gibi, ayrı cihazlarda depolamaktır. Öncelikle meta verilerle çalışan uygulamalar vardır ve bu uygulamalar, meta verilerin pahalı, yüksek performanslı depolama aygıtlarına yerleştirilmesiyle büyük ölçüde hızlandırılabilir. FS+LVM kombinasyonuyla böyle bir seçicilik gösteremezsiniz: LVM, kendisine ilettiğiniz blokta ne olduğunu bilmez (oradaki veriler veya meta veriler).
FS+LVM kombinasyonuna kıyasla kendi düşük seviyeli LVM'nizi FS'de uygulamaktan pek bir fayda elde edemezsiniz, ancak çok iyi yapabileceğiniz şey FS'yi daha sonra koduyla çalışmayı imkansız hale getirecek şekilde karmaşık hale getirmektir. Sanal cihazlarla akın eden ZFS ve Btrfs, mimari açıdan katmanlama ihlalinin sistemi nasıl öldürdüğünün açık örnekleri.Peki neden tüm bunlar benim? Üstelik dosya sistemine kendi düşük seviyeli LVM'nizi kurmanıza gerek yoktur. Bunun yerine, bazı ağ dosya sistemlerinin farklı makinelerde (depolama düğümleri) yaptığı gibi, cihazları yüksek düzeyde mantıksal birimler halinde toplamanız gerekir. Doğru, kötü algoritmaların kullanılması nedeniyle bunu iğrenç bir şekilde yapıyorlar.
Kesinlikle berbat algoritmalara örnek olarak GlusterFS dosya sistemindeki DHT çeviricisi ve Ceph dosya sistemindeki CRUSH haritası verilebilir. Gördüğüm algoritmaların hiçbiri basitlik ve iyi ölçeklenebilirlik açısından beni tatmin etmedi. Bu yüzden cebiri hatırlamam ve her şeyi kendim icat etmem gerekiyordu. 2015 yılında hash fonksiyonları üzerinde paketler üzerinde deneyler yaparken bana uygun bir şey buldum ve patentini aldım. Artık tüm bunları hayata geçirme girişiminin başarılı olduğunu söyleyebilirim. Yeni yaklaşımda ölçeklenebilirlikle ilgili herhangi bir sorun görmüyorum.
Evet, her alt cilt, bellekte süper blok gibi ayrı bir yapıya ihtiyaç duyacaktır. Bu çok mu korkutucu? Genel olarak, kimin "okyanusu kaynatacağını" ve tek bir yerel makinede yüzbinlerce veya daha fazla cihazdan oluşan mantıksal hacimler oluşturacağını bilmiyorum. Birisi bana bunu açıklayabilirse, çok minnettar olacağım. Bu arada benim için bu pazarlama saçmalığı.
Çekirdek blok aygıtı alt sistemindeki değişiklikler (örneğin, blk-mq'nin görünümü) FS uygulama gereksinimlerini nasıl etkiledi?
Hiçbir etkisi olmadı. Blok katmanında yeni bir FS tasarlamayı gerekli kılacak ne olacağını bilmiyorum. Bu alt sistemlerin etkileşim arayüzü çok zayıftır. Sürücü tarafında, FS yalnızca ilk önce blok katmanının ve ardından FS'nin ayarlanacağı yeni sürücü türlerinin görünümünden etkilenmelidir (reiser4 için bu, yeni eklentilerin ortaya çıkması anlamına gelecektir).
Yeni medya türlerinin ortaya çıkışı (örneğin, SMR veya SSD'lerin her yerde bulunması), dosya sistemi tasarımı için temelde yeni zorluklar anlamına mı geliyor?
Evet. Ve bunlar FS'nin gelişimi için normal teşviklerdir. Zorluklar farklı ve tamamen beklenmedik olabilir. Örneğin, bir G/Ç işleminin hızının büyük ölçüde veri parçasının boyutuna ve uzaklığına bağlı olduğu sürücüleri duydum. FS bloğunun boyutunun sayfa boyutunu aşamadığı Linux'ta, böyle bir sürücü varsayılan olarak tüm yeteneklerini göstermez. Ancak dosya sisteminiz doğru tasarlanmışsa, bundan çok daha fazlasını elde etme şansınız vardır.
Şu anda Reiser4 koduyla sizin dışınızda kaç kişi çalışıyor?
İstediğimden daha az ama ciddi bir kaynak sıkıntısı da yaşamıyorum. Reiser4'ün gelişim hızından fazlasıyla memnunum. "At sürmeyeceğim" - bu doğru alan değil. Burada, “Daha sessiz sürersen yola devam edersin!” Modern bir dosya sistemi, en karmaşık çekirdek alt sistemidir ve yanlış tasarım kararları, sonraki yıllardaki insan emeğini mahvedebilir.
Gönüllülere bir şeyi hayata geçirme teklifinde bulunarak, ciddi ihtiyaçlarda talep edilebilecek çabaların mutlaka doğru sonuca varacağını her zaman garanti ediyorum. Anladığınız gibi, aynı anda bu kadar çok garanti olamaz. Aynı zamanda, açıkça kullanılamaz olan yazılımların "özelliklerini" utanmadan tanıtan, yüzlerce kullanıcıyı ve geliştiriciyi aldatan ve aynı zamanda çekirdek zirvelerinde oturup gülümseyen "figürlere" dayanamıyorum.
Herhangi bir şirket Reiser4'ün gelişimini destekleme isteğini ifade etti mi?
Evet, böyle teklifler vardı. ve büyük bir satıcıdan. Ancak bunun için başka bir ülkeye taşınmak zorunda kaldım. Maalesef artık 30 yaşında değilim, ilk düdükte öylece ayrılamam.
Şu anda Reiser4'te hangi özellikler eksik?
Basit birimler için ReiserFS(v3)'te bulunana benzer bir "yeniden boyutlandırma" işlevi yoktur. Ayrıca DIRECT_IO bayrağıyla yapılan dosya işlemlerinin de zararı olmaz. Daha sonra, bir birimi sabit bir boyutu olmayan ve bağımsız birimler olarak monte edilebilen “anlamsal alt birimlere” ayırabilmek istiyorum. Bu sorunlar, "gerçek olanı" denemek isteyen yeni başlayanlar için iyidir.
Ve son olarak, basit uygulama ve yönetime sahip ağ mantıksal hacimlerine sahip olmak istiyorum (modern algoritmalar buna zaten izin veriyor). Ancak Reiser4'ün kesinlikle asla sahip olamayacağı şey, RAID-Z, temizlemeler, boş alan önbellekleri, 128 bit değişkenler ve bazı dosya sistemlerinin geliştiricileri arasındaki fikir eksikliğinin arka planında ortaya çıkan diğer pazarlama saçmalıklarıdır.
İhtiyaç duyulabilecek her şey eklentiler tarafından uygulanabilir mi?
Yalnızca bunları uygulayan arayüzler ve eklentiler (modüller) açısından konuşursak, o zaman her şey değil. Ancak bu arayüzlere ilişkileri de dahil ederseniz, diğer şeylerin yanı sıra, halihazırda idare edebileceğiniz daha yüksek polimorfizm kavramlarına sahip olursunuz. Nesne yönelimli bir çalışma zamanı sistemini varsayımsal olarak dondurduğunuzu, talimat işaretçisinin değerini aynı X arayüzünü uygulayan başka bir eklentiyi işaret edecek şekilde değiştirdiğinizi ve ardından sistemin donmasını çözerek çalışmaya devam ettiğini hayal edin.
Eğer son kullanıcı böyle bir “ikame”yi fark etmezse o zaman sistemin X arayüzünde sıfır dereceli polimorfizme sahip olduğunu (veya sistemin X arayüzünde heterojen olduğunu, ki bu da aynı şeydir) deriz. Artık yalnızca bir dizi arayüzünüz değil, aynı zamanda bunlar üzerinde ilişkiler de varsa (arayüz grafiği), o zaman herhangi bir arayüzün "mahallesinde" zaten bulunan sistemin heterojenliğini karakterize edecek daha yüksek dereceli polimorfizmleri tanıtabilirsiniz. Uzun zaman önce böyle bir sınıflandırmayı başlattım ama ne yazık ki hiç olmadı.
Yani, eklentilerin ve bu tür yüksek polimorfizmlerin yardımıyla, bilinen herhangi bir özelliği tanımlayabileceğiniz gibi, hiç bahsedilmemiş olanları da "tahmin edebilirsiniz". Bunu tam olarak kanıtlayamadım ama henüz karşıt bir örnek de bilmiyorum. Bu soru genel olarak bana Felix Klein’ın “Erlangen Programı”nı hatırlattı. Bir zamanlar tüm geometriyi cebirin bir dalı (özellikle grup teorisi) olarak temsil etmeye çalıştı.
Şimdi asıl soruya gelelim: Reiser4'ün ana çekirdeğe tanıtımında işler nasıl gidiyor? Son röportajınızda bahsettiğiniz bu dosya sisteminin mimarisi hakkında herhangi bir yayın var mıydı? Bu soru sizin bakış açınıza ne kadar uygun?
Genel olarak üç yıldır ana branşa dahil olmak için talepte bulunuyoruz. Reiser'in, çekme talebinin yapıldığı halka açık başlıktaki son yorumu yanıtsız kaldı. Yani diğer tüm sorular bizim için değil. Kişisel olarak neden belirli bir işletim sistemiyle "birleşmemiz" gerektiğini anlamıyorum. Linux'ta ışık bir kama gibi birleşmiyordu. Dolayısıyla, farklı işletim sistemleri için birkaç şube bağlantı noktasının bulunacağı ayrı bir depo vardır. Kimin ihtiyacı varsa ilgili bağlantı noktasını kopyalayabilir ve onunla istediğini yapabilir (tabii ki lisans kapsamında). Birisinin buna ihtiyacı yoksa, o zaman bu benim sorunum değil. Bu noktada “ana Linux çekirdeğine yükseltme” sorununu çözümlenmiş olarak değerlendirmeyi öneriyorum.
FS mimarisiyle ilgili yayınlar konuyla alakalı, ancak şu ana kadar yalnızca yeni sonuçlarım için zaman bulabildim ve bunun daha yüksek bir öncelik olduğunu düşünüyorum. Başka bir şey de ben bir matematikçiyim ve matematikte herhangi bir yayın teoremlerin ve onların kanıtlarının bir özetidir. Orada herhangi bir şeyi kanıt olmadan yayınlamak kötü zevkin işaretidir. FS'nin mimarisiyle ilgili herhangi bir ifadeyi iyice kanıtlarsam veya çürütürsem, sonuç öyle yığınlar olacaktır ki, üstesinden gelinmesi oldukça zor olacaktır. Kimin ihtiyacı var? Muhtemelen her şeyin eski haliyle (kaynak kodu ve ona yapılan yorumlar) kalmaya devam etmesinin nedeni budur.
Son birkaç yılda Reiser4'teki yenilikler neler?
Uzun zamandır beklenen istikrar nihayet gerçekleşti. Ortaya çıkan son hatalardan biri, "silinemez" dizinlere yol açan bir hataydı. Zorluk, yalnızca ad karması çarpışmalarının arka planında ve bir ağaç düğümündeki dizin kayıtlarının belirli bir konumunda ortaya çıkmasıydı. Ancak yine de üretim için Reiser4'ü öneremiyorum: bunun için üretim sistemi yöneticileriyle aktif etkileşim kurarak bazı çalışmalar yapmanız gerekiyor.
Uzun süredir devam eden fikrimizi, farklı işlem modellerini nihayet hayata geçirmeyi başardık. Daha önce Reiser4 yalnızca bir sabit kodlu Macdonald-Reiser modelini çalıştırıyordu. Bu tasarım sorunları yarattı. Özellikle, böyle bir işlem modelinde anlık görüntülerin alınması mümkün değildir; bunlar "ÜZERİNDE YAZMA SET" adı verilen atomik bir bileşen tarafından bozulacaktır. Reiser4 şu anda üç işlem modelini desteklemektedir. Bunlardan birinde (Her Yere Yaz), ÜZERİNE YAZMA SETİ atomik bileşeni yalnızca "fotoğrafı çekilemeyen" (tavuk ve yumurta sorunu) sistem sayfalarını (disk bitmap görüntüleri vb.) içerir.
Böylece resimler artık mümkün olan en iyi şekilde gerçekleştirilebilir. Başka bir işlem modelinde, değiştirilen tüm sayfalar yalnızca ÜZERİNE YAZMA SETİNE gider (yani, esasen saf günlük kaydıdır). Bu model, Reiser4 bölümlerinin hızlı parçalanmasından şikayetçi olanlar içindir. Artık bu modelde bölümünüz ReiserFS'den (v3) daha hızlı parçalanmayacaktır. Mevcut üç modelin tümü, bazı çekincelerle, operasyonların atomikliğini garanti eder, ancak atomiklik kaybı olan ve yalnızca bölümün bütünlüğünü koruyan modeller de yararlı olabilir. Bu tür modeller, halihazırda bu işlevlerden bazılarını üstlenmiş olan her türlü uygulama (veritabanları vb.) için faydalı olabilir. Bu modelleri Reiser4'e eklemek çok kolay ama ben yapmadım çünkü kimse bana sormadı ve kişisel olarak buna ihtiyacım da yok.
Meta veri sağlama toplamları ortaya çıktı ve yakın zamanda bunları "ekonomik" aynalarla (hala kararsız malzeme) tamamladım. Herhangi bir bloğun sağlama toplamı başarısız olursa, Reiser4 karşılık gelen bloğu kopya cihazından hemen okur. ZFS ve Btrfs'nin bunu yapamayacağını unutmayın: tasarım buna izin vermiyor. Orada "fırçalama" adı verilen özel bir arka plan tarama işlemi çalıştırmalı ve sorunlu bloğa ulaşmasını beklemelisiniz. Programcılar mecazi anlamda bu tür olayları "koltuk değneği" olarak adlandırıyor.
Ve son olarak, ZFS, Btrfs, blok katmanı ve FS+LVM kombinasyonlarının prensipte sağlayamadığı her şeyi sunan heterojen mantıksal birimler ortaya çıktı: paralel ölçeklendirme, O(1) disk adresi ayırıcı, alt birimler arasında şeffaf veri geçişi. İkincisi ayrıca bir kullanıcı arayüzüne sahiptir. Artık en sıcak verileri biriminizdeki en yüksek performanslı sürücüye kolayca taşıyabilirsiniz.
Ek olarak, herhangi bir kirli sayfayı acilen böyle bir sürücüye aktarmak mümkündür, böylece sıklıkla fsync(2) çağrısı yapan uygulamaları önemli ölçüde hızlandırabilirsiniz. Bcache adı verilen blok katmanı işlevselliğinin hiçbir şekilde böyle bir hareket özgürlüğü sağlamadığını belirtmek isterim. Yeni mantıksal hacimler benim algoritmalarıma dayanıyor (ilgili patentler var). Yazılım zaten oldukça kararlı, denemek, performansı ölçmek vb. oldukça mümkün. Tek rahatsızlık, şimdilik birim yapılandırmasını manuel olarak güncellemeniz ve bir yerde saklamanız gerekmesidir.
Şu ana kadar fikirlerimi yüzde 10 oranında hayata geçirmeyi başardım.Ancak, en zor şey olarak gördüğüm şeyi başardım: mantıksal hacimleri, reiser4'teki tüm ertelenmiş eylemleri gerçekleştiren bir flash prosedürle bağlamak. Bunların hepsi hala deneysel “format41” dalındadır.
Reiser4 xfstest'leri geçiyor mu?
En azından son sürümü hazırlarken benim için öyle oldu.
Prensip olarak Reiser4'ü eklentileri kullanarak bir ağ (küme) FS yapmak mümkün müdür?
Mümkün ve hatta gerekli! Düzgün tasarlanmış bir yerel dosya sistemini temel alan bir ağ dosyası oluşturursanız sonuç çok etkileyici olacaktır! Modern ağ FS'lerinde, herhangi bir yerel FS kullanılarak uygulanan bir arka uç depolama düzeyinin varlığından memnun değilim. Bu seviyenin varlığı tamamen haksızdır. Ağ FS'si doğrudan blok katmanıyla etkileşime girmeli ve yerel FS'den başka hizmet dosyaları oluşturmasını istememelidir!
Genel olarak dosya sistemlerini yerel ve ağ olarak ayırmak kötülüktendir. Otuz yıl önce kullanılan ve yerine henüz hiçbir şey önerilmeyen algoritmaların kusurlarından kaynaklandı. Bu aynı zamanda çok sayıda gereksiz yazılım bileşeninin (çeşitli hizmetler vb.) ortaya çıkmasının da nedenidir. İyi bir şekilde, çekirdek modülü biçiminde yalnızca bir FS ve her makinede kurulu bir dizi kullanıcı yardımcı programı olmalıdır - bir küme düğümü. Bu FS hem yerel hem de ağdır. Ve daha fazlası değil!
Linux'ta Reiser4 ile hiçbir şey yolunda gitmezse, FreeBSD için bir FS teklif etmek isterim (önceki bir röportajdan alıntı: “...FreeBSD... akademik köklere sahiptir... Ve bu, yüksek derecede olasılıkla biz geliştiricilerle ortak bir dil bulacaktır”)?
Yani, az önce öğrendiğimiz gibi, Linux'ta her şey zaten mükemmel bir şekilde çalıştı: bunun için depomuzun ana dalı biçiminde ayrı bir çalışan Reiser4 bağlantı noktası var. FreeBSD'yi unutmadım! Teklif! FreeBSD'nin içini iyi bilenlerle yakın çalışmaya hazırım. Bu arada: Topluluklarıyla ilgili gerçekten hoşuma giden şey, oradaki kararların bağımsız uzmanlardan oluşan güncellenmiş bir konsey tarafından alınması ve bunun hükümetin kalıcı bir kişiyi aldatmasıyla hiçbir ilgisi yok.
Bugünkü Linux kullanıcı topluluğunu nasıl değerlendiriyorsunuz? Daha “pop” hale mi geldi?
İşimin doğası gereği bunu değerlendirmem oldukça zor. Çoğunlukla kullanıcılar bana hata raporları ve bölümün düzeltilmesi yönünde isteklerle geliyor. Kullanıcı olarak kullanıcılar. Bazıları daha anlayışlı, bazıları daha az. Herkese aynı davranılıyor. Kullanıcı talimatlarımı görmezden gelirse kusura bakmayın: yoksayma emri benim tarafımdan da girilecek.
Önümüzdeki beş ila on yıl boyunca dosya sistemlerinin gelişimini tahmin etmek mümkün mü? FS geliştiricilerinin karşılaşabileceği temel zorlukların neler olduğunu düşünüyorsunuz?
Evet böyle bir tahminde bulunmak zor değil. Uzun süredir yukarı yönde dosya sistemlerinde herhangi bir gelişme yaşanmadı. Sadece bunun görünümü yaratılır. Yerel dosya sistemi geliştiricileri, zayıf tasarımla ilgili sorunlarla karşılaştı. Burada bir uyarı yapmak gerekiyor. Kodun "depolanması", "yalanması" ve taşınması olarak adlandırılan işlemleri geliştirme ve geliştirme olarak görmüyorum. Ve “Btrfs” denilen yanlış anlaşılmayı da daha önce açıkladığım sebeplerden dolayı bir gelişme olarak sınıflandırmıyorum.
Her yama sorunları daha da kötüleştirir. Kuyu. ve her zaman "her şeyin işe yaradığını" düşünen çeşitli türde "vaizler" vardır. Temel olarak bunlar okul çocukları ve dersleri atlayan öğrencilerdir. Bir düşünün: onun işine yarıyor ama profesörün yaramıyor. Bu nasıl bir adrenalin patlamasıdır! Benim açımdan en büyük zarar, Btrfs'in harika özelliklerini systemd, docker vb. her türlü katmana coşkuyla "vidalamak" için acele eden "zanaatkarlar"dan kaynaklanıyor. - bu zaten metastaza benziyor.
Şimdi beş ila on yıllık bir tahmin yapmaya çalışalım. Reiser4'te yapacaklarımızı daha önce kısaca listelemiştim. Yukarı yöndeki yerel FS geliştiricileri için asıl zorluk, maaş karşılığında iyi bir iş yapamamak olacaktır (evet, zaten bu hale geldi). Veri depolama alanında herhangi bir fikirleri olmadan bu talihsiz VFS, XFS ve ext4'e yama yapmaya devam edecekler. Bu arka planda VFS'nin durumu özellikle komik görünüyor; şeflerin bulunmadığı ve şeflerin beklenmediği bir restoranın çılgınca modernizasyonunu anımsatıyor.
Artık VFS kodu, herhangi bir koşul olmaksızın, birden fazla bellek sayfasını aynı anda kilitler ve temeldeki FS'yi bunlar üzerinde çalışmaya davet eder. Bu, Ext4'ün silme işlemlerindeki performansını artırmak için tanıtıldı, ancak anlaşılması kolay olduğu gibi, bu tür eşzamanlı kilitleme, gelişmiş işlem modelleriyle tamamen uyumsuzdur. Yani çekirdeğe bazı akıllı dosya sistemleri için destek ekleyemezsiniz. Linux'un diğer alanlarında durumun ne olduğunu bilmiyorum ama dosya sistemleri söz konusu olduğunda buradaki herhangi bir gelişmenin Torvalds'ın pratikte izlediği politikayla uyumlu olması pek mümkün değil (akademik projeler atılıyor ve dolandırıcılar B ağacının ne olduğu hakkında hiçbir fikrim yok, sonsuz güven kredisi veriliyor). Bu nedenle yavaş yavaş çürümeye doğru bir rota belirlendi. Elbette bunu “kalkınma” olarak yansıtmak için ellerinden geleni yapacaklar.
Dahası, dosya sistemlerinin "koruyucuları", yalnızca "depolama"dan fazla bir kazanç sağlayamayacağınızı fark ederek, daha karlı bir iş için ellerinden geleni yapacaklardır. Bunlar kural olarak dağıtılmış dosya sistemleri ve sanallaştırmadır. Belki de moda olan ZFS'yi henüz var olmayan başka bir yere taşıyacaklar. Ancak, yukarı akıştaki tüm FS gibi, bir Yeni Yıl ağacını andırıyor: eğer üstüne başka küçük şeyler asabilirseniz, o zaman daha derine inemezsiniz. ZFS'ye dayalı ciddi bir kurumsal sistem kurmanın mümkün olduğunu kabul ediyorum, ancak şu anda geleceği tartıştığımız için ZFS'nin bu konuda umutsuz olduğunu üzülerek söyleyebilirim: adamlar sanal cihazlarıyla oksijeni kestiler kendilerinin ve gelecek nesillerin daha da gelişmesi için. ZFS geçmişte kaldı. Ve ext4 ve XFS dünden önceki gün bile değil.
Sansasyonel "Yeni nesil Linux dosya sistemi" konseptinden ayrı olarak bahsetmeye değer. Bu, tabiri caizse Linux'taki "dosya sistemlerinin geleceğini belirli karakterlerin arkasına sabitleme" fırsatı için yaratılmış tamamen politik ve pazarlama amaçlı bir projedir. Gerçek şu ki Linux eskiden “sadece eğlence içindi”. Ama artık öncelikle bir para kazanma makinesi. Mümkün olan her şey üzerinde yapılırlar. Örneğin, iyi bir yazılım ürünü yaratmak çok zordur, ancak akıllı "geliştiriciler" uzun zamandır hiçbir şekilde zorlanmaya gerek olmadığını fark ettiler: her türlü kamuoyunda duyurulan ve tanıtılan, var olmayan bir yazılımı başarıyla satabilirsiniz. etkinlikler - asıl önemli olan sunum slaytlarının daha fazla "özellik" içermesidir.
Dosya sistemleri bunun için mükemmeldir çünkü sonuç için on yıl boyunca güvenle pazarlık yapabilirsiniz. Birisi daha sonra bu sonucun eksikliğinden şikayet ederse, dosya sistemleri hakkında hiçbir şey anlamıyor demektir! Bu bir finansal piramidi anımsatıyor: En tepede bu karışıklığı başlatan maceracılar ve "şanslı" olan birkaç kişi var: "temettüleri geri çektiler", yani. Gelişim için para aldılar, yönetici olarak iyi maaşlı bir işe girdiler, konferanslara “ortaya çıktılar” vb.
Daha sonra "şanssız" olanlar gelir: kayıpları sayarlar, kullanılamaz bir yazılım ürününü üretime yerleştirmenin sonuçlarıyla uğraşırlar, vb. Çok daha fazlası var. Piramidin tabanında işe yaramaz kodları "kesen" büyük bir geliştirici kitlesi var. En büyük kaybedenler onlardır çünkü boşa harcanan zaman geri döndürülemez. Bu tür piramitler Torvalds ve arkadaşları için son derece faydalıdır. Ve bu piramitler ne kadar çok olursa onlar için o kadar iyi olur. Bu tür piramitleri beslemek için çekirdeğe her şey alınabilir. Tabii kamuoyunda bunun tersini söylüyorlar. Ama sözlerle değil eylemlerle yargılarım.
Dolayısıyla, "Linux'ta dosya sistemlerinin geleceği" yine çokça tanıtılan ancak pek kullanışlı olmayan bir başka yazılımdır. Btrfs'den sonra, büyük olasılıkla, böyle bir "geleceğin" yerini, Linux blok katmanını bir dosya sistemiyle geçmeye yönelik başka bir girişim olan Bcachefs alacaktır (kötü bir örnek bulaşıcıdır). Ve tipik olan şey: Btrfs'deki sorunların aynısı var. Uzun süre bundan şüphelendim ve sonra bir şekilde dayanamadım ve koda baktım - bu doğru!
Bcachefs ve Btrfs'in yazarları, FS'lerini oluştururken, onlar hakkında çok az şey anlayarak diğer insanların kaynaklarını aktif olarak kullandılar. Durum, çocuk oyunu "kırık telefon"u çok anımsatıyor. Ve bu kodun çekirdeğe nasıl dahil edileceğini kabaca hayal edebiliyorum. Aslında hiç kimse “tırmıkları” görmeyecek (daha sonra herkes üzerlerine basacak). Kodun stili, var olmayan ihlal suçlamaları vb. Hakkında sayısız tartışmadan sonra, yazarın "sadakati", diğer geliştiricilerle ne kadar iyi "etkileşime girdiği" ve tüm bunların ne kadar başarılı olabileceği hakkında bir sonuca varılacaktır. Daha sonra şirketlere satılacak.
Nihai sonuç kimseyi ilgilendirmeyecek. Belki yirmi yıl önce ilgimi çekerdi ama şimdi sorular farklı soruluyor: Önümüzdeki on yıl içinde belirli kişilerin istihdam edilmesini sağlayacak şekilde bunu teşvik etmek mümkün olacak mı? Ve ne yazık ki, nihai sonucu merak etmek alışılmış bir şey değil.
Genel olarak, dosya sisteminizi sıfırdan yeniden keşfetmeye başlamamanızı şiddetle tavsiye ederim. Çünkü on yıl içinde rekabetçi bir şeye ulaşmak için önemli finansal yatırımlar bile yeterli olmayacaktır. Tabii ki, çekirdeğe "itilmesi" amaçlananlardan değil, ciddi projelerden bahsediyorum. Yani kendinizi ifade etmenin daha etkili bir yolu da bizim gibi gerçek gelişmelere katılmaktır. Elbette bunu yapmak kolay değil; ancak bu, herhangi bir üst düzey proje için geçerlidir.
Öncelikle önereceğim sorunun bağımsız olarak üstesinden gelmeniz gerekecek. Bundan sonra niyetinizin ciddiyetine ikna olarak yardım etmeye başlayacağım. Geleneksel olarak yalnızca kendi geliştirmelerimizi kullanırız. İstisnalar sıkıştırma algoritmaları ve bazı karma işlevlerdir. Geliştiricileri konferanslara seyahat etmeye göndermiyoruz ve çoğu startup'ta olduğu gibi oturup diğer insanların fikirlerini ("belki ne olacak") birleştirmeyiz.
Tüm algoritmaları kendimiz geliştiriyoruz. Şu anda veri depolama biliminin cebirsel ve kombinatoryal yönleriyle ilgileniyorum. Özellikle sonlu alanlar, asimptotikler, eşitsizliklerin ispatı. Sıradan programcılar için de iş var ama sizi hemen uyarmalıyım: "başka bir FS'ye bakıp aynısını yapın" yönündeki tüm öneriler göz ardı ediliyor. VFS aracılığıyla Linux ile daha yakın entegrasyona yönelik yamalar da oraya gidecek.
Yani tırmığımız yok ama nereye gitmemiz gerektiğine dair bir anlayışımız var ve bu yönün doğru olduğuna dair inancımız var. Bu anlayış gökten kudret helvası şeklinde gelmedi. Arkamızda 29 yıllık geliştirme tecrübemiz olduğunu, sıfırdan yazılmış iki dosya sistemimizin olduğunu hatırlatmama izin verin. Ve aynı sayıda veri kurtarma yardımcı programı. Ve bu çok fazla!
Kaynak: opennet.ru