Neden Linux'un dosya sistemi tek bir dizin ağacı olarak tasarlandı?

Linux'un neden tek bir dizin ağacı olarak tasarlandığını açıklayan var mı?

Oysa Windows'ta birden fazla sürücümüz olabilir C:\ve D:\Unix'te tek bir kök var. Herhangi bir özel sebep var mı?

Unix dosya sistemi uzun yıllar Windows’u ön plana çıkardığı için, “Windows neden her aygıt için ayrı bir gösterici kullanıyor?” Sorusu yeniden ifade edilebilir.

Hiyerarşik bir dosya sistemi, herhangi bir dosya veya dizinin kök dizinin alt öğesi olarak bulunabilme avantajına sahiptir. Verileri yeni bir cihaza veya bir ağ cihazına taşımanız gerekirse, dosya sistemindeki konum aynı kalabilir ve uygulama farkı görmez.

İşletim sisteminin statik olduğu ve yüksek G / Ç gereksinimleri olan bir uygulamanın olduğu bir sisteminiz olduğunu varsayalım. SSD sürücülerine salt okunur / usr bağlayabilir ve (uygulama orada yaşıyorsa) koyabilir / seçebilir. Dosya sistemi hiyerarşisi değişmez. Windows'ta bu özellikle C: \ Program Files \ altında yaşamakta ısrar eden uygulamalarla daha zor.

Bu kısmen tarihsel nedenlerden ve kısmen de bu şekilde daha mantıklı olduğu için.

Multics'in

Multics , bugün bildiğimiz hiyerarşik dosya sistemini , dizinleri içerebilen dizinlerle tanıtan ilk işletim sistemiydi . RC Daley ve PG Neumann tarafından “İkincil Depolama İçin Genel Amaçlı Bir Dosya Sistemi” Atıf :

Makalenin 2. Bölümü sistemin esnek kullanımına izin veren hiyerarşik dosyaların yapısını sunar. Bu yapı çok yönlülüğü sağlamak için yeterli yetenekler içermektedir. (...)

Anlama kolaylığı için, dosya yapısı, bazıları dizin olan bir dosya ağacı olarak düşünülebilir. Yani, bir istisna dışında, her bir dosya (örneğin, her bir dizin) kendisini doğrudan bir dizinde tam olarak bir dizinde tam olarak işaret ettiği şekilde bulur. Bunun istisnası, ağacın kökündeki kök dizini veya köküdür. Açıkça herhangi bir dizine işaret edilmese de, kök, dosya sistemi tarafından bilinen hayali bir dal tarafından örtük olarak belirtilir. (...)

Herhangi bir zamanda, bir kullanıcının çalışma dizini adı verilen bir dizinde işlem yaptığı kabul edilir. Çalışma dizinindeki bir girişin işaret ettiği bir dosyaya yalnızca giriş adını belirterek etkili bir şekilde erişebilir. Aynı anda birden fazla kullanıcı aynı çalışma dizinine sahip olabilir.

