Kısım I · Makine · Bölüm 16

Dosyalar ve Dosya Sistemleri

Elektrik kesilince geriye ne kalır (Files and file systems)

1. Kat 8–10Ağ, tarayıcı, bizim uygulamaDosyaları okur: HTML, CSS, JS, kullanıcı verileri.
2. Kat 7İşletim sistemiBu bölüm: üçüncü iş, kalıcılık. Bölüm 13–18.
3. Kat 3İşlemci ve bellekRAM uçucudur; kalıcı depolama onun altında durur (Bölüm 8.3).
4. Kat 0–2Bit, kapılar, devrelerDosyanın içi de sonunda bitlerdir (Bölüm 2).

Bu bölümün sonunda şunları bileceksin: bir dosyanın ve klasörün ne olduğunu, yol yazmanın iki biçimini (HTML'deki href="style.css" bunlardan birini kullanır), dosya sisteminin diskin üstüne nasıl bir düzen kurduğunu (APFS, ext4, NTFS'in ortak fikri), izinlerin ne işe yaradığını, metin ve ikili dosyanın farkını ve neden bir veritabanının "sadece bir dosya" olmadığını.

16.1 Dosya, dizin (klasör), yol: mutlak ve göreli

Bir disk, Bölüm 8'de gördüğün gibi, bloklara bölünmüş büyük bir bayt dizisidir. Hiçbir yerde "tez.docx" ya da "index.html" yazmaz; yalnızca baytlar vardır. İşletim sistemi bu baytların üzerine insanın anlayacağı bir düzen kurar. OSTEP, kalıcı depolama için iki temel soyutlama sayar: dosya ve dizin.¹

