Linus Torvalds ve OS X Dosya Sistemi

2008'de Linus Torvalds ünlü bir röportajında "OS X'in bir şekilde programlamak için Windows'tan daha kötü olduğunu söyledi. Dosya sistemleri eksiksiz ve son derece saçma." OS X dosya sistemi (muhtemelen HFS +) hakkında neden bu şekilde hissettiği hakkında daha fazla ayrıntı aradım, ancak hiçbir şey bulamadım.

Linus, temel Unix dosya sistemi modelinden kesinlikle hoşlanmıyor ve HFS + 'dan büyük / küçük harfe duyarlı olmadığından nefret ediyorum. Ve ne kadar kışkırtıcı bir şekilde yorumuna hitap edilse de, tamamen değersiz olduğuna şüpheliyim. Yorum, OS X için programlama bağlamında olduğu için, görüşünün performansa, sağlamlığa, işletim sistemi arayüzüne veya bu çizgilerdeki bir şeye bağlı olabileceğinden şüpheleniyorum. 2008 döneminde Linus'un 2008 döneminde HFS + ile ne gibi şikayetleri olduğunu bilen var mı?

Linus'un yorumu yaptığı “Soru ve Cevap” oturumunun bir kopyası mevcut, ancak ayrıntılı bir şekilde hazırlanmasının istenmediği görülüyor. HFS + hakkındaki görüşünün daha derinlemesine bir analizinin başka bir yere yazılıp yazılmadığından emin değilim.

Başka birinin konuyu incelemesi için John Siracusa'nın Mac OS X incelemelerine göz atabilirsiniz. Özellikle, “ HFS + ile ilgili sorun nedir ” başlıklı bir bölümü olan Mac OS X Lion için olanı, en göze çarpan bit'in (benimkine önem verdiğini) düşünüyorum:

Eşzamanlılık, doğru bayt sırası ile yazılmış meta veriler, ikinci saniye tarihi kesinliği, büyük hacimli boyutlar için destek ve seyrek dosya desteği, Unix dosya sistemlerinin ortak özellikleridir. Mac OS X, elbette, bir Unix temeli üzerine kuruludur. HFS + klasik Mac OS'den Mac OS X'e taşındığında, Unix dosya sistemlerinden beklenen bazı minimum özellikler kümesini desteklemek için genişletilmesi gerekiyordu .

Bu özelliklerden bazıları kolay bir uyum sağlamıştır, ancak diğerleri geriye dönük uyumluluğu bozmadan dosya sistemine eklemek çok zordu. Özellikle korkutucu bir örnek, HFS + üzerindeki sabit bağlantıların uygulanmasıdır. Sabit bağlantıları izlemek için HFS +, birimin kök düzeyinde gizli bir dizinde bulunan her sabit link için ayrı bir dosya oluşturur. Gizli dizinler başlamak için biraz ürkütücüdür, ancak asıl korkma, gereksiz veri çoğaltmasını önlemek için Time Machine'in zor bağlantılar kullanarak uygulandığını hatırladığınızda gelir.

Buradaki önemli nokta, Mac OS X'in Unix sistemi için bile tasarlanmamış bir dosya sistemi kullanıyor olması, klasik Mac OS için tasarlanmış ve geriye dönük uyumluluğu koruyarak Mac OS X 10.0'ın özelliklerini uygulamak için yamalı olması. Apple daha sonra “sıfırdan bir tasarım” yaklaşımı yerine aynı yama yaklaşımını kullanarak Mac OS X 10.7'de (günlük kaydı, meta veriler, dosya sistemi olayları ...) sahip olduğu ek özellikleri uyguladı. Bunu teknik olmayan bir şekilde nasıl açıklayacağımdan emin değilim, ancak bu ek özelliklerin hepsinin onları destekleyecek şekilde tasarlanmamış klasik bir Mac OS temeli üzerinde durduğunu söyleyebilirsiniz. Bu, çözümün olabileceği kadar iyi olmadığı anlamına gelir. Siracusa'nın tartışmaya devam ettiği örnek, HFS + sınırlamaları içinde çalışırken Apple'ın zor bağlantılar için kullanmak zorunda olduğu çözümün, HFS +'nın aynı zamanda hiçbir zaman verilerle ilgilenmeyecek şekilde tasarlandığı gerçeği ile birleştirilen donanım arızasına karşı çok hassas olmasıdır. bütünlük. Elbette, klasik Mac OS ile uyumluluğun korunması, Mac OS X 10.0'da arzu edilen bir sınırlamaydı, ancak artık Mac OS X 10.7'de değil.

İşletim Sistemi uzmanı olmasam ve Windows'tan geldikten sonra OSX'i kullanmaya yeni başlamama rağmen, kendimi Windows'ta bir PowerUser ve Linux'ta oldukça yetkin buluyorum. Bu arka plandan yola çıkarak, OSX gibi oldukça modern bir işletim sisteminde, dosya sisteminin, dosya adlarının "karıştırılmaması" gibi tuhaflıklar olduğuna şaşırdım.

Linus’un HFS + ile ilgili sorunlarının aynı noktadan kaynaklandığını anlıyorum: sorunu araştırırken bulduklarımdan itibaren, HFS + Unicode kullanarak dosyaların adlarını saklar, ancak bir dosya "genişletilmiş" veya NON-ASCII karakterleri (á gibi) kullandığında é, í, ó, ú, ñ İspanyolca ya da ü. Almanca'daki gibi şeyler), Unicode isminin kodlanmasında 2 yol sağlar, OSX saklanma zamanında kodlamayı sessizce "normalleştirir" ... dosya OSX'de oluşturuldu ve tüketildi, ancak diğer işletim sistemlerinin kullanıcıları ile bilgi paylaştığınızda , dosyanın isminin değişmesi, her tür garip davranışa neden oluyor ...

Örnek olarak: Son 8 artı yıl boyunca çalışmamı Subversion'da "eserler" (dosyalar, belgeler vb.) İzliyorum. Mac’e taşınırken Mac’in SVN istemcisini aldım ve ilgili dizinlerimden bir Checkout yaptıktan sonra , aksanlı tüm dosyaların eksik olduğunu ve aynı ada sahip yeni bir dosyanın sürümsiz olarak göründüğünü gördüm. İçine kazma, sorunları dosya sistemi IN dosya elma kodlu iken, depodaki veri başka bir (mükemmel geçerli ve meşru) Unicode kodlama kullanır ...

Bu, bence verilerimin brüt bir kargaşası. Apple DOES, dosya adı kodlamasının her iki biçimini de (Windows'ta bir paylaşıma erişmek veya Windows'tan bir USB çubuğu kullanmak uygun dosya adlarını vb. Gösterir) anlar ancak dosya oluşturma zamanında "daha iyi bildiği" kararına varılır ve dosyaları yeniden adlandırır. ..

Yine çoğu kullanıcının farkına varamayacağı bir şey değil - bir dosyanın kopyasını alıncaya veya yeniden adlandırdıktan sonra, orijinal dosyanın bulunduğu yere geri koyup, görünüşte aynı olan iki dosyayla bitirin !!!)

John Siracusa ve Dan Benjamin, HFS + 'in Hypercritical # 56'daki bazı dezavantajlarını tartışıyor .

HFS + 'da veri bozulmasını giderir ve ZFS'nin bazı özelliklerini dikkate alır.