Diğer birçok açıdan olduğu gibi, Multics esneklik istedi. Kullanıcılar, dosya sisteminin bir alt ağacında çalışabilir, gerisini görmezden gelebilir ve yine de dosyalarını düzenlemek için dizinlerden faydalanabilir. Dizinler aynı zamanda erişim kontrolü için de kullanılıyordu - READ özelliği kullanıcıların bir dizindeki dosyaları listelemelerine izin veriyordu ve EXECUTE özelliği de kullanıcıların bu dizindeki dosyalara erişmesine izin veriyordu (bu, diğer birçok özellik gibi, unix'te yaşanıyordu).

Multics ayrıca tek bir depolama havuzuna sahip olma ilkesini takip etti. Kağıt bu konuda durmuyor. Tek bir depolama havuzu zamanın donanımıyla iyi bir uyuşuyordu: en azından hiçbirinin umursayacağı hiçbiri çıkarılabilir depolama cihazı yoktu. Multics ayrı bir yedekleme depolama havuzuna sahipti, ancak bu kullanıcılar için şeffaftı.

Unix

Unix, Multics'ten çok ilham aldı, ancak sadeliği hedeflerken, Multics esnekliği hedefledi.

Tek bir hiyerarşik dosya sistemi Unix'e çok yakışmış. Multics'te olduğu gibi, depolama havuzları genellikle kullanıcılarla ilgili değildi. Ancak, çıkarılabilir aygıtlar vardı ve Unix bunları mountve umountkomutları aracılığıyla kullanıcılara maruz bıraktı (“süper kullanıcıya, yani yöneticiye ayrıldı). In “UNIX Zaman Paylaşım Sistemi” , Dennis Ritchie ve Ken Thompson açıklamak:

Dosya sisteminin kökü her zaman aynı cihazda depolansa da, tüm dosya sistemi hiyerarşisinin bu cihazda bulunması gerekli değildir. İki argüman içeren bir takma sistemi isteği var: mevcut bir normal dosyanın adı ve ilişkili depolama birimi (örneğin bir disk paketi) kendi dizin hiyerarşisini içeren bağımsız bir dosya sisteminin yapısına sahip olması gereken özel bir dosyanın adı . Bağlamanın etkisi, şimdiye kadarki sıradan dosyalara atıfta bulunmak yerine, çıkarılabilir birimdeki dosya sisteminin kök dizinine başvurmaktır. Aslında, mount tamamen yeni bir alt ağaç (çıkarılabilir birimde depolanan sıradüzen) ile hiyerarşi ağacının yaprağını (sıradan dosya) değiştirir. Bağlama işleminden sonra, çıkarılabilir birimdeki dosyalar ile kalıcı dosya sistemindeki dosyalar arasında hemen hemen hiçbir fark yoktur. Örneğin, kurulumumuzda, kök dizini disk sürücülerimizin birinin küçük bir bölümünde bulunurken, kullanıcının dosyalarını içeren diğer sürücü sistem başlatma sırasına göre monte edilir. Takılabilir bir dosya sistemi, ilgili özel dosyasına yazarak oluşturulur. Boş bir dosya sistemi oluşturmak için bir yardımcı program mevcuttur veya bir tanesi mevcut bir dosyayı kopyalayabilir.

Hiyerarşik dosya sistemi aynı zamanda çoklu depolama cihazlarını yönetme karmaşıklığını çekirdeğe yoğunlaştırma avantajına da sahiptir. Bu, çekirdeğin daha karmaşık olduğu, ancak sonuç olarak tüm uygulamaların daha basit olduğu anlamına geliyordu. Çekirdeğin donanım aygıtlarıyla ilgilenmesi gerektiğinden, ancak çoğu uygulama bunu yapmadığından, bu daha doğal bir tasarımdır.

pencereler

Windows atalarını iki soyadı takip ediyor: aslen VAX minibilgisayar için tasarlanmış bir işletim sistemi olan VMS ve ilk Intel mikrobilgisayarları için tasarlanmış bir işletim sistemi olan CP / M.

VMS dağıtılmış bir hiyerarşik dosya sistemine ( Files-11) sahipti . Files-11'de bir dosyanın tam yolu bir düğüm adı, bu düğümde bir hesap adı, bir cihaz adı, bir dizin ağacı yolu, bir dosya adı, bir dosya türü ve sürüm numarası içerir. VMS, kısayolların belirli dizinlere tanımlanmasına izin veren güçlü bir mantıksal ad özelliğine sahipti , bu nedenle kullanıcıların nadiren bir yöneticinin “gerçek” konumu ile ilgilenmeleri gerekirdi.

CP / M, 64kB RAM ve disket sürücülü bilgisayarlar için tasarlanmıştı, bu yüzden basitlik sağladı. Dizin yoktu, ancak bir dosya başvurusu sürücü göstergesini ( A:veya B:) içerebilir .

MS-DOS 2.0 dizinleri açtığında , kendisini CP / M'yi izleyen MS-DOS1 ile uyumlu bir sözdizimi ile yapardı. Böylece yollar, tek harfli bir adla bir sürücüde köklendi. (Ayrıca, eğik çizgi karakteri /VMS ve CP / M'de komut satırı seçeneklerini başlatmak için kullanıldı, bu nedenle farklı bir karakterin dizin ayırıcı olarak kullanılması gerekiyordu. ).