Dosya (file), adı olan, okunup yazılabilen bir bayt dizisidir. OSTEP'e göre dosya sistemi, dosyanın ne olduğu (resim, metin, C kodu) hakkında çoğu zaman bir şey bilmez; yalnızca baytları kalıcı olarak saklar ve sen geri istediğinde aynen verir.¹ İçindekinin ne olduğuna program karar verir: Bölüm 2'deki "anlam bağlamdadır" ilkesinin dosya hali. Her dosyanın ayrıca kullanıcının görmediği bir alt adı vardır: düşük seviyeli sayı adı, tarihsel nedenlerle inode numarası denir (16.2'de).

Dizin (directory), ya da günlük adıyla klasör (folder), başka dosyaları ve dizinleri içeren bir kaptır. Dizinler iç içe geçince bir ağaç kurulur. Ağacın en üstündeki dizin kök dizin (root directory) denir ve macOS ve Linux'ta tek bir eğik çizgiyle yazılır: /. Windows'ta kök, sürücü harfiyle başlar (C:\) ve ayırıcı ters eğik çizgidir (\). Bu kitapta Unix ailesinin yazımını kullanacağız; web de (URL'ler, Bölüm 20) aynı eğik çizgiyi kullanır.

Yol

Yol (path), bir dosyaya ağaçta nasıl gidileceğini adım adım söyleyen yazıdır: /Users/kerem/hukuk-app/index.html. İki yazım biçimi vardır:

• Mutlak yol (absolute path): Kökten başlar (/ ile). Nerede durduğundan bağımsız, her zaman aynı dosyayı gösterir. Posta adresindeki "Türkiye, İstanbul, … mahallesi, … sokak, no 5" gibidir.
• Göreli yol (relative path): Bulunduğun yerden başlar. style.css "şu anki dizindeki style.css", js/app.js "şu anki dizindeki js klasörünün içindeki app.js" demektir. "Karşı apartmanın ikinci kat" gibidir: nerede durduğuna göre anlam kazanır. .. bir üst dizin, . bulunduğun dizindir. Her dizinde bu ikisi hazır girdiler olarak bulunur.¹

Bir örnek kuralım. Kerem'in prototipinin klasörünü şöyle hayal edelim (kendi bilgisayarımızda aynı yapıyı oluşturup komutlarla denedik; Bölüm 18'de komutları öğreneceksin). Prototipinde muhtemelen buna benzer bir düzen vardır:

hukuk-app/
├── index.html
├── style.css
└── js/
    └── app.js

Şimdi index.html'in içindeki şu satırlara bak:

<link rel="stylesheet" href="style.css">
<script src="js/app.js"></script>

Her ikisi de göreli yoldur. Tarayıcı, index.html'i hangi dizinde bulduysa oradan başlayarak style.css ve js/app.js'i arar. Bu yüzden hukuk-app klasörünü başka bir yere taşıyabilirsin, hâlâ çalışır: içerdeki yollar klasörün içine göredir, dışındaki yere değil. Mutlak yolla yazsaydın (href="/Users/kerem/hukuk-app/style.css") site yalnızca senin bilgisayarında çalışır, kardeşinin bilgisayarında bozulurdu. Web'de aynı fikir URL'lere genişler (Bölüm 20.2): tarayıcı göreli bir yolu, sayfanın adresine göre tamamlar.

16.2 Dosya sistemi: APFS, ext4, NTFS

Elinde yalnızca "bayt dizisi olan bir disk" ve "dosya adı" var. İkisini birbirine bağlayan düzen dosya sistemidir (file system): bir diskin üzerine kurulmuş, dosyaların, dizinlerin ve onların disk üzerindeki yerinin kayıtlarını tutan bir veri düzeni, ve onu okuyup yazan işletim sistemi kodu. Dosya sistemi, bir soyutlamadır (Bölüm 1.4): üst taraf "dosya" ve "klasör" görür, alt taraf blokları.

İçine bakalım: OSTEP'in küçük dosya sistemi

OSTEP, vsfs (very simple file system) adında oyuncak bir dosya sistemini sıfırdan kurar.² Gerçek sistemlerin hepsi bu fikrin gelişmişidir; o yüzden küçüğü anlamak yeter. Disk, eşit boyutlu bloklara (blocks) bölünür (örnekte 4 KB). Blokların bir kısmı veri içindir. Dosyayı bulmak için de kayıt tutulması gerekir; bu kayıtlar şunlardır:

• İnode (inode, "index node"): Bir dosyanın üst verisini (metadata) tutan kayıt: boyu, izinleri, hangi blokların onun olduğu. Dosyanın adı inode'da yoktur. İnode'lar diskte bir "inode tablosu" içinde ardışık durur ve numara ile aranır.² Bir inode genelde 128 ya da 256 bayttır; OSTEP örneğinde 256 bayt alınır, yani 4 KB'lık bir blok 16 inode taşır.²
• Veri blokları: Dosyanın asıl içeriği.
• Bitmap'ler: Hangi inode'un ve hangi veri bloğunun boş olduğunu tutan bit dizileri (0 boş, 1 dolu). Yeni dosya açılırken boş yer buradan bulunur.²
• Süper blok (superblock): O dosya sisteminin kendisini anlatan kayıt: kaç inode, kaç veri bloğu var, inode tablosu nerede başlıyor, bir de dosya sisteminin türünü belirten bir "sihirli sayı".²

OSTEP'in 64 bloklu minik diskinde bu düzen şöyledir: 1 süper blok, 1 inode bitmap'i, 1 veri bitmap'i, 5 blokluk inode tablosu (5 × 16 = 80 inode) ve geri kalan 56 veri bloğu: 1 + 1 + 1 + 5 + 56 = 64.² Bu hesaba göre bu disk en çok 80 dosya tutabilir. Daha büyük disk, daha büyük inode tablosu ister.

Bir inode numarasından inode'u bulmak basit bir hesaptır. Örneğin 32 numaralı inode için: 32 × 256 bayt = 8192 bayt; inode tablosu diskte 12 KB'ta başlıyorsa, 12 KB + 8 KB = 20 KB'taki bloğa gidilir.² Yani "ad → numara → bayt konumu" bir zincirdir; aranan şey adresi hesaplanabilen bir tablodaki satırdır.

Bir dosya büyükse blokları nerede?

İnode'un içindeki işaretçilerin sayısı sınırlıdır. OSTEP iki fikri anlatır: doğrudan işaretçiler (direct pointers) doğrudan bir veri bloğunu gösterir; dosya büyüyünce bir dolaylı işaretçi (indirect pointer), veri değil, başka işaretçiler dolu bir bloğu gösterir. Küçük dosya ucuz kalır, büyük dosya yine de saklanabilir.² Ayrıntısı bizim kapsamımızın dışında; bilmen gereken, "dosyanın blokları nerede?" sorusunun inode içindeki işaretçilerle cevaplandığıdır.

Dizin de bir dosyadır

Dosya adı nerede tutulur? Dizinde. Bir dizin, içeriği (ad, inode numarası) çiftlerinden oluşan özel bir dosyadır.³ Bir dosyayı yolla aradığında işletim sistemi, kök dizinin inode'undan başlar (kökün inode numarası bilinir), içinde "hukuk-app" adını arar, onun inode numarasını bulur, o dizini okur, "index.html"i arar, ve nihayet dosyanın inode'una ulaşır. Her adım bir dizin okumaktır. İnode ayrı, ad ayrı olduğu için aynı dosyaya birden çok ad verilebilir: bu duruma sabit bağ (hard link) denir; aynı inode'u gösteren iki dizin girdisidir. Dosya yalnızca bu adlardan hepsi silinince gerçekten silinir.³

Takılıp bağlanmak: mkfs ve mount

Bilgisayarında bir USB bellek takınca dosyaları aynı klasör ağacında belirir. OSTEP bunu şöyle anlatır: önce mkfs ("make file system") aracıyla bir diske boş bir dosya sistemi yazılır (kök dizin dahil); sonra mount aracı bu dosya sistemini mevcut ağaçtaki bir dizine "bağlar".³ Böylece birçok ayrı dosya sistemi tek bir ağaçta toplanır. Windows aynı iş için sürücü harfi (D:) verir; macOS ve Linux ise ağacın içine takar (örneğin /Volumes/USB).

APFS, ext4, NTFS

Dosya sistemi türlerinin üçü senin karşılaşacağın isimlerdir; her biri yukarıdaki fikrin kendi gerçeklemesidir.

Her işletim sistemi kendi dosya sistemini kullanır; bir USB bellek formatlıyken bunu seçersin. Bir Mac'te formatlı disk, çoğu zaman Windows'ta doğrudan okunamaz: her sistemin bayt düzeni farklıdır. Bu yüzden iki sistem arasında taşınan harici disklerde ortak bir biçim kullanılır. Bunun ayrıntısı bu kitabın konusu değil; "neden okunmuyor" sorusunun cevabı, işletim sisteminin diskteki düzeni tanımamasıdır.

Elektrik kesilirse? Tamponlar ve günlükleme

Dosya sistemi performans için yazıları hemen diske göndermez; OSTEP'e göre bir write() çağrısı "bu veriyi bir ara kalıcı depoya yaz" demektir ve dosya sistemi yazıyı bir süre (örneğin 5 ya da 30 saniye) bellekte tutar.³ Yani programın "yazdım" dediği bayt, henüz diskte olmayabilir; bu sırada elektrik giderse yazı kaybolur. Bir uygulamanın verinin diske ulaştığını garanti etmesi gerekiyorsa fsync() çağrısı yapar: dosya sistemi o dosyanın bekleyen tüm yazılarını diske zorlar ve iş bittiğinde döner.³ Bu tampon fikri, Bölüm 8.2'deki önbellek fikrinin yazma tarafıdır: hız için yakın bir yerde tutulur, bedeli kayıp riskidir.

Bir yazı çok adımlı olduğunda (inode, bitmap ve veri bloğu güncellenir) araya giren bir elektrik kesintisi dosya sistemini tutarsız bırakabilir. Modern dosya sistemleri bunu önlemek için önce yapılacak işi bir günlüğe yazar (journaling, OSTEP'in kendi bölümü vardır⁷). Aynı fikre Bölüm 38'de, veritabanlarında tekrar rastlayacağız.

16.3 Dosya izinleri ve sahiplik

Birden çok kullanıcılı bir bilgisayarda, ya da tek kullanıcılı bir bilgisayarda çalışan ve kullanıcı adına davranan onlarca programda şu soru kaçınılmaz: Bu dosyayı kim okuyabilir, kim değiştirebilir? Cevap, Bölüm 13'teki yetki ve yalıtım fikrinin dosya düzeyindeki karşılığıdır.

Unix ailesinde (Bölüm 18) her dosyanın bir sahibi (owner) ve bir grubu (group) vardır. İzinler üç kişiye ayrı verilir: sahip, grup ve diğer herkes. Her biri için üç hak vardır: okuma r (read), yazma w (write), çalıştırma x (execute). Bir dosyanın ls -l çıktısı şöyle görünür (kendi denememizden, kullanıcı adı değiştirilerek):

-rw-rw-r-- 1 kerem kerem  186 Nov 13 16:03 index.html
drwxrwxr-x 2 kerem kerem 4096 Nov 13 16:03 js
-rw------- 1 kerem kerem   34 Nov 13 16:03 style.css

İlk sütun on karakterdir. İlk karakter türü söyler: - sıradan dosya, d dizin. Sonraki dokuz karakter üçer üçer: sahip hakları, grup hakları, diğerleri. index.html için rw- (sahip: okur ve yazar), rw- (grup: okur ve yazar), r-- (diğerleri: yalnızca okur). Üçüncü satır, style.css dosyasına chmod 600 uyguladıktan sonraki hali: rw-------, yalnızca sahip okur ve yazar. Dosyanın boyutu 186 ve 34 bayttır; ikinci satırdaki 4096 ise dizinin kendi kaydıdır.

Hakları ikilik sayıyla (Bölüm 2) kısaltmak da mümkün: okuma 4, yazma 2, çalıştırma 1. rw- = 4 + 2 = 6, r-- = 4. Üç kişiye ait üç rakam yan yana yazılınca 644 (sahip rw-, grup r--, diğerleri r--) ve 600 (rw-, ---, ---) çıkar. chmod 600 style.css komutu bu sayıyı dosyaya uygular. Dizinde x hakkı "içine girebilir" anlamındadır, r "içindekileri listeleyebilir".

İzinler üç yerde karşına çıkacak: sunucuda bir sertifika ya da gizli anahtar dosyasını sadece sahibinin okuyabilmesi gerektiğinde (600); bir betiği çalıştırılabilir yapmak için x eklemek gerektiğinde (Bölüm 18); ve "Permission denied" hatasında. Bu hata, dosyanın bozuk olduğu anlamına gelmez; işletim sistemi, senin kimliğinle yaptığın erişime izin vermemiştir. Windows'ta aynı fikir farklı biçimde işler (NTFS'te erişim denetim listeleri) ama soru aynıdır: kim, hangi dosyaya, ne yapabilir?

16.4 Metin dosyası ve ikili dosya; uzantılar

Bölüm 2'de bitlerin anlamının, onları okuyan kuralda olduğunu gördün. Dosyalarda bu kural iki geniş sınıfa ayrılır.

Metin dosyası (text file), baytların bir karakter kodlamasıyla (genellikle UTF-8) okunabilen dosyadır. HTML, CSS, JavaScript, JSON, Markdown, hepsi metin dosyasıdır: bir metin düzenleyicide açarsan okunur harfler görürsün. Örneğin içinde yalnızca "Hukuk" yazan bir dosya, 5 byte'tır: 48 75 6b 75 6b (onaltılık). "Türkçe" kelimesi ise altı karakter olduğu halde sekiz byte tutar, çünkü ü ve ç UTF-8'de ikişer byte'tır: 54 c3 bc 72 6b c3 a7 65 (hesabı terminalde doğruladık). Metin dosyasının faydası, insanın doğrudan okuyup değiştirebilmesidir; bu yüzden kod hep metin dosyalarında yazılır.

İkili dosya (binary file) ise baytların bir metin kodlamasıyla değil, kendine özgü bir dosya biçimiyle (Bölüm 2.7) düzenlendiği dosyadır: resim, ses, PDF, derlenmiş program, SQLite veritabanı. Bir metin düzenleyiciyle açarsan çoğunlukla bozuk karakterler görürsün; bozuk değildir, yanlış kuralla okunmaktadır. İkili dosyalar çoğu zaman başlıkla kendini tanıtır: gerçek bir PNG dosyasının ilk sekiz byte'ına baktığımızda 89 50 4e 47 0d 0a 1a 0a gördük; 50 4e 47 ASCII'de "PNG" harfleridir. Bu başlık, programa "ben bir PNG'yim" der. Hangi dosya türü olduğuna işletim sistemi değil, çoğunlukla dosyayı açan program karar verir.

Uzantı

Uzantı (extension), dosya adının sonundaki noktadan sonrasıdır: .html, .png, .pdf. Uzantı, dosyanın içeriğine dair bir ipucudur, garantisi değildir. Bir dosyanın adını foto.png'den foto.txt'ye değiştirmek içindeki baytları değiştirmez; yalnızca işletim sisteminin hangi programı açacağını seçmesini etkiler. Bölüm 1'deki önizlemede "işletim sistemi uzantıya bakar ve hangi programın açacağına karar verir" demiştik: bu o. Çift tıkladığında .html uzantılı dosya tarayıcıda açılır, çünkü işletim sistemi uzantıyı bir programla eşleyen bir tablo tutar.

16.5 Veritabanı neden "sadece bir dosya" değildir

Şu soru doğal: kullanıcıların puanlarını bir JSON dosyasına yazsak, her kullanıcı için bir dosya açsak olmaz mı? Küçük bir prototip için olur. Ama gerçek bir uygulamada şu sorunlar çıkar, her biri bu bölümde öğrendiklerinin bir sonucudur:

• Aynı anda yazma. İki kullanıcı aynı anda aynı dosyaya yazarsa ne olur? Bölüm 14'teki yarış durumu: sonuç iki yazıdan birini ezer. Dosya sistemi yazıların sırasını sizin istediğiniz biçimde garanti etmez.
• Elektrik kesintisi ve yarım yazılmış dosya. Yukarıda gördük: yazma birden çok adımdır ve tamponludur. "Puanı 10 artır, serinin tarihini güncelle" iki ayrı yazıysa, aralarında bir kesinti yarım bir durum bırakır. Veritabanı bunu işlem (transaction) ile çözer: ya ikisi de olur, ya hiçbiri.
• Aramak. "Bu hafta en çok puan toplayan 10 kullanıcı" sorusu, milyon dosyayı tek tek açmak demektir. Veritabanı veriyi, böyle sorgulara hızlı cevap verecek biçimde (indekslerle) düzenler.
• İzinler ve ilişkiler. Bir dosya, "kimin ne yapabileceği"ni yalnızca dosya düzeyinde söyler; "kullanıcı yalnızca kendi cevaplarını görsün" gibi kurallar veri düzeyindedir.

Veritabanı yazılımı (örneğin PostgreSQL) sonunda yine dosya sistemine yazar; ama bu çiftleşme yukarıdaki sorunları çözmek için bir kat ekler. PostgreSQL belgeleri, write-ahead logging (yazmadan önce günlükleme) fikrini şöyle anlatır: veri dosyalarındaki değişiklikler yalnızca o değişiklikler günlüğe yazıldıktan sonra yapılır.⁸ Bu, dosya sisteminin günlükleme fikrinin veritabanındaki halidir. Ayrıntısı Bölüm 38'de; burada bilmen gereken, veritabanının "dosya sisteminin üstünde, onun eksiklerini kapatan bir kat" olduğudur.

Bu bölümde neler kuruldu

İşletim sisteminin üçüncü işi kalıcılıktır. Ham diski, adlı dosyalara ve iç içe dizinlere çeviren düzene dosya sistemi denir; bir dosyaya yolla ulaşılır, yol mutlak (kökten) ya da göreli (bulunduğun yerden) yazılır; HTML'deki href="style.css" göreli bir yoldur. Dosya sisteminin içinde inode (dosyanın üst verisi ve blok işaretçileri), bitmap'ler, süper blok ve (ad, inode numarası) çiftlerinden oluşan dizinler bulunur. APFS (Apple), ext4 (Linux) ve NTFS (Windows) aynı fikrin farklı gerçeklemeleridir. İzinler sahip, grup ve diğerleri için okuma, yazma, çalıştırma haklarıdır. Dosyalar metin ya da ikili olur; uzantı yalnızca ipucudur. Veritabanı, dosya sisteminin eşzamanlı yazma, kesinti, arama ve veri düzeyi izin eksiklerini kapatan bir kattır.

Terimler sözlükte, Bölüm 16 başlığı altında.

Kaynaklar

1. Remzi H. Arpaci-Dusseau ve Andrea C. Arpaci-Dusseau, Operating Systems: Three Easy Pieces, bölüm 39, Interlude: Files and Directories: dosya, dizin, dizin ağacı, mutlak ve göreli yol, . ve .., dosya sisteminin içeriği bilmemesi.
2. OSTEP, bölüm 40, File System Implementation: vsfs, inode, bitmap, süper blok, 64 bloklu örnek (80 inode, 56 veri bloğu), inode konumu hesabı (32 numaralı inode → 20 KB), doğrudan ve dolaylı işaretçiler.
3. OSTEP, bölüm 39 (aynı bölüm): dizin girdileri, sabit bağ, mkfs ve mount, yazma tamponlaması (5 ya da 30 saniye) ve fsync(). Dizin içeriğinin (ad, inode numarası) çiftleri olduğu ayrıntısı bölüm 40'ta da geçer.
4. Wikipedia, Apple File System: iOS 10.3 (27 Mart 2017) ve macOS 10.13 (25 Eylül 2017) ile tanıtılması; HFS Plus'ın yerini alması.
5. Wikipedia, ext4: Debian ve Ubuntu dahil birçok Linux dağıtımının varsayılan dosya sistemi olması. Ayrıca Linux çekirdeği belgeleri, ext4 General Information.
6. Wikipedia, NTFS: 27 Temmuz 1993, Windows NT 3.1 ile tanıtılması. Ayrıca Microsoft Learn, NTFS overview.
7. OSTEP, bölüm 42, Crash Consistency: FSCK and Journaling: günlükleme fikri.
8. PostgreSQL belgeleri, Write-Ahead Logging: Reliability and the Write-Ahead Log (WAL): değişikliklerin veri dosyalarına yazılmadan önce günlüğe yazılması.