Mayoritas distribusi Linux modern menggunakan sistem file ext4, sama seperti distribusi Linux sebelumnya yang menggunakan default ext3, ext2, dan—jika Anda mundur cukup jauh—ext.
Jika Anda baru mengenal Linux—atau sistem file—Anda mungkin bertanya-tanya apa yang dibawa ext4 ke tabel yang tidak dimiliki ext3. Anda mungkin juga bertanya-tanya apakah ext4 masih dalam pengembangan aktif, mengingat banyaknya liputan berita sistem file alternatif seperti btrfs, xfs, dan zfs.
Lebih banyak sumber daya Linux
- Lembar contekan perintah Linux
- Lembar contekan perintah Linux tingkat lanjut
- Kursus online gratis:Ikhtisar Teknis RHEL
- Lembar contekan jaringan Linux
- Lembar contekan SELinux
- Lembar contekan perintah umum Linux
- Apa itu container Linux?
- Artikel Linux terbaru kami
Kami tidak dapat membahas semua tentang sistem file dalam satu artikel, tetapi kami akan mencoba memberi Anda informasi terbaru tentang sejarah sistem file default Linux, di mana posisinya, dan apa yang diharapkan.
Saya banyak memanfaatkan berbagai artikel sistem file ext Wikipedia, entri wiki kernel.org di ext4, dan pengalaman saya sendiri saat mempersiapkan ikhtisar ini.
Sejarah singkat dari ext
sistem file MINIX
Sebelum ada ext, ada filesystem MINIX. Jika Anda tidak mengetahui sejarah Linux Anda, MINIX adalah sistem operasi mirip Unix yang sangat kecil untuk komputer mikro IBM PC/AT. Andrew Tannenbaum mengembangkannya untuk tujuan pengajaran dan merilis kode sumbernya (dalam bentuk cetak!) pada tahun 1987.
Meskipun Anda dapat membaca dengan teliti sumber MINIX, itu sebenarnya bukan perangkat lunak bebas dan sumber terbuka (FOSS). Penerbit buku Tannebaum membutuhkan biaya lisensi $69 untuk mengoperasikan MINIX, yang sudah termasuk dalam biaya buku. Namun, ini sangat murah untuk saat itu, dan adopsi MINIX berkembang pesat, segera melebihi niat awal Tannenbaum menggunakannya hanya untuk mengajarkan pengkodean sistem operasi. Sepanjang tahun 1990-an, Anda dapat menemukan instalasi MINIX berkembang pesat di universitas-universitas di seluruh dunia—dan Linus Torvalds muda menggunakan MINIX untuk mengembangkan kernel Linux asli, pertama kali diumumkan pada tahun 1991, dan dirilis di bawah GPL pada bulan Desember 1992.
Tapi tunggu, ini adalah sistem file artikel, kan? Ya, dan MINIX memiliki sistem file sendiri, yang juga diandalkan oleh versi awal Linux. Seperti MINIX, itu dapat digambarkan sebagai contoh "mainan" dari jenisnya—sistem file MINIX hanya dapat menangani nama file hingga 14 karakter dan hanya menangani penyimpanan 64MB. Pada tahun 1991, hard drive biasa sudah berukuran 40-140MB. Linux jelas membutuhkan sistem file yang lebih baik!
ekst
Sementara Linus meretas kernel Linux yang masih baru, Rémy Card bekerja pada sistem file ext pertama. Pertama kali diimplementasikan pada tahun 1992—hanya setahun setelah pengumuman awal Linux itu sendiri!—ext memecahkan masalah sistem file MINIX yang terburuk.
Ext tahun 1992 menggunakan lapisan abstraksi sistem file virtual (VFS) baru di kernel Linux. Tidak seperti sistem file MINIX sebelumnya, ext dapat menangani penyimpanan hingga 2 GB dan menangani nama file 255 karakter.
Tetapi ext tidak memiliki kekuasaan yang lama, sebagian besar karena timestamping primitifnya (hanya satu cap waktu per file, daripada tiga cap terpisah untuk pembuatan inode, akses file, dan modifikasi file yang kita kenal sekarang). Setahun kemudian, ext2 memakan makan siangnya.
ext2
Rémy jelas menyadari keterbatasan ext cukup cepat, karena ia merancang ext2 sebagai penggantinya setahun kemudian. Sementara ext masih berakar pada sistem operasi "mainan", ext2 dirancang dari awal sebagai sistem file kelas komersial, dengan prinsip yang sama seperti Sistem File Cepat Berkeley BSD.
Ext2 menawarkan ukuran file maksimum dalam gigabyte dan ukuran sistem file dalam terabyte, menempatkannya dengan kuat di liga besar untuk tahun 1990-an. Itu diadopsi dengan cepat dan luas, baik di kernel Linux dan akhirnya di MINIX, serta oleh modul pihak ketiga yang membuatnya tersedia untuk MacOS dan Windows.
Masih ada masalah yang harus dipecahkan:sistem file ext2, seperti kebanyakan sistem file tahun 1990-an, rentan terhadap kerusakan besar jika sistem mogok atau kehilangan daya saat data sedang ditulis ke disk. Mereka juga mengalami kerugian kinerja yang signifikan karena fragmentasi (penyimpanan satu file di banyak tempat, secara fisik tersebar di sekitar disk yang berputar) seiring berjalannya waktu.
Terlepas dari masalah ini, ext2 masih digunakan dalam beberapa kasus yang terisolasi saat ini—paling umum, sebagai format untuk USB thumb drive portabel.
ext3
Pada tahun 1998, enam tahun setelah adopsi ext2, Stephen Tweedie mengumumkan bahwa dia sedang bekerja untuk meningkatkannya secara signifikan. Ini menjadi ext3, yang diadopsi ke Linux arus utama dengan kernel versi 2.4.15, pada November 2001.
Ext2 telah dilakukan dengan sangat baik oleh distribusi Linux untuk sebagian besar, tetapi — seperti FAT, FAT32, HFS, dan sistem file lain pada waktu itu — rentan terhadap kerusakan besar selama kehilangan daya. Jika Anda kehilangan daya saat menulis data ke sistem file, itu dapat dibiarkan dalam apa yang disebut tidak konsisten negara bagian di mana hal-hal telah dibiarkan setengah selesai dan setengah dibatalkan. Hal ini dapat mengakibatkan hilangnya atau rusaknya sejumlah besar file yang tidak terkait dengan file yang disimpan atau bahkan tidak dapat dipasangnya seluruh sistem file.
Ext3, dan sistem file lain pada akhir 1990-an, seperti NTFS Microsoft, menggunakan jurnal untuk memecahkan masalah ini. Jurnal adalah alokasi khusus pada disk tempat penulisan disimpan dalam transaksi; jika transaksi selesai menulis ke disk, datanya di jurnal dikomit ke sistem file itu sendiri. Jika sistem crash sebelum operasi itu dilakukan, sistem yang baru di-boot ulang mengenalinya sebagai transaksi yang tidak lengkap dan memutarnya kembali seolah-olah itu tidak pernah terjadi. Ini berarti bahwa file yang sedang dikerjakan mungkin masih hilang, tetapi sistem file itu sendiri tetap konsisten, dan semua data lainnya aman. Tiga tingkat penjurnalan tersedia dalam implementasi kernel Linux dari ext3:jurnal , dipesan , dan tulis balik .
- Jurnal adalah mode risiko terendah, menulis data dan metadata ke jurnal sebelum memasukkannya ke sistem file. Ini memastikan konsistensi file yang sedang ditulis, serta sistem file secara keseluruhan, tetapi dapat menurunkan kinerja secara signifikan.
- Dipesan adalah mode default di sebagian besar distribusi Linux; mode terurut menulis metadata ke jurnal tetapi melakukan data langsung ke sistem file. Sesuai dengan namanya, pesanan operasi di sini kaku:Pertama, metadata berkomitmen untuk jurnal; kedua, data ditulis ke sistem file, dan baru kemudian metadata terkait dalam jurnal dipindahkan ke sistem file itu sendiri. Ini memastikan bahwa, jika terjadi crash, metadata yang terkait dengan penulisan yang tidak lengkap masih ada di jurnal, dan sistem file dapat membersihkan penulisan yang tidak lengkap tersebut saat memutar kembali jurnal. Dalam mode berurutan, kerusakan dapat mengakibatkan kerusakan pada file atau file yang sedang ditulis secara aktif selama kerusakan, tetapi sistem file itu sendiri—dan file yang tidak sedang ditulis secara aktif—dijamin aman.
- Tulis Ulang adalah mode penjurnalan ketiga—dan paling tidak aman. Dalam mode writeback, seperti mode terurut, metadata dijurnal, tetapi data tidak. Tidak seperti mode terurut, metadata dan data dapat ditulis dalam urutan apa pun yang masuk akal untuk kinerja terbaik. Ini dapat menawarkan peningkatan kinerja yang signifikan, tetapi jauh lebih tidak aman. Meskipun mode writeback masih menawarkan jaminan keamanan untuk sistem file itu sendiri, file yang ditulis selama atau sebelum crash rentan terhadap kerugian atau korupsi.
Seperti ext2 sebelumnya, ext3 menggunakan pengalamatan internal 16-bit. Ini berarti bahwa dengan ukuran blok 4K, ukuran file terbesar yang dapat ditanganinya adalah 2 TiB dalam ukuran sistem file maksimum 16 TiB.
ext4
Theodore Ts'o (yang saat itu merupakan pengembang utama ext3) mengumumkan ext4 pada tahun 2006, dan ditambahkan ke Linux arus utama dua tahun kemudian, dalam versi kernel 2.6.28. Ts'o menggambarkan ext4 sebagai teknologi sementara yang secara signifikan memperluas ext3 tetapi masih bergantung pada teknologi lama. Dia mengharapkannya pada akhirnya akan digantikan oleh sistem file generasi berikutnya yang sebenarnya.
Ext4 secara fungsional sangat mirip dengan ext3, tetapi membawa dukungan sistem file yang besar, peningkatan ketahanan terhadap fragmentasi, kinerja yang lebih tinggi, dan stempel waktu yang ditingkatkan.
Ext4 vs ext3
Ext3 dan ext4 memiliki beberapa perbedaan yang sangat spesifik, yang akan saya fokuskan di sini.
Kompatibilitas mundur
Ext4 secara khusus dirancang agar kompatibel dengan ext3. Ini tidak hanya memungkinkan sistem file ext3 untuk ditingkatkan di tempat ke ext4; itu juga mengizinkan driver ext4 untuk secara otomatis memasang sistem file ext3 dalam mode ext3, sehingga tidak perlu memelihara dua basis kode secara terpisah.
Sistem file besar
Sistem file Ext3 menggunakan pengalamatan 32-bit, membatasinya menjadi 2 file TiB dan 16 sistem file TiB (dengan asumsi ukuran blok 4 KiB; beberapa sistem file ext3 menggunakan ukuran blok yang lebih kecil dan dengan demikian semakin dibatasi).
Ext4 menggunakan pengalamatan internal 48-bit, sehingga secara teoritis memungkinkan untuk mengalokasikan file hingga 16 TiB pada sistem file hingga 1.000.000 TiB (1 EiB). Implementasi awal ext4 masih terbatas pada 16 sistem file TiB oleh beberapa utilitas pengguna, tetapi mulai tahun 2011, e2fsprogs telah secara langsung mendukung pembuatan sistem file>16TiB ext4. Sebagai salah satu contoh, Red Hat Enterprise Linux secara kontraktual mendukung sistem file ext4 hanya hingga 50 TiB dan merekomendasikan volume ext4 tidak lebih besar dari 100 TiB.
Peningkatan alokasi
Ext4 memperkenalkan banyak peningkatan dalam cara blok penyimpanan dialokasikan sebelum menulisnya ke disk, yang dapat meningkatkan kinerja baca dan tulis secara signifikan.
Ekstensi
Tingkat adalah rentang blok fisik yang berdekatan (hingga 128 MiB, dengan asumsi ukuran blok 4 KiB) yang dapat dipesan dan ditangani sekaligus. Memanfaatkan luasan mengurangi jumlah inode yang dibutuhkan oleh file tertentu dan secara signifikan mengurangi fragmentasi dan meningkatkan kinerja saat menulis file besar.
Alokasi multiblok
Ext3 memanggil pengalokasi bloknya sekali untuk setiap blok baru yang dialokasikan. Ini dapat dengan mudah menghasilkan fragmentasi berat ketika banyak penulis terbuka secara bersamaan. Namun, ext4 menggunakan alokasi tertunda, yang memungkinkannya menggabungkan penulisan dan membuat keputusan yang lebih baik tentang cara mengalokasikan blok untuk penulisan yang belum dilakukan.
Pra-alokasi persisten
Saat melakukan pra-alokasi ruang disk untuk file, sebagian besar sistem file harus menulis nol ke blok untuk file tersebut saat pembuatan. Ext4 memungkinkan penggunaan fallocate() sebagai gantinya, yang menjamin ketersediaan ruang (dan berupaya menemukan ruang yang berdekatan untuk itu) tanpa terlebih dahulu perlu menulis ke sana. Hal ini secara signifikan meningkatkan kinerja baik dalam penulisan maupun pembacaan di masa mendatang dari data tertulis untuk streaming dan aplikasi database.
Alokasi tertunda
Ini adalah fitur yang kenyal—dan kontroversial—. Alokasi tertunda memungkinkan ext4 menunggu untuk mengalokasikan blok sebenarnya yang akan ditulisi data sampai siap untuk mengkomit data itu ke disk. (Sebaliknya, ext3 akan segera mengalokasikan blok, bahkan saat data masih mengalir ke cache tulis.)
Menunda alokasi blok saat data terakumulasi dalam cache memungkinkan sistem file membuat pilihan yang lebih waras tentang cara mengalokasikan blok tersebut, mengurangi fragmentasi (menulis dan, kemudian, membaca) dan meningkatkan kinerja secara signifikan. Sayangnya, meningkatkan potensi kehilangan data dalam program yang belum ditulis secara khusus untuk memanggil fsync() ketika programmer ingin memastikan data telah di-flush seluruhnya ke disk.
Katakanlah sebuah program menulis ulang file seluruhnya:
fd=open("file" ,O_TRUNC); write(fd, data); close(fd);
Dengan sistem file lama, close(fd); cukup untuk menjamin bahwa isi file akan di-flush ke disk. Meskipun penulisan tidak, secara tegas, transaksional, sangat kecil risiko kehilangan data jika terjadi crash setelah file ditutup.
Jika penulisan tidak berhasil (karena kesalahan dalam program, kesalahan pada disk, kehilangan daya, dll.), baik versi asli dan versi file yang lebih baru mungkin hilang atau rusak. Jika proses lain mengakses file saat sedang ditulis, mereka akan melihat versi yang rusak. Dan jika proses lain membuka file dan tidak mengharapkan kontennya berubah—misalnya, perpustakaan bersama yang dipetakan ke beberapa program yang sedang berjalan—mereka mungkin mogok.
Untuk menghindari masalah ini, beberapa programmer menghindari penggunaan O_TRUNC sama sekali. Sebagai gantinya, mereka mungkin menulis ke file baru, menutupnya, lalu mengganti namanya dengan yang lama:
fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");
Di bawah sistem file tanpa alokasi tertunda, ini cukup untuk menghindari potensi kerusakan dan masalah kerusakan yang diuraikan di atas:Sejak rename() adalah operasi atom, tidak akan terganggu oleh crash; dan program yang berjalan akan terus merujuk ke versi file lama yang sekarang tidak ditautkan selama mereka memiliki filehandle terbuka untuk itu. Tetapi karena alokasi ext4 yang tertunda dapat menyebabkan penulisan tertunda dan diurutkan ulang, rename("newfile","file") dapat dilakukan sebelum isi newfile sebenarnya ditulis ke disk, yang membuka masalah proses paralel mendapatkan versi file yang buruk lagi.
Untuk mengurangi ini, kernel Linux (sejak versi 2.6.30) mencoba untuk mendeteksi kasus kode umum ini dan memaksa file yang bersangkutan untuk segera dialokasikan. Ini mengurangi, tetapi tidak mencegah, potensi kehilangan data—dan ini tidak membantu sama sekali dengan file baru. Jika Anda seorang pengembang, harap perhatikan:hanya cara untuk menjamin data ditulis ke disk segera adalah dengan memanggil fsync() dengan tepat.
Subdirektori tak terbatas
Ext3 terbatas pada total 32.000 subdirektori; ext4 memungkinkan jumlah yang tidak terbatas. Dimulai dengan kernel 2.6.23, ext4 menggunakan indeks HTree untuk mengurangi kehilangan kinerja dengan sejumlah besar subdirektori.
Pemeriksaan jurnal
Ext3 tidak memeriksa jurnalnya, yang menyajikan masalah untuk disk atau perangkat pengontrol dengan cache mereka sendiri, di luar kendali langsung kernel. Jika pengontrol atau disk dengan cache-nya sendiri tidak menulis dengan benar, itu dapat merusak urutan transaksi penjurnalan ext3, berpotensi merusak file yang sedang ditulis selama (atau untuk beberapa waktu sebelumnya) crash.
Secara teori, masalah ini diselesaikan dengan penggunaan penghalang tulis—saat memasang sistem file, Anda menyetel barrier=1 di opsi pemasangan, dan perangkat kemudian akan menghormati fsync() panggilan sampai ke logam. Dalam praktiknya, ditemukan bahwa perangkat penyimpanan dan pengontrol sering tidak menghormati hambatan penulisan—meningkatkan kinerja (dan tolok ukur, di mana mereka dibandingkan dengan pesaing mereka) tetapi membuka kemungkinan korupsi data yang seharusnya dicegah.
Memeriksa jurnal memungkinkan sistem file untuk menyadari bahwa beberapa entrinya tidak valid atau rusak pada pemasangan pertama setelah crash. Dengan demikian, ini menghindari kesalahan dengan memutar kembali entri jurnal yang sebagian atau tidak berurutan dan lebih lanjut merusak sistem file—bahkan jika perangkat penyimpanan berbohong dan tidak memenuhi penghalang.
Pemeriksaan sistem file cepat
Di bawah ext3, seluruh sistem file—termasuk file yang dihapus dan kosong—harus diperiksa kapan fsck dipanggil. Sebaliknya, ext4 menandai blok dan bagian yang tidak terisi dari tabel inode seperti itu, memungkinkan fsck untuk melewatkan mereka sepenuhnya. Ini sangat mengurangi waktu untuk menjalankan fsck pada sebagian besar sistem file dan telah diimplementasikan sejak kernel 2.6.24.
Stempel waktu yang ditingkatkan
Ext3 menawarkan cap waktu granular hingga satu detik. Meskipun cukup untuk sebagian besar penggunaan, aplikasi mission-critical sering mencari kontrol waktu yang jauh lebih ketat. Ext4 membuat dirinya tersedia untuk aplikasi perusahaan, ilmiah, dan misi-kritis tersebut dengan menawarkan stempel waktu dalam nanodetik.
Sistem file Ext3 juga tidak menyediakan bit yang cukup untuk menyimpan tanggal di luar 18 Januari 2038. Ext4 menambahkan dua bit tambahan di sini, memperpanjang zaman Unix 408 tahun lagi. Jika Anda membaca ini pada tahun 2446 M, semoga Anda telah pindah ke sistem file yang lebih baik—tetapi ini akan membuat saya secara anumerta sangat, sangat senang jika Anda masih mengukur waktu sejak UTC 00:00, 1 Januari 1970.
Defragmentasi online
Baik ext2 maupun ext3 tidak secara langsung mendukung defragmentasi online—yaitu, mendefrag sistem file saat dipasang. Ext2 memiliki utilitas yang disertakan, e2defrag , itu sesuai dengan namanya—tetapi itu harus dijalankan secara offline saat sistem file tidak dipasang. (Ini, jelas, sangat bermasalah untuk sistem file root.) Situasinya bahkan lebih buruk di ext3—meskipun ext3 jauh lebih kecil kemungkinannya untuk mengalami fragmentasi parah daripada ext2, menjalankan e2defrag terhadap sistem file ext3 dapat mengakibatkan kerusakan parah dan kehilangan data.
Meskipun ext3 awalnya dianggap "tidak terpengaruh oleh fragmentasi," proses yang menggunakan proses penulisan paralel secara besar-besaran ke file yang sama (mis., BitTorrent) memperjelas bahwa ini tidak sepenuhnya terjadi. Beberapa peretasan ruang pengguna dan solusi, seperti Shake, mengatasi hal ini dalam satu atau lain cara—tetapi mereka lebih lambat dan dalam berbagai hal kurang memuaskan daripada proses defrag tingkat kernel yang benar-benar sadar sistem file.
Ext4 mengatasi masalah ini secara langsung dengan e4defrag , utilitas defragmentasi tingkat blok dan tingkat ekstension, mode kernel, sadar sistem file.
Pengembangan ext4 yang sedang berlangsung
Ext4, sebagai Monty Python korban wabah pernah berkata, "belum mati!" Meskipun pengembang utamanya menganggapnya sebagai pengganti sementara di sepanjang jalan menuju sistem file generasi berikutnya, tidak ada kandidat yang mungkin siap (karena masalah teknis atau lisensi) untuk ditempatkan sebagai sistem file root untuk beberapa waktu.
Masih ada beberapa fitur utama yang sedang dikembangkan ke versi ext4, termasuk checksumming metadata, dukungan kuota kelas satu, dan blok alokasi besar.
Metadata checksumming
Karena ext4 memiliki superblok yang berlebihan, checksumming metadata di dalamnya menawarkan sistem file cara untuk mencari tahu sendiri apakah superblok utama rusak dan perlu menggunakan alternatif. Dimungkinkan untuk memulihkan dari superblok yang rusak tanpa melakukan checksum—tetapi pengguna harus terlebih dahulu menyadari bahwa itu adalah rusak, lalu coba pasang sistem file secara manual menggunakan alternatif. Karena memasang sistem file baca-tulis dengan superblok utama yang rusak, dalam beberapa kasus, dapat menyebabkan kerusakan lebih lanjut, ini bukanlah solusi yang memadai, bahkan dengan pengguna yang cukup berpengalaman!
Dibandingkan dengan checksumming per blok yang sangat kuat yang ditawarkan oleh sistem file generasi berikutnya seperti btrfs atau zfs, checksumming metadata ext4 adalah fitur yang cukup lemah. Tapi itu jauh lebih baik daripada tidak sama sekali.
Meskipun kedengarannya tidak perlu dipikirkan—ya, checksum ALL THE THINGS!—ada beberapa tantangan signifikan untuk menggabungkan checksum ke dalam sistem file setelah fakta; lihat dokumen desain untuk detailnya.
Dukungan kuota kelas satu
Tunggu, kuota?! Kami sudah memilikinya sejak 2 hari yang lalu! Ya, tapi mereka selalu menjadi renungan, dan mereka selalu agak menyebalkan. Mungkin tidak ada gunanya membahas detail yang rumit di sini, tetapi dokumen desain menjelaskan cara kuota akan dipindahkan dari ruang pengguna ke dalam kernel dan diterapkan dengan lebih benar dan berperforma tinggi.
Blok alokasi besar
Seiring berjalannya waktu, sistem penyimpanan sial itu terus bertambah besar. Dengan beberapa solid-state drive yang sudah menggunakan ukuran blok perangkat keras 8K, batasan ext4 saat ini untuk blok 4K semakin membatasi. Blok penyimpanan yang lebih besar dapat mengurangi fragmentasi dan meningkatkan kinerja secara signifikan, dengan mengorbankan ruang "kendur" yang meningkat (ruang yang tersisa saat Anda hanya memerlukan sebagian blok untuk menyimpan file atau bagian terakhir dari file).
Anda dapat melihat detail berbulu di dokumen desain.
Keterbatasan praktis dari ext4
Ext4 adalah sistem file yang kuat dan stabil, dan itulah yang mungkin harus digunakan kebanyakan orang sebagai sistem file root pada tahun 2018. Namun, Ext4 tidak dapat menangani semuanya. Mari kita bicara secara singkat tentang beberapa hal yang tidak boleh harapkan dari ext4—sekarang atau mungkin di masa depan.
Meskipun ext4 dapat menangani hingga 1 EiB—setara dengan 1.000.000 TiB—data, Anda benar-benar sangat tidak harus mencoba melakukannya. Ada masalah skala di atas dan di luar kemampuan mengingat alamat dari lebih banyak blok, dan ext4 tidak sekarang (dan kemungkinan besar tidak akan pernah) menskalakan lebih dari 50-100 TiB data.
Ext4 juga tidak cukup untuk menjamin integritas data Anda. Kemajuan besar seperti penjurnalan kembali dalam 3 hari terakhir, itu tidak mencakup banyak penyebab umum korupsi data. Jika data rusak saat sudah ada di disk—oleh perangkat keras yang rusak, dampak sinar kosmik (ya, sungguh), atau degradasi data yang sederhana dari waktu ke waktu—ext4 tidak memiliki cara untuk mendeteksi atau memperbaiki kerusakan tersebut.
Membangun dua item terakhir, ext4 hanyalah filesystem pure murni , dan bukan pengelola volume penyimpanan. Ini berarti bahwa meskipun Anda memiliki banyak disk—dan karenanya paritas atau redundansi, yang secara teoritis dapat Anda pulihkan dari data yang rusak—ext4 tidak memiliki cara untuk mengetahuinya atau menggunakannya untuk keuntungan Anda. Meskipun secara teori mungkin untuk memisahkan sistem file dan sistem manajemen volume penyimpanan dalam lapisan terpisah tanpa kehilangan fitur deteksi dan perbaikan kerusakan otomatis, sistem penyimpanan saat ini tidak dirancang, dan ini akan menghadirkan tantangan signifikan untuk desain baru.
Sistem file alternatif
Sebelum kita mulai, peringatan:Jadilah sangat hati-hati dengan sistem file alternatif apa pun yang tidak ada di dan didukung langsung sebagai bagian dari kernel utama distribusi Anda!
Meskipun sistem file aman , menggunakannya sebagai sistem file root dapat benar-benar menakutkan jika ada sesuatu yang tersendat selama pemutakhiran kernel. Jika Anda tidak sangat nyaman dengan gagasan untuk mem-boot dari media alternatif dan menyodok secara manual dan sabar pada modul kernel, konfigurasi grub, dan DKMS dari chroot... jangan membatalkan reservasi dengan sistem file root pada sistem yang penting bagi Anda.
Mungkin ada alasan bagus untuk menggunakan sistem file yang tidak didukung langsung oleh distro Anda—tetapi jika Anda melakukannya, saya sangat menyarankan Anda memasangnya setelah sistem sudah aktif dan dapat digunakan. (Misalnya, Anda mungkin memiliki sistem file root ext4, tetapi menyimpan sebagian besar data Anda di kumpulan zfs atau btrfs.)
XFS
XFS hampir sama arusnya dengan sistem file non-ext di Linux. Ini adalah sistem file jurnal 64-bit yang telah dibangun ke dalam kernel Linux sejak tahun 2001 dan menawarkan kinerja tinggi untuk sistem file besar dan tingkat konkurensi yang tinggi (yaitu, sejumlah besar proses yang semuanya menulis ke sistem file sekaligus).
XFS menjadi sistem file default untuk Red Hat Enterprise Linux, pada RHEL 7. Ini masih memiliki beberapa kelemahan untuk pengguna rumahan atau bisnis kecil — terutama, sangat sulit untuk mengubah ukuran sistem file XFS yang ada, sampai-sampai biasanya membuat lebih banyak masuk akal untuk membuat yang lain dan menyalin data Anda.
Meskipun XFS stabil dan berkinerja, tidak ada cukup perbedaan penggunaan akhir yang nyata antara XFS dan ext4 untuk merekomendasikan penggunaannya di mana pun yang bukan default (mis., RHEL7) kecuali ini mengatasi masalah khusus yang Anda alami dengan ext4, seperti sistem file berkapasitas>50 TiB.
XFS sama sekali bukan sistem file "generasi berikutnya" seperti ZFS, btrfs, atau bahkan WAFL (sistem file SAN berpemilik). Seperti ext4, itu kemungkinan besar harus dianggap sebagai pengganti sementara di sepanjang jalan menuju sesuatu yang lebih baik.
ZFS
ZFS dikembangkan oleh Sun Microsystems dan dinamai zettabyte—setara dengan 1 triliun gigabyte—karena secara teoritis dapat menangani sistem penyimpanan sebesar itu.
Sebuah sistem file generasi berikutnya yang sebenarnya, ZFS menawarkan manajemen volume (kemampuan untuk menangani beberapa perangkat penyimpanan individu dalam satu sistem file), checksumming kriptografi tingkat blok (memungkinkan deteksi korupsi data dengan tingkat akurasi yang sangat tinggi), perbaikan korupsi otomatis (di mana penyimpanan redundan atau paritas tersedia), replikasi inkremental asinkron yang cepat, kompresi inline, dan banyak lagi. Lebih banyak lagi.
Masalah terbesar dengan ZFS, dari sudut pandang pengguna Linux, adalah lisensi. ZFS dilisensikan CDDL, yang merupakan lisensi semi-permisif yang bertentangan dengan GPL. Ada banyak kontroversi mengenai implikasi penggunaan ZFS dengan kernel Linux, dengan pendapat mulai dari "itu pelanggaran GPL" hingga "itu pelanggaran CDDL" hingga "tidak apa-apa, hanya saja belum diuji di pengadilan. " Yang paling menonjol, Canonical telah menyertakan kode ZFS sebaris di kernel defaultnya sejak 2016 tanpa tantangan hukum sejauh ini.
Saat ini, bahkan sebagai sangat pengguna ZFS yang rajin, saya tidak akan merekomendasikan ZFS sebagai sistem file root Linux. Jika Anda ingin memanfaatkan manfaat ZFS di Linux, siapkan sistem file root kecil di ext4, lalu letakkan ZFS di sisa penyimpanan Anda, dan letakkan data, aplikasi, apa pun yang Anda suka di dalamnya—tetapi tetap root pada ext4, hingga distribusi Anda secara eksplisit
btrfs
Btrfs—kependekan dari B-Tree Filesystem, dan biasanya diucapkan "mentega"—diumumkan oleh Chris Mason pada tahun 2007 selama masa jabatannya di Oracle. Btrfs membidik sebagian besar tujuan yang sama seperti ZFS, menawarkan pengelolaan beberapa perangkat, checksumming per blok, replikasi asinkron, kompresi inline, dan banyak lagi.
Pada 2018, btrfs cukup stabil dan dapat digunakan sebagai sistem file disk tunggal standar tetapi mungkin tidak dapat diandalkan sebagai manajer volume. Ia mengalami masalah kinerja yang signifikan dibandingkan dengan ext4, XFS, atau ZFS dalam banyak kasus penggunaan umum, dan fitur generasi berikutnya—replikasi, topologi multi-disk, dan manajemen snapshot—bisa jadi sangat bermasalah, dengan hasil mulai dari penurunan kinerja yang sangat parah. hingga kehilangan data yang sebenarnya.
Status btrf yang sedang berlangsung kontroversial; SUSE Enterprise Linux mengadopsinya sebagai sistem file default pada tahun 2015, sedangkan Red Hat mengumumkan tidak akan lagi mendukung btrf yang dimulai dengan RHEL 7.4 pada tahun 2017. Mungkin perlu dicatat bahwa produksi, penyebaran yang didukung btrf menggunakannya sebagai sistem file disk tunggal, tidak sebagai pengelola volume multi-disk a la ZFS—bahkan Synology, yang menggunakan btrfs pada peralatan penyimpanannya, tetapi melapisinya di atas RAID kernel Linux konvensional (mdraid) untuk mengelola disk.