Windows DOS ve VMS yaklaşımı ile uyumluluğu koruduğu için, daha az alakalı hale geldiklerinde bile sürücü harfleri kavramını korudu. Bugün, başlık altında, Windows UNC yollarını kullanıyor ( başlangıçta Microsoft ve IBM tarafından ilgili soydan gelen OS / 2 için geliştirilmiştir ). Bu, uzman kullanıcılar için ayrılmış olmasına rağmen (muhtemelen tarihin ağırlığından dolayı), Windows yeniden satış noktalarından montaj yapmayı sağlar .

Tek bir dizin ağacına sahip olmanın ardında güvenlik endişesi yoktur.

Unix'i tasarlayanlar, kullanıcıların hangi fiziksel cihazın belirli bir kaynağı içerdiğini bilmelerini gerektiren işletim sistemleriyle ilgili çok fazla deneyime sahipti. Bir işletim sisteminin amacının bir parçası, gerçek donanımın üstüne soyut bir makine oluşturmak olduğundan, kaynakları fiziksel konumlarına göre ele almanın daha kolay olduğunu düşündüler ve her şeyi tek bir ad ağacına koymaya karar verdiler.

Bu, Unix tasarımının arkasındaki dahinin sadece bir kısmı .

Modern Windows'a devam eden MS-DOS sürücü harf adlarının burada kırmızı bir ringa balığı olduğunu unutmayın. Sürücü harfi adları, birden çok kökü olan bir dosya sistemi yapısının en iyi gösterimi değildir. Onlar böyle bir sistemin pipetçi uygulamasıdır.

Birden fazla kökü destekleyen, düzgün bir şekilde uygulanan bir dosya sistemi, birimler için rasgele adlandırmaya izin verir dvdrom:/path/to/file.avi. Mesela, sistem, Windows'u rahatsız eden gülünç kullanıcı arayüzü sorunlarından kurtulurdu. Örneğin, kamera gibi bir cihazı bağlarsanız, Windows Gezgini Kullanıcı Arabirimi, Kamera (veya her neyse) adında bir cihaz olduğuna ve benzeri bir yolun olduğuna inanmanızı sağlar Computer\Camera\DCIM\.... Ancak, bu yolun metin halindeki sürümünü Explorer'dan kesip yapıştırırsanız, işlev adı bileşenlerinin bazıları, temel işletim sistemi tarafından bilinmeyen bir kullanıcı arabirimi kurgusu olduğu için aslında çalışmaz. Çok köklü ve düzgün bir şekilde uygulanmış bir sistemde, iyi olurdu:camera:\DCIM\...sistemdeki her seviyede düzgün bir şekilde tanınan yol. Üstelik, ESKİ bir PC'den eski bir sabit diske aktardıysanız, bunun gibi bir sürücü harfinin adıyla sıkışıp F:kalmazsınız, daha doğrusu istediğiniz gibi adlandırabilirsiniz old-disk:.

Yani, eğer Unix dosya sistemi yapısında birden fazla kök yapmış olsaydı, bu şekilde yapılırdı ve MS-DOS ve Windows'ta tek harfli sürücü isimleriyle değil. Başka bir deyişle, Unix şemasını sadece iyi bir çoklu-kök tasarımla karşılaştıralım.

Öyleyse, Unix neden aklı başında tek köklü bir uygulama lehine mantıklı bir çoklu-kök uygulamasına sahip değil? Muhtemelen sadece basitlik için. Bağlantı noktaları, birimlere adlar aracılığıyla erişebilmenin tüm işlevlerini sağlar. Ek bir önek sözdizimi ile ad alanını genişletmeye gerek yoktur.

Matematiksel olarak konuşursak, herhangi bir ayrık ağaç grafiği ("orman") bir kök düğümü ekleyerek ve ayrık parçaları çocuklarının yapmasıyla birleştirilebilir.

Dahası, hacimlerin kök seviyesinde olması gerekmediği için daha esnektir. Hacmi belirten özel bir sözdizimi olmadığı için (sadece bir yol bileşenidir), montaj noktaları herhangi bir yerde olabilir. Eğer makinenize üç yaşlı disklerde getirirsem, bunları olabilir /old-disk/one, /old-disk/twovb istediğiniz gibi sen diskleri organize edebilir, dosyaları ve dizinleri düzenlemek yol.

Yollara bağlı uygulamalar yazılabilir ve depolama aygıtları yeniden yapılandırıldığında yolların geçerliliği korunabilir. Örneğin, uygulamalar /var/logve gibi iyi bilinen yolları kullanabilir /var/lib. Bu ister size kalmış /var/logve /var/libaynı disk biriminde veya ayrı olanlar vardır. Yolları korurken, sistemi yeni bir depolama topolojisine geçirebilirsiniz.

Bağlantı noktaları iyi bir fikirdir, bu yüzden Windows bunları Windows 2000'den beri sürdürmüştür.

Birim montaj noktaları, aygıtlar bilgisayardan eklendiğinde veya çıkarıldığında meydana gelen sistem değişikliklerine karşı dayanıklıdır. Microsoft Tekniği

Hem * nix hem de Windows sürücülerini monte eder. Windows'ta bunlar otomatik olarak, varsayılan olarak artan alfabetik sıradaki montaj noktalarına monte edilir. Bu varsayılanlar:

• A:ve B:=> disketler
• C: => ilk sabit sürücünün ilk bölümü
• D: => başka bölüm yoksa, sonraki bölüm veya sonraki sabit sürücü veya CD / DVD sürücüsü.

Bu bağlama noktalarının her biri bir dizindir.

* Nix'te montaj noktaları kullanıcı tarafından belirlenir. Örneğin, bir bölümü olarak /diğeri de olarak monte edilmiş durumda /home. Yani, /homeayrı bir sürücüdür, E:Windows'ta söylenenin karşılığı olacaktır .

Her iki durumda da, Windows ve * nix, bağlama noktaları ayrı dizinlerdir. Tek fark * nix, bu ayrı dizinleri alt dizinleri olmasıdır /arasında, C:Windows süre, her puan altında doğrudan monte edilir monte /altında, My Computerdiyelim ki.

Kullanıcı bakış açısına göre asıl avantaj, montaj parçalarının tamamen şeffaf olmasıdır. Dizinin /homeaslında ayrı bir bölümde olduğunu bilmeme gerek yok . Normal bir dizin olarak kullanabilirim. Bunun yerine, DOS'ta açıkça bağlantı noktasının adıyla çağırmam gerekirdi.E:\home

Harici sürücüler her iki sistemde de hemen hemen aynı şekilde monte edilir. D:Windows ve /mnt/cdromLinux için söyle . Bunların her biri bir dizin, aradaki farkı gerçekten göremiyorum. Windows altındaki sürücünüze bir CDROM yerleştirdiğinizde, disk D:tıpkı Linux'daki gibi takılır .

Yukarıdaki cevaplara, özellikle Doug O'Neal'in cevabına katılıyorum, ancak açık cihazın MS-DOS "C:" veya "A:" gibi noktaları belirttiği gibi hepsinin bir şeyleri özlediklerini düşünüyorum.

Rob Pike, The Hideous Name'ı isimlerin sözdizimi hakkında yazdı , ancak Russ Cox kaynattı :

Ad boşlukları ... en yeni, yeni sözdizimi eklenmeden yeni anlambilim eklenebilir.

Aygıtların isteğe bağlı olarak monte edilebildiği tek bir ad alanı, gerçekten esnek işlemlere izin verir. Halen kullanılmayan bir diski veya CD'yi genel dosya sistemine geçici olarak yerleştirmek /mnt/sdb1ve kullanmak /mnt/cdromiçin düzenli olarak kullanıyorum . NFS sunucusunda ev dizinleri olması nadir değildir, bu nedenle hangi makineye giriş yaparsanız yapın, $HOMEher yerde aynı olur .

Bu, aşağıya doğru geliyor: özel şeyler için özel bir sözdizimine sahip olmak, yapabileceklerinize kesin sınırlamalar koyar. Kullanılmayan bir diski veya CD'yi veya DVD'yi veya "E:" veya "W:" üzerindeki bir ağ dosya sistemini / "paylaşımını" takabilirseniz ya da her neyse, çok daha az esnekliğe sahipsiniz.

Bu aptalca. Windows ayrıca tek bir hiyerarşi noktasına sahiptir. Ancak gizli ve standart değildir. Çoğu şeyin pencereleri gibi.

Bu durumda, "Bilgisayarım" kavramıdır. Unix'deki kök (/) 'in karşılığıdır. Kökün çekirdekte var olan bir kavram olduğunu unutmayın. beğendin ya da sevmedin. Tıpkı pencerelerin "Bilgisayarım" ı kullandığı gibi. Tabii ki, unix içindeki kök üzerine bir bölüm ekleyebilirsiniz ve çoğu insan böyle yapar. Ve pek çok şey şeyler için belirli bir yola bakacaktır (örn. / Etc /), ancak onunla sınırlı değilsiniz. Elbette, sürücülerinizi / C: / içine monte edin. unix de yapman yasak.

C: \, pencerelerde bir kök değildir, bir bölümün birleşme noktasıdır. Hangi "Bilgisayarım" üst düzeyde olmalı. Unix'deyken herhangi bir ağacın altına bir bölüm ekleyebilirsiniz. Bu yüzden linux, C: ' /nin D: monteli /mnt/d/olmasına rağmen monte edilmiş olabilir ... hatta monteli /ancak zor bir iştir ve önceden monte edilmiş bir yolun üzerine monte ederken iki dosya sisteminin nasıl davrandığına bağlıdır.

Böylece pencerelerinizde olduğu gibi aynısını elde edebilirsiniz; pencereleri rastgele dayatılan aynı sınırlamaları takip etmeye zorlarsınız.

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

O zaman önyükleme seçeneklerinde mount seçeneklerine geçmek zorundasınız. Çünkü / etc / ... 'a sahip olmayacaksınız, fakat bu aynı zamanda pencerelerin dayattığı sınırlamaları simüle ediyor.

Windows sürücü harfleri nedeni muhtemelen muhtemelen Microsoft ve DOS daha ileri gider. Çıkarılabilir sürücülere mektup atama IBM sistemlerinde yaygındı, bu nedenle Microsoft CP / M'yi kopyalayarak IBM'in talimatlarını yerine getirmiş olabilir. Ve başlangıçta, DOS zaten dizinleri yoktu.

MS-DOS, bir veya iki çıkarılabilir diski olan ve sabit ortamı olmayan bilgisayarlarda çalıştığında, dizinleri olan bir dosya sistemine gerçekten ihtiyacınız yoktu. Bir, belki iki, 180 kilobayt diskle, onları organize etmekte zorlanacak kadar hiçbir zaman dosyalarınız olmadı.

https://en.wikipedia.org/wiki/Drive_letter_assignment

Aslında, Linux Unix'e dayanır (ya da Unix'tir, tartışmaya bakınız ) ve Unix, çoklu cihaz kullanımının oldukça açık olduğu ana bilgisayar ortamından gelir. Cihazları tek bir dizin ağacına monte etmek size maksimum esneklik sağlar ve işletim sisteminin erişebileceği cihaz sayısını sınırlamaz.

Diğer yandan, sürücüler için DOS harfleri 1 veya 2 disket istasyonu ve tek disk sürücüsü olan bir PC için iyi bir tasarımdır. Büyük disket 5,25 'her zaman A :, küçük bir 3,5' her zaman B: ve disk sürücüsü her zaman C: 'dir. Bir dosyayı diskete veya diske bir yere kopyalayıp kopyalamayacağınızı her zaman bilirsiniz. Fiziksel olarak 2 disket sürücüyü ve 2 (veya 4) sabit diski bağlayamazsanız esnekliğe ihtiyacınız yoktur.

DOS tasarımı daha son kullanıcı dostuyken Unix tasarımı yönetici dostu idi. Artık sürücü harfleri Windows için bir yük, kullanıcılar mektubunu bilmek yerine çıkarılabilir sürücü içeriğine sahip gezgin penceresini otomatik olarak açmaya güveniyorlar ... Ubuntu aslında aynı şeyi yapıyor.

Bu doğru değil aslında. Windows başka bir yol şeması kullanıyor (peki, aynı değil)

"Birim Mektuplar" sadece yolları, diskleri ve bölümleri kolayca hatırlayabileceğiniz bir şeydir.

ARC yolları Windows'ta bir dosyanın yolunu tanımlar (ancak bunlar yalnızca önyüklemede kullanıcıya görünür):

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

Windows NT’de diskler, bölümler ve birim harfleri arasında bir ilişki yoktur: Bir birimin tamamını bir klasöre "koyabilirsiniz" (örneğin: c: \ myseconddisk tüm bir fiziksel disk olabilir!)

İşaret etmek istediğim iki şey -

1. Linux'taki sabit diskler aslında / dev / sdb1 gibi harf / ad verilmiş bir şekildedir. Ancak tek / kök yapısından ulaşılabilecek her yere monte edilebilirler
2. İnsanların (kendim de dahil) Windows’ta ayrı sürücülere sahip olmalarının en yaygın nedeni, Windows’un kaçınılmaz biçimde yeniden yüklenmesi veya değiştirilmesi gerektiğinde, yükseltme veya virüs olması gerektiğinden, belge, müzik, program vb. dosya sistemi arızası, bu dosyalara hala erişim vardı. Linux'ta bu sorunu yaşamadım - dosya sistemi çok daha güvenilir, işletim sistemi benim tarafımdan doğrudan bir işlem veya hata yapmadıkça (ooh! Kanama kenarı repo, deneyelim!) FAR daha basittir. Ve, nadir bir durumda, tüm yazılımlar eklediğim repolar veya ppa'lar aracılığıyla mevcut olduğundan (ve home dir dizinimi canlı bir diskle kolayca kopyalayabildiğim için) yeniden yüklemem gerekti,

Geçmişe bakarsanız, Unix’in ses için 8 bantlı bant sistemi ve 9 bantlı IBM veri sistemleri (9 bant / veri için 8 bant, parite için bir tane) sırasında başladığını görebilirsiniz. Teknik olarak hemen hemen aynı.

O zaman, dosyaların konumu hakkındaki bilgiler, bant üzerindeki bilgilerin bölümlerinde saklanır ve banttan veri okurken ileriye ve geriye doğru tanımlanır (bir dosya gibi, başlangıç ​​ve bitiş imzası olan); Ayrıca sürücünün başlangıcında neden sadece bir tane FAT olmadığınızı da açıklıyor; aramayı hızlandırmak için birden fazla kişi bulunduğunu açıklıyor. Ve eğer birden fazla sürücünüz varsa, bunlar / dev'in içine bağlı ve dosyaların arasında, cihazlar arasında taşıdığınız dosyanın adresi.

Daha erken başladığını ve MS Dos alanının (CP / M) ve daha sonraki Windows NT’nin arkasındaki kararın yalnızca bakıldığı sırada tek bir giriş noktası yerine VM ana bilgisayar sürücü harfleriyle ilgili olduğunu düşündüğünüze inanıyorum. daha modern, günümüzün veri miktarları mevcut değildi ve sonunda yeterli sürücü harfine sahip olamayacağınızı ya da fazla dağınık olacağını düşünmediler.

9-Track-Drive ve Drive Letter ataması