Wawancara kedua dengan Eduard Shishkin, pengembang sistem file Reiser4, telah dipublikasikan.
Untuk memulai, harap ingatkan pembaca di mana dan untuk siapa Anda bekerja.
Saya bekerja sebagai Arsitek Penyimpanan Utama di Huawei Technologies, Pusat Penelitian Jerman. Di departemen virtualisasi saya menangani berbagai aspek penyimpanan data. Aktivitas saya tidak terkait dengan sistem operasi tertentu.
Apakah Anda saat ini berkomitmen pada cabang kernel utama?
Sangat jarang, dan hanya jika majikan saya memerlukannya. Terakhir kali sekitar tiga tahun yang lalu, saya mengirimkan patch untuk meningkatkan throughput penyimpanan yang dibagikan pada host menggunakan protokol 9p (nama lain untuk bisnis ini adalah VirtFS). Satu catatan penting harus dibuat di sini: meskipun saya telah lama bekerja dengan Linux, saya tidak pernah menjadi penggemarnya, yaitu, saya “bernafas dengan teratur”, seperti yang lainnya. Khususnya, jika saya melihat ada kekurangan, saya dapat menunjukkannya paling banyak satu kali. Dan agar Anda dapat mengikuti seseorang dan membujuk mereka - ini tidak akan terjadi.
Saya ingat terakhir kali, sepuluh tahun yang lalu, Anda cukup kritis terhadap gaya pengembangan kernel. Dari sudut pandang Anda (atau mungkin perusahaan), apakah ada yang berubah, apakah masyarakat menjadi lebih responsif atau tidak? Jika tidak, menurut Anda siapa yang harus disalahkan?
Saya tidak pernah melihat adanya perubahan menjadi lebih baik. Masalah utama masyarakat adalah penggantian ilmu pengetahuan dengan teknologi politik, hubungan personal, opini mayoritas, populisme, nasehat dari “suara hati”, kompromi yang busuk, apapun selain ilmu pengetahuan. Ilmu komputer, apa pun yang dikatakan orang, pada dasarnya adalah ilmu pasti. Dan jika seseorang mulai menyatakan nilainya sendiri untuk 2x2, berbeda dari 4, di bawah bendera “Linux way”, atau di bawah bendera lain, maka hal ini tidak akan membawa apa pun selain kerugian.
Semua masalah terutama disebabkan oleh ketidakmampuan dan kurangnya pendidikan dari mereka yang mengambil keputusan. Jika seorang manajer tidak kompeten, dia tidak mampu membuat keputusan yang obyektif dan memadai. Jika dia juga tidak berbudaya, dia tidak dapat menemukan spesialis kompeten yang akan memberinya nasihat yang tepat. Dengan kemungkinan besar, pilihan akan jatuh pada penipu yang mengatakan “hal-hal yang tampaknya benar”. Lingkungan yang korup selalu berkembang di sekitar pemimpin yang tidak kompeten. Terlebih lagi, sejarah tidak mengenal pengecualian dalam hal ini, dan masyarakat adalah konfirmasi paling jelas mengenai hal ini.
Bagaimana Anda menilai kemajuan dalam pengembangan Btrfs? Apakah FS ini menghilangkan penyakit anak? Bagaimana Anda memposisikannya sendiri - sebagai FS “untuk rumah” atau untuk penggunaan perusahaan juga?
Saya tidak membuangnya. Segala sesuatu yang saya sebutkan 11 tahun lalu masih relevan hingga saat ini. Salah satu permasalahan Btrfs yang membuatnya tidak cocok untuk kebutuhan serius adalah masalah ruang kosong. Saya bahkan tidak berbicara tentang fakta bahwa pengguna diminta untuk lari ke toko untuk mendapatkan disk baru dalam situasi di mana FS lain akan menunjukkan banyak ruang kosong di partisi. Ketidakmampuan untuk menyelesaikan operasi pada volume logis karena kurangnya ruang kosong juga bukan hal terburuk. Hal terburuknya adalah pengguna yang tidak memiliki hak istimewa hampir selalu dapat, melewati kuota disk apa pun, menghilangkan ruang kosong semua orang dalam waktu yang cukup singkat.
Tampilannya seperti ini (diuji untuk kernel Linux 5.12). Sebuah skrip diluncurkan pada sistem yang baru diinstal, yang dalam satu lingkaran membuat file dengan nama tertentu di direktori home, menulis data ke file tersebut pada offset tertentu, dan kemudian menghapus file tersebut. Setelah satu menit menjalankan skrip ini, tidak ada hal aneh yang terjadi. Setelah lima menit, porsi ruang yang ditempati pada partisi bertambah sedikit. Setelah dua hingga tiga jam mencapai 50% (dengan nilai awal 15%). Dan setelah lima atau enam jam bekerja, skrip tersebut mogok dengan kesalahan "tidak ada ruang kosong di partisi". Setelah ini, Anda tidak lagi dapat menulis file 4K ke partisi Anda.
Situasi menarik terjadi: Anda akhirnya tidak menulis apa pun ke partisi, dan semua ruang kosong (sekitar 85%) hilang entah kemana. Analisis bagian yang terkena serangan semacam itu akan mengungkapkan banyak node pohon yang hanya berisi satu item (sebuah objek yang dilengkapi dengan kunci), berukuran beberapa byte. Artinya, konten yang sebelumnya menempati 15% ruang disk ternyata “dioleskan” secara merata ke seluruh partisi sehingga tidak ada tempat untuk menulis file baru, karena kuncinya lebih besar dari semua yang sudah ada, dan gratis. blok pada partisi telah habis.
Selain itu, semua ini sudah terjadi pada konfigurasi dasar Btrfs (tanpa snapshot, subvolume, dll.), dan tidak masalah bagaimana Anda memutuskan untuk menyimpan badan file di FS tersebut (sebagai "fragmen" di pohon, atau sebagai luasan dari blok yang belum diformat) - hasil akhirnya akan sama.
Anda tidak akan dapat membuat sistem file upstream lainnya terkena serangan seperti itu (tidak peduli apa yang mereka katakan kepada Anda). Saya telah menjelaskan penyebab masalahnya sejak lama: ini adalah penyimpangan total dari konsep B-tree di Btrfs, yang memungkinkannya mengalami kemunduran secara spontan atau sengaja. Khususnya, pada beban tertentu, sistem file Anda akan terus-menerus “berantakan” selama pengoperasiannya sendiri, tanpa bantuan dari luar. Jelas bahwa segala macam proses latar belakang yang "menekan" hanya akan menyelamatkan situasi di masing-masing desktop.
Di server kolektif, penyerang akan selalu bisa “mengungguli” mereka. Administrator sistem bahkan tidak akan dapat menentukan siapa sebenarnya yang menindasnya. Cara tercepat untuk memperbaiki masalah ini di Btrfs adalah dengan mengembalikan struktur B-tree biasa, yaitu. mendesain ulang format disk dan menulis ulang sebagian besar kode Btrfs. Ini akan memakan waktu 8-10 tahun, termasuk proses debug, asalkan pengembang secara ketat mengikuti artikel asli tentang algoritma dan struktur data yang relevan, dan tidak memainkan permainan “ponsel rusak”, seperti yang biasa (dan dianjurkan) di “Linux jalan".
Di sini kita juga perlu menambahkan waktu yang dibutuhkan pengembang untuk memahami semua ini. Di sinilah segalanya menjadi lebih sulit. Bagaimanapun, 10 tahun tidak cukup bagi mereka untuk memahaminya. Sampai saat itu tiba, Anda tidak bisa mengharapkan keajaiban. Ini tidak akan terjadi dalam bentuk opsi pemasangan “yang Anda dan saya tidak mengetahuinya”, atau dalam bentuk tambalan yang “hanya urusan bisnis” untuk dipersiapkan. Untuk setiap “perbaikan” yang tergesa-gesa, saya akan menyajikan skenario kemunduran yang baru. B-tree adalah salah satu topik favorit saya, dan saya harus mengatakan bahwa struktur ini tidak mentolerir kebebasan!
Bagaimana cara memposisikan Btrfs untuk diri saya sendiri? Sebagai sesuatu yang sama sekali tidak bisa disebut sistem file apalagi digunakan. Karena, menurut definisi, FS adalah subsistem OS yang bertanggung jawab atas pengelolaan sumber daya “ruang disk” yang efektif, yang tidak kita lihat dalam kasus Btrfs. Nah, bayangkan Anda datang ke toko untuk membeli jam tangan agar tidak terlambat ke kantor, dan sebagai ganti jam tangan, mereka menjual pemanggang listrik dengan pengatur waktu maksimal 30 menit. Jadi, situasi dengan Btrfs bahkan lebih buruk lagi.
Melihat-lihat milis, saya sering menemukan pernyataan bahwa mengelola ruang disk secara efektif tidak lagi relevan karena murahnya drive. Ini benar-benar tidak masuk akal. Tanpa pengelola ruang disk yang efektif, OS akan menjadi rentan dan tidak dapat digunakan. Terlepas dari kapasitas disk pada mesin Anda.
Saya ingin meminta komentar tentang penghentian dukungan Btrfs di RHEL.
Tidak ada yang istimewa untuk dikomentari di sini, semuanya sangat jelas. Mereka juga menjadikannya sebagai “pratinjau teknologi”. Jadi, saya tidak melalui "pratinjau" ini. Jangan biarkan label ini menggantung selamanya! Namun mereka tidak dapat meluncurkan produk sampingan yang cacat dengan dukungan penuh. RHEL adalah suatu perusahaan, yaitu hubungan komoditas-uang yang ditentukan. Red Hat tidak dapat menindas pengguna seperti yang mereka lakukan di milis Btrfs. Bayangkan saja situasinya: seorang klien yang membayar uang hasil jerih payahnya untuk disk tersebut dan juga Anda atas dukungannya, ingin memahami ke mana perginya ruang disknya setelah dia tidak menulis apa pun. Apa yang akan Anda jawab padanya untuk ini?
Lebih jauh. Klien Red Hat mencakup bank dan bursa besar ternama. Bayangkan apa yang akan terjadi jika mereka terkena serangan DoS berdasarkan kerentanan yang disebutkan di Btrfs. Menurut Anda siapa yang bertanggung jawab atas hal ini? Kepada mereka yang hendak menuding garis lisensi GPL yang tertulis bahwa pembuatnya tidak bertanggung jawab atas apapun, saya akan langsung berkata: “sembunyikan!” Red Hat akan menjawab, dan sedemikian rupa sehingga tampaknya tidak cukup! Namun saya tahu bahwa Red Hat tidak menghadapi masalah seperti ini, mengingat tim insinyur QA mereka yang sangat kuat dan pernah bekerja sama dengan saya.
Mengapa beberapa perusahaan terus mendukung Btrfs dalam produk perusahaannya?
Perlu diketahui bahwa awalan “perusahaan” pada nama produk tidak berarti banyak. Perusahaan adalah ukuran tanggung jawab yang tertanam dalam hubungan kontrak dengan klien. Saya hanya mengetahui satu perusahaan yang berbasis GNU/Linux - RHEL. Segala sesuatu yang lain, dari sudut pandang saya, hanya disajikan sebagai sebuah perusahaan, tetapi bukan satu kesatuan. Dan terakhir, jika ada permintaan akan sesuatu, maka akan selalu ada penawaran (dalam kasus kami, ini adalah “dukungan”) yang disebutkan. Ada permintaan untuk segalanya, termasuk. dan perangkat lunak yang tidak dapat digunakan. Bagaimana permintaan tersebut terbentuk dan siapa yang mendorongnya adalah topik lain.
Jadi, saya tidak akan langsung mengambil kesimpulan apa pun setelah Facebook dikabarkan telah menerapkan Btrfs di servernya. Selain itu, saya akan merekomendasikan untuk menjaga kerahasiaan alamat server tersebut karena alasan di atas.
Mengapa begitu banyak upaya dilakukan untuk membersihkan kode XFS belakangan ini? Bagaimanapun, awalnya ini adalah sistem file pihak ketiga, dan ext4 telah stabil sejak lama dan memiliki kesinambungan dari versi sebelumnya yang sama stabilnya. Apa minat Red Hat terhadap XFS? Apakah masuk akal untuk secara aktif mengembangkan dua sistem file yang memiliki tujuan serupa - ext4 dan XFS?
Saya tidak ingat apa yang memotivasi hal ini. Kemungkinan besar inisiatif ini datang dari klien Red Hat. Saya ingat penelitian semacam ini dilakukan: pada beberapa sistem file dari hulu, sejumlah besar objek dibuat pada drive kelas atas generasi baru. Berdasarkan hasilnya, XFS berperilaku lebih baik daripada ext4. Jadi mereka mulai mempromosikannya sebagai yang paling menjanjikan. Bagaimanapun, saya tidak akan mencari sesuatu yang sensasional di sini.
Bagi saya, mereka seperti mengganti penusuk dengan sabun. Tidak ada gunanya mengembangkan ext4 dan XFS. Baik secara paralel dan salah satunya untuk dipilih. Tidak ada hal baik yang akan terjadi dari ini. Meskipun di alam seringkali terdapat situasi dimana terdapat banyak potensi untuk berkembang, namun tidak ada ruang untuk berkembang. Dalam hal ini, berbagai pertumbuhan baru yang sangat buruk muncul, yang menjadi sasaran semua orang (“Oh, lihat, apa yang tidak akan Anda lihat dalam hidup ini!”).
Apakah menurut Anda masalah pelanggaran lapisan telah diselesaikan (dalam arti negatif) dengan munculnya fungsi enkripsi di ext4, F2FS (belum lagi RAID di Btrfs)?
Secara umum, pengenalan tingkat mana pun dan pengambilan keputusan untuk tidak melanggarnya biasanya merupakan masalah kebijakan, dan saya tidak berjanji untuk mengomentari apa pun di sini. Aspek obyektif dari pelanggaran lapisan tidak begitu menarik bagi siapa pun, tetapi kita dapat mempertimbangkan beberapa di antaranya dengan menggunakan contoh pelanggaran "dari atas", yaitu implementasi fungsionalitas dalam FS yang sudah ada pada lapisan blok. “Pelanggaran” seperti itu hanya dibenarkan dengan pengecualian yang jarang terjadi. Untuk setiap kasus tersebut, pertama-tama Anda harus membuktikan dua hal: bahwa hal tersebut benar-benar diperlukan, dan bahwa desain sistem tidak akan dirugikan dengan hal tersebut.
Misalnya, mirroring, yang secara tradisional merupakan aktivitas lapisan blok, masuk akal untuk diterapkan pada tingkat sistem file. Untuk alasan yang berbeda. Misalnya, kerusakan data “diam” (bit rot) terjadi pada disk drive. Ini adalah saat perangkat berfungsi dengan baik, tetapi data blok tiba-tiba rusak karena pengaruh kuantum gamma keras yang dipancarkan oleh quasar jauh, dll. Yang terburuk adalah jika blok ini ternyata merupakan blok sistem FS (superblock, blok bitmap, node pohon penyimpanan, dll), karena hal ini tentu akan menyebabkan kepanikan kernel.
Harap dicatat bahwa mirror yang ditawarkan oleh lapisan blok (disebut RAID 1) tidak akan menyelamatkan Anda dari masalah ini. Ya, benarkah: seseorang harus memeriksa checksum dan membaca replikanya jika terjadi kegagalan? Selain itu, masuk akal untuk mencerminkan tidak hanya semuanya, tetapi hanya metadatanya saja. Beberapa data penting (misalnya, file aplikasi penting yang dapat dijalankan) dapat disimpan sebagai metadata. Dalam hal ini, mereka mendapat jaminan keamanan yang sama. Masuk akal untuk mempercayakan perlindungan data yang tersisa ke subsistem lain (bahkan mungkin aplikasi pengguna) - kami telah menyediakan semua kondisi yang diperlukan untuk ini.
Mirror “ekonomis” seperti itu mempunyai hak untuk ada, dan mereka hanya dapat diatur secara efektif pada tingkat sistem file. Jika tidak, pelanggaran pelapisan akan mengacaukan subsistem dengan kode duplikat demi beberapa manfaat mikroskopis. Contoh mencolok dari hal ini adalah implementasi RAID-5 menggunakan FS. Solusi seperti itu (memiliki RAID / LVM dalam sistem file) mematikan yang terakhir dalam hal arsitektur. Perlu juga dicatat di sini bahwa pelanggaran berlapis “disebarkan” oleh berbagai jenis penipu pemasaran. Dengan tidak adanya ide, fungsionalitas yang telah lama diterapkan di tingkat tetangga ditambahkan ke subsistem, ini disajikan sebagai fitur baru yang sangat berguna dan didorong secara aktif.
Reiser4 dituduh melanggar level “dari bawah”. Berdasarkan fakta bahwa sistem file tidak monolitik, seperti yang lainnya, tetapi modular, dibuat asumsi yang tidak berdasar bahwa ia melakukan apa yang seharusnya dilakukan oleh level di atas (VFS).
Apakah mungkin untuk berbicara tentang kematian ReiserFS v3.6 dan, misalnya, JFS? Akhir-akhir ini mereka hampir tidak mendapat perhatian di bagian inti. Apakah itu sudah ketinggalan zaman?
Di sini kita perlu mendefinisikan apa arti matinya suatu produk perangkat lunak. Di satu sisi, mereka berhasil digunakan (untuk itulah mereka diciptakan), yang berarti mereka hidup. Di sisi lain, saya tidak bisa berbicara tentang JFS (saya tidak tahu banyak), tetapi ReiserFS (v3) sangat sulit beradaptasi dengan tren baru (diuji dalam praktik). Artinya ke depan pengembang tidak akan memperhatikannya, tapi yang lebih mudah beradaptasi. Dari sisi ini ternyata sudah mati secara arsitektural. Saya tidak akan memanipulasi konsep “usang secara moral” sama sekali. Ini berlaku dengan baik, misalnya, pada lemari pakaian, tetapi tidak pada produk perangkat lunak. Ada konsep inferioritas dan superioritas pada sesuatu. Saya benar-benar dapat mengatakan bahwa ReserFS v3 sekarang lebih rendah daripada Reiser4 dalam segala hal, tetapi dalam beberapa jenis beban kerja, ini lebih unggul daripada semua FS upstream lainnya.
Tahukah Anda tentang perkembangan FS Tux3 dan HAMMER/HAMMER2 (FS untuk DragonFly BSD)?
Ya kami tahu. Di Tux3 saya pernah tertarik dengan teknologi snapshot mereka (yang disebut "penunjuk versi"), tetapi di Reiser4 kemungkinan besar kami akan menempuh jalur yang berbeda. Saya sudah lama berpikir untuk mendukung snapshot dan belum memutuskan bagaimana menerapkannya untuk volume Reiser4 sederhana. Faktanya adalah teknik penghitung referensi “malas” bermodel baru yang diusulkan oleh Ohad Rodeh hanya bekerja untuk B-tree. Kami tidak memilikinya. Untuk struktur data yang digunakan di Reiesr4, penghitung "malas" tidak ditentukan - untuk memperkenalkannya, perlu untuk memecahkan masalah algoritmik tertentu, yang belum pernah dilakukan oleh siapa pun.
Menurut HAMMER: Saya membaca artikel dari penciptanya. Tidak tertarik. Sekali lagi, pohon B. Struktur data ini sudah ketinggalan jaman. Kami meninggalkannya pada abad terakhir.
Bagaimana Anda menilai meningkatnya permintaan untuk FS cluster jaringan seperti CephFS/GlusterFS/dll? Apakah tuntutan ini berarti adanya pergeseran prioritas pengembang ke FS jaringan dan kurangnya perhatian terhadap FS lokal?
Ya, pergeseran prioritas telah terjadi. Perkembangan sistem file lokal mengalami stagnasi. Sayangnya, melakukan sesuatu yang signifikan untuk volume lokal sekarang cukup sulit dan tidak semua orang bisa melakukannya. Tidak ada yang mau berinvestasi dalam pengembangan mereka. Ini hampir sama dengan meminta organisasi komersial untuk mengalokasikan uang untuk penelitian matematika - tanpa antusiasme mereka akan bertanya kepada Anda bagaimana Anda dapat menghasilkan uang dari sebuah teorema baru. Sekarang FS lokal adalah sesuatu yang secara ajaib muncul “di luar kotak” dan “seharusnya selalu berfungsi,” dan jika tidak berhasil, hal itu akan menyebabkan keluhan yang tidak terselesaikan seperti: “Ya, apa yang mereka pikirkan!”
Hal ini menyebabkan kurangnya perhatian terhadap FS lokal, padahal masih banyak pekerjaan di bidang tersebut. Dan ya, semua orang telah beralih ke penyimpanan terdistribusi, yang dibangun berdasarkan sistem file lokal yang sudah ada. Ini sangat modis sekarang. Ungkapan “Big Data” memacu adrenalin banyak orang, menghubungkannya dengan konferensi, lokakarya, gaji besar, dll.
Seberapa masuk akal untuk mengimplementasikan sistem file jaringan di ruang kernel dan bukan di ruang pengguna?
Pendekatan yang sangat masuk akal yang belum diterapkan di mana pun. Secara umum, pertanyaan tentang di ruang mana sistem file jaringan harus diimplementasikan adalah “pedang bermata dua.” Baiklah, mari kita lihat sebuah contoh. Klien mencatat data pada mesin jarak jauh. Mereka masuk ke cache halamannya dalam bentuk halaman kotor. Ini adalah pekerjaan untuk sistem file jaringan "gerbang tipis" di ruang kernel. Kemudian sistem operasi cepat atau lambat akan meminta Anda untuk menulis halaman tersebut ke disk untuk membebaskannya. Kemudian modul FS jaringan penerusan IO (pengiriman) ikut berperan. Ini menentukan mesin server (node server) mana yang akan dituju oleh halaman-halaman ini.
Kemudian tumpukan jaringan mengambil alih (dan, seperti yang kita ketahui, ini diimplementasikan di ruang kernel). Selanjutnya, node server menerima paket tersebut dengan data atau metadata dan menginstruksikan modul penyimpanan backend (yaitu, FS lokal yang beroperasi di ruang kernel) untuk mencatat semua hal ini. Jadi, kami telah mengurangi pertanyaan menjadi di mana modul “pengiriman” dan “penerimaan” harus bekerja. Jika salah satu modul tersebut berjalan di ruang pengguna, hal ini pasti akan menyebabkan peralihan konteks (karena kebutuhan untuk menggunakan layanan kernel). Jumlah sakelar tersebut bergantung pada detail implementasi.
Jika terdapat banyak sakelar seperti itu, maka throughput penyimpanan (kinerja I/O) akan menurun. Jika penyimpanan backend Anda terdiri dari disk yang lambat, Anda tidak akan melihat penurunan yang signifikan. Namun jika Anda memiliki disk yang cepat (SSD, NVRAM, dll.), maka peralihan konteks sudah menjadi “hambatan” dan, dengan menghemat peralihan konteks, kinerja dapat meningkat secara signifikan. Cara standar untuk menghemat uang adalah dengan memindahkan modul ke ruang kernel. Misalnya, kami menemukan bahwa memindahkan server 9p dari QEMU ke kernel pada mesin host menghasilkan peningkatan kinerja VirtFS tiga kali lipat.
Ini, tentu saja, bukan FS jaringan, tetapi sepenuhnya mencerminkan esensi dari segala sesuatunya. Kelemahan dari optimasi ini adalah masalah portabilitas. Bagi sebagian orang, hal terakhir ini mungkin penting. Misalnya, GlusterFS tidak memiliki modul sama sekali di kernel. Berkat ini, sekarang ia berfungsi di banyak platform, termasuk NetBSD.
Konsep apa yang dapat dipinjam oleh FS lokal dari FS jaringan dan sebaliknya?
Saat ini, FS jaringan, sebagai suatu peraturan, memiliki add-on pada FS lokal, jadi saya tidak begitu mengerti bagaimana Anda dapat meminjam sesuatu dari FS lokal. Baiklah, mari kita bayangkan sebuah perusahaan dengan 4 karyawan, di mana setiap orang melakukan urusannya sendiri: yang satu mendistribusikan, yang lain mengirim, yang ketiga menerima, yang keempat menyimpan. Dan pertanyaannya, apa yang bisa dipinjam perusahaan dari karyawannya yang menyimpannya, terdengar salah (perusahaan sudah lama memiliki apa yang bisa dipinjam darinya).
Namun FS lokal harus banyak belajar dari FS jaringan. Pertama, Anda harus belajar dari mereka cara menggabungkan volume logis pada tingkat tinggi. Sekarang yang disebut Sistem file lokal “canggih” mengumpulkan volume logis secara eksklusif menggunakan teknologi “perangkat virtual” yang dipinjam dari LVM (pelanggaran lapisan menular yang sama yang pertama kali diterapkan di ZFS). Dengan kata lain, penerjemahan alamat virtual (nomor blok) menjadi alamat asli dan sebaliknya terjadi pada tingkat rendah (yaitu, setelah sistem file mengeluarkan permintaan I/O).
Harap dicatat bahwa menambah dan menghapus perangkat ke volume logis (bukan cermin) yang diatur pada lapisan blok menyebabkan masalah yang tidak banyak dibicarakan oleh pemasok "fitur" tersebut. Saya berbicara tentang fragmentasi pada perangkat nyata, yang dapat mencapai nilai yang sangat besar, sedangkan pada perangkat virtual semuanya baik-baik saja. Namun, hanya sedikit orang yang tertarik dengan perangkat virtual: semua orang tertarik dengan apa yang terjadi di perangkat Anda yang sebenarnya. Tetapi FS seperti ZFS (serta FS apa pun yang digabungkan dengan LVM) hanya berfungsi dengan perangkat disk virtual (mengalokasikan alamat disk virtual dari yang gratis, mendefrag perangkat virtual ini, dll.). Dan mereka tidak tahu apa yang terjadi di perangkat sebenarnya!
Sekarang bayangkan Anda tidak memiliki fragmentasi pada perangkat virtual (yaitu, Anda hanya memiliki satu tingkatan raksasa yang tinggal di sana), Anda menambahkan disk ke volume logis Anda, lalu menghapus disk acak lain dari volume logis Anda dan kemudian menyeimbangkannya kembali. Dan berkali-kali. Tidak sulit untuk membayangkan bahwa pada perangkat virtual Anda masih memiliki tingkat hidup yang sama, tetapi pada perangkat nyata Anda tidak akan melihat sesuatu yang baik.
Hal terburuknya adalah Anda bahkan tidak dapat memperbaiki situasi ini! Satu-satunya hal yang dapat Anda lakukan di sini adalah meminta sistem file untuk mendefrag perangkat virtual. Tapi dia akan memberitahu Anda bahwa semuanya baik-baik saja di sana - hanya ada satu tingkat, fragmentasi adalah nol, dan tidak ada yang lebih baik! Jadi, volume logis yang disusun pada tingkat blok tidak dimaksudkan untuk penambahan/penghapusan perangkat berulang kali. Dalam cara yang baik, Anda hanya perlu merakit volume logis pada tingkat blok satu kali, memberikannya ke sistem file, dan kemudian tidak melakukan apa pun dengannya.
Selain itu, kombinasi subsistem FS+LVM independen tidak memungkinkan memperhitungkan sifat berbeda dari drive tempat volume logis dikumpulkan. Memang, misalkan Anda telah merakit volume logis dari HDD dan perangkat solid-state. Namun yang pertama memerlukan defragmentasi, sedangkan yang terakhir tidak. Untuk yang terakhir, Anda perlu mengeluarkan permintaan pembuangan, tetapi untuk yang pertama, tidak, dll. Namun, dalam kombinasi ini cukup sulit untuk menunjukkan selektivitas tersebut.
Perhatikan bahwa setelah membuat LVM Anda sendiri pada sistem file, situasinya tidak menjadi lebih baik. Selain itu, dengan melakukan ini, Anda sebenarnya mengakhiri prospek perbaikan di masa depan. Ini sangat buruk. Berbagai jenis drive dapat hidup di mesin yang sama. Dan jika sistem file tidak membedakannya, lalu siapa lagi?
Masalah lainnya terletak pada penantian apa yang disebut. Sistem file “Write-Anywhere” (ini juga termasuk Reiser4, jika Anda menentukan model transaksional yang sesuai selama pemasangan). Sistem file seperti itu harus menyediakan alat defragmentasi yang kekuatannya belum pernah ada sebelumnya. Dan manajer volume tingkat rendah tidak membantu di sini, tetapi hanya menghalangi. Faktanya adalah bahwa dengan manajer seperti itu, FS Anda akan menyimpan peta blok gratis hanya dari satu perangkat - perangkat virtual. Oleh karena itu, Anda hanya dapat mendefrag perangkat virtual. Ini berarti defragmenter Anda akan bekerja dalam waktu yang sangat lama pada satu ruang alamat virtual yang sangat besar.
Dan jika Anda memiliki banyak pengguna yang melakukan penimpaan acak, maka efek berguna dari defragmenter tersebut akan dikurangi menjadi nol. Sistem Anda pasti akan mulai melambat, dan Anda hanya perlu menyerah pada diagnosis "desain rusak" yang mengecewakan. Beberapa defragmenter yang berjalan pada ruang alamat yang sama hanya akan saling mengganggu. Ini adalah masalah yang sama sekali berbeda jika Anda memelihara peta blok gratis Anda sendiri untuk setiap perangkat sebenarnya. Ini secara efektif akan memparalelkan proses defragmentasi.
Namun ini hanya dapat dilakukan jika Anda memiliki pengelola volume logis tingkat tinggi. Sistem file lokal dengan pengelola seperti itu sebelumnya tidak ada (setidaknya, saya tidak mengetahuinya). Hanya sistem file jaringan (misalnya GlusterFS) yang memiliki pengelola seperti itu. Contoh lain yang sangat penting adalah utilitas pemeriksaan integritas volume (fsck). Jika Anda menyimpan peta blok bebas independen Anda sendiri untuk setiap subvolume, maka prosedur untuk memeriksa volume logis dapat diparalelkan secara efektif. Dengan kata lain, volume logis dengan manajer tingkat tinggi berskala lebih baik.
Selain itu, dengan pengelola volume tingkat rendah Anda tidak akan dapat mengatur snapshot lengkap. Dengan sistem file mirip LVM dan ZFS, Anda hanya dapat mengambil snapshot lokal, namun tidak dapat mengambil snapshot global. Snapshot lokal memungkinkan Anda untuk langsung memutar kembali operasi file biasa saja. Dan tidak ada seorang pun di sana yang akan mengembalikan operasi dengan volume logis (menambah/menghapus perangkat). Mari kita lihat ini dengan sebuah contoh. Pada suatu saat, ketika Anda memiliki volume logis dari dua perangkat A dan B yang berisi 100 file, Anda mengambil snapshot dari sistem S dan kemudian membuat seratus file lainnya.
Setelah itu, Anda menambahkan perangkat C ke volume Anda, dan terakhir melakukan rollback sistem Anda ke snapshot S. Pertanyaan: Berapa banyak file dan perangkat yang terdapat dalam volume logis Anda setelah rollback ke S? Akan ada 100 file, seperti yang sudah Anda duga, tetapi akan ada 3 perangkat - ini adalah perangkat A, B, dan C yang sama, meskipun pada saat snapshot dibuat, hanya ada dua perangkat di sistem (A dan B ). Operasi penambahan perangkat C tidak dibatalkan, dan jika Anda sekarang menghapus perangkat C dari komputer, data Anda akan rusak, jadi sebelum menghapus, Anda harus terlebih dahulu melakukan operasi yang mahal untuk menghapus perangkat dari volume logis penyeimbangan ulang, yang mana akan menyebarkan semua data dari perangkat C ke perangkat A dan B. Namun jika FS Anda mendukung snapshot global, penyeimbangan ulang tersebut tidak diperlukan, dan setelah rollback instan ke S, Anda dapat menghapus perangkat C dengan aman dari komputer.
Jadi, snapshot global bagus karena memungkinkan Anda menghindari penghapusan (penambahan) perangkat yang mahal dari volume logis (ke volume logis) dengan sejumlah besar data (tentu saja, jika Anda ingat untuk "menjepret" sistem Anda di waktu yang tepat). Izinkan saya mengingatkan Anda bahwa membuat snapshot dan mengembalikan sistem file ke dalamnya adalah operasi instan. Pertanyaan yang mungkin timbul: bagaimana mungkin untuk langsung memutar kembali operasi pada volume logis yang memakan waktu tiga hari? Tapi itu mungkin! Asalkan sistem file Anda dirancang dengan benar. Saya mendapat ide tentang "snapshot 3D" tiga tahun lalu, dan tahun lalu saya mematenkan teknik ini.
Hal berikutnya yang harus dipelajari FS lokal dari FS jaringan adalah menyimpan metadata pada perangkat terpisah dengan cara yang sama seperti FS jaringan menyimpannya di mesin terpisah (yang disebut server metadata). Ada aplikasi yang terutama bekerja dengan metadata, dan aplikasi ini dapat dipercepat dengan menempatkan metadata pada perangkat penyimpanan berkinerja tinggi yang mahal. Dengan kombinasi FS+LVM, Anda tidak akan dapat menunjukkan selektivitas seperti itu: LVM tidak mengetahui apa yang ada di blok yang Anda teruskan (data di sana atau metadata).
Anda tidak akan mendapatkan banyak manfaat dari mengimplementasikan LVM tingkat rendah Anda sendiri di FS dibandingkan dengan kombinasi FS+LVM, tetapi yang dapat Anda lakukan dengan baik adalah mengacaukan FS sehingga nantinya menjadi tidak mungkin untuk bekerja dengan kodenya. ZFS dan Btrfs, yang digunakan pada perangkat virtual, merupakan contoh nyata bagaimana pelanggaran lapisan mematikan sistem secara arsitektural. Jadi, mengapa saya melakukan semua ini? Selain itu, tidak perlu menginstal LVM tingkat rendah Anda sendiri di sistem file. Sebaliknya, Anda perlu menggabungkan perangkat ke dalam volume logis pada tingkat tinggi, seperti yang dilakukan beberapa sistem file jaringan dengan mesin yang berbeda (node penyimpanan). Benar, mereka melakukan ini dengan cara yang menjijikkan karena penggunaan algoritma yang buruk.
Contoh algoritma yang benar-benar buruk adalah penerjemah DHT di sistem file GlusterFS dan apa yang disebut peta CRUSH di sistem file Ceph. Tak satu pun algoritma yang saya lihat memuaskan saya dalam hal kesederhanaan dan skalabilitas yang baik. Jadi saya harus mengingat aljabar dan menciptakan semuanya sendiri. Pada tahun 2015, saat bereksperimen dengan bundel fungsi hash, saya menemukan dan mematenkan sesuatu yang cocok untuk saya. Sekarang saya dapat mengatakan bahwa upaya untuk menerapkan semua ini berhasil. Saya tidak melihat adanya masalah dengan skalabilitas dalam pendekatan baru ini.
Ya, setiap subvolume memerlukan struktur terpisah seperti superblock di memori. Apakah ini sangat menakutkan? Secara umum, saya tidak tahu siapa yang akan “mendidih lautan” dan membuat volume logis ratusan ribu atau lebih perangkat di satu mesin lokal. Jika ada yang bisa menjelaskan hal ini kepada saya, saya akan sangat berterima kasih. Sementara itu, bagi saya ini adalah omong kosong pemasaran.
Bagaimana perubahan pada subsistem perangkat blok kernel (misalnya, tampilan blk-mq) memengaruhi persyaratan implementasi FS?
Mereka tidak memberikan dampak apa pun. Saya tidak tahu apa yang akan terjadi pada lapisan blok yang mengharuskan perancangan FS baru. Antarmuka interaksi subsistem ini sangat buruk. Dari sisi pengemudi, FS seharusnya hanya terpengaruh oleh munculnya jenis drive baru, yang lapisan bloknya akan disesuaikan terlebih dahulu, dan kemudian FS (untuk reiser4 ini berarti munculnya plugin baru).
Apakah munculnya jenis media baru (misalnya, SMR, atau SSD yang ada di mana-mana) berarti tantangan baru yang mendasar dalam desain sistem file?
Ya. Dan ini adalah insentif yang normal untuk pengembangan FS. Tantangan bisa berbeda dan sama sekali tidak terduga. Misalnya, saya pernah mendengar tentang drive yang kecepatan operasi I/Onya sangat bergantung pada ukuran data dan offsetnya. Di Linux, di mana ukuran blok FS tidak boleh melebihi ukuran halaman, drive tersebut tidak akan menampilkan kemampuan penuhnya secara default. Namun, jika sistem file Anda dirancang dengan benar, maka ada peluang untuk mendapatkan lebih banyak manfaat darinya.
Berapa banyak orang yang saat ini bekerja dengan kode Reiser4 selain Anda?
Kurang dari yang saya inginkan, namun saya juga tidak mengalami kekurangan sumber daya yang akut. Saya sangat puas dengan laju perkembangan Reiser4. Saya tidak akan “mengendarai kuda” - ini bukan area yang tepat. Di sini, “jika Anda mengemudi dengan lebih pelan, Anda akan terus melaju!” Sistem file modern adalah subsistem kernel yang paling kompleks, keputusan desain yang salah dapat membatalkan pekerjaan manusia selama bertahun-tahun.
Dengan mengajak para relawan untuk melaksanakan sesuatu, saya selalu menjamin bahwa upaya tersebut pasti akan membuahkan hasil yang benar, yang mungkin diperlukan untuk kebutuhan yang serius. Seperti yang Anda pahami, tidak mungkin ada banyak jaminan seperti itu sekaligus. Pada saat yang sama, saya tidak tahan dengan “figur” yang tanpa malu-malu mempromosikan “fitur” perangkat lunak yang jelas-jelas tidak dapat digunakan, menipu ratusan pengguna dan pengembang, dan pada saat yang sama duduk dan tersenyum di pertemuan puncak kernel.
Apakah ada perusahaan yang menyatakan kesediaannya untuk mendukung pengembangan Reiser4?
Ya, ada usulan seperti itu, termasuk. dan dari vendor besar. Tapi untuk ini saya harus pindah ke negara lain. Sayangnya, usia saya sudah tidak lagi 30 tahun, saya tidak bisa melepaskan diri dan pergi seperti itu begitu peluit pertama berbunyi.
Fitur apa yang saat ini hilang dari Reiser4?
Tidak ada fungsi “resize” untuk volume sederhana, serupa dengan yang ditemukan di ReiserFS(v3). Selain itu, operasi file dengan flag DIRECT_IO tidak ada salahnya. Selanjutnya, saya ingin dapat memisahkan volume menjadi “subvolume semantik”, yang tidak memiliki ukuran tetap, dan dapat dipasang sebagai volume independen. Soal-soal ini bagus untuk pemula yang ingin mencoba “masalah nyata”.
Dan terakhir, saya ingin memiliki volume logis jaringan dengan implementasi dan administrasi yang sederhana (algoritma modern sudah mengizinkan hal ini). Namun yang pasti tidak akan pernah dimiliki Reiser4 adalah RAID-Z, scrub, cache ruang kosong, variabel 128-bit, dan omong kosong pemasaran lainnya yang muncul dengan latar belakang kurangnya ide di antara pengembang beberapa sistem file.
Bisakah semua yang diperlukan diimplementasikan oleh plugin?
Jika kita hanya berbicara tentang antarmuka dan plugin (modul) yang mengimplementasikannya, maka tidak semuanya. Tetapi jika Anda juga memperkenalkan hubungan pada antarmuka ini, antara lain, Anda akan memiliki konsep polimorfisme yang lebih tinggi, yang sudah dapat Anda atasi. Bayangkan Anda secara hipotetis membekukan sistem runtime berorientasi objek, mengubah nilai penunjuk instruksi untuk menunjuk ke plugin lain yang mengimplementasikan antarmuka X yang sama, dan kemudian mencairkan sistem agar terus dijalankan.
Jika pengguna akhir tidak melihat “substitusi” seperti itu, maka kita katakan bahwa sistem tersebut memiliki polimorfisme orde nol di antarmuka X (atau sistem tersebut heterogen di antarmuka X, yang merupakan hal yang sama). Jika sekarang Anda tidak hanya memiliki sekumpulan antarmuka, tetapi juga memiliki hubungan di dalamnya (grafik antarmuka), maka Anda dapat memperkenalkan polimorfisme tingkat tinggi, yang akan mencirikan heterogenitas sistem yang sudah berada di "lingkungan" antarmuka mana pun. Saya memperkenalkan klasifikasi seperti itu sejak lama, tetapi sayangnya, hal itu tidak pernah terjadi.
Jadi, dengan bantuan plugin dan polimorfisme yang lebih tinggi, Anda dapat mendeskripsikan fitur apa pun yang diketahui, serta "memprediksi" fitur yang bahkan belum pernah disebutkan. Saya belum bisa membuktikannya secara tegas, tapi saya juga belum tahu contoh tandingannya. Secara umum, pertanyaan ini mengingatkan saya pada “Program Erlangen” Felix Klein. Pada suatu waktu ia mencoba untuk mewakili semua geometri sebagai cabang aljabar (khususnya, teori grup).
Sekarang ke pertanyaan utama - bagaimana dengan promosi Reiser4 ke inti utama? Apakah ada publikasi tentang arsitektur sistem file ini yang Anda bicarakan pada wawancara terakhir? Seberapa relevan pertanyaan ini dari sudut pandang Anda?
Secara umum, kami sudah meminta untuk dimasukkan ke dalam cabang utama selama tiga tahun. Komentar terakhir Reiser di thread publik tempat permintaan penarikan dibuat tetap tidak terjawab. Jadi semua pertanyaan lebih lanjut bukan untuk kami. Saya pribadi tidak mengerti mengapa kita perlu “menggabungkan” ke dalam sistem operasi tertentu. Di Linux, cahayanya tidak menyatu seperti irisan. Jadi, ada repositori terpisah di mana akan ada beberapa port cabang untuk OS yang berbeda. Siapa pun yang membutuhkannya dapat mengkloning port yang sesuai dan melakukan apa pun yang Anda inginkan dengannya (tentu saja dalam lisensi). Nah, jika seseorang tidak membutuhkannya, itu bukan masalah saya. Pada titik ini, saya mengusulkan untuk mempertimbangkan pertanyaan tentang "promosi ke kernel Linux utama" sebagai hal yang sudah diselesaikan.
Publikasi tentang arsitektur FS memang relevan, tetapi sejauh ini saya hanya punya waktu untuk hasil baru saya, yang saya anggap sebagai prioritas lebih tinggi. Hal lainnya adalah saya seorang ahli matematika, dan dalam matematika, publikasi apa pun adalah ringkasan teorema dan pembuktiannya. Menerbitkan apa pun di sana tanpa bukti adalah pertanda tidak enak. Jika saya benar-benar membuktikan atau menyangkal pernyataan apa pun tentang arsitektur FS, maka hasilnya akan sangat bertumpuk sehingga akan cukup sulit untuk dilewati. Siapa yang membutuhkannya? Ini mungkin alasan mengapa semuanya tetap dalam bentuk lamanya - kode sumber dan komentarnya.
Apa yang baru di Reiser4 selama beberapa tahun terakhir?
Stabilitas yang telah lama dinanti akhirnya terwujud. Salah satu yang terakhir muncul adalah bug yang menyebabkan direktori “tidak dapat dihapus”. Kesulitannya adalah bahwa itu hanya muncul dengan latar belakang tabrakan nama hash dan dengan lokasi tertentu dari catatan direktori di simpul pohon. Namun, saya masih tidak dapat merekomendasikan Reiser4 untuk produksi: untuk ini Anda perlu melakukan beberapa pekerjaan dengan interaksi aktif dengan administrator sistem produksi.
Kami akhirnya berhasil menerapkan ide lama kami - model transaksi yang berbeda. Sebelumnya, Reiser4 hanya menjalankan satu model Macdonald-Reiser yang di-hardcode. Hal ini menimbulkan masalah desain. Secara khusus, snapshot tidak mungkin dilakukan dalam model transaksional seperti itu - snapshot akan dirusak oleh komponen atom yang disebut “OVERWRITE SET”. Reiser4 saat ini mendukung tiga model transaksi. Di salah satunya (Write-Anywhere), komponen atom OVERWRITE SET hanya mencakup halaman sistem (gambar bitmap disk, dll.), yang tidak dapat "difoto" (masalah ayam dan telur).
Jadi gambar-gambar itu sekarang dapat diwujudkan dengan cara terbaik. Dalam model transaksional lainnya, semua halaman yang dimodifikasi hanya masuk ke OVERWRITE SET (yaitu, pada dasarnya adalah penjurnalan murni). Model ini diperuntukkan bagi mereka yang mengeluhkan fragmentasi partisi Reiser4 yang cepat. Sekarang dalam model ini partisi Anda akan terfragmentasi tidak lebih cepat dibandingkan dengan ReiserFS (v3). Ketiga model yang ada, dengan beberapa syarat, menjamin atomisitas operasi, namun model dengan hilangnya atomisitas dan hanya menjaga integritas bagian juga dapat berguna. Model seperti itu dapat berguna untuk semua jenis aplikasi (database, dll.), yang telah mengambil beberapa fungsi ini. Sangat mudah untuk menambahkan model ini ke Reiser4, tetapi saya tidak melakukannya, karena tidak ada yang bertanya kepada saya, dan saya pribadi tidak membutuhkannya.
Checksum metadata muncul dan saya baru-baru ini melengkapinya dengan cermin "ekonomis" (bahan yang masih tidak stabil). Jika checksum blok mana pun gagal, Reiser4 segera membaca blok terkait dari perangkat replika. Perhatikan bahwa ZFS dan Btrfs tidak dapat melakukan ini: desainnya tidak mengizinkannya. Di sana Anda harus menjalankan proses pemindaian latar belakang khusus yang disebut “scrub” dan menunggu hingga mencapai blok yang bermasalah. Para pemrogram secara kiasan menyebut kejadian seperti itu sebagai “kruk”.
Dan akhirnya, volume logis heterogen telah muncul, menawarkan segala sesuatu yang pada prinsipnya tidak dapat disediakan oleh ZFS, Btrfs, lapisan blok, serta kombinasi FS+LVM - penskalaan paralel, pengalokasi alamat disk O(1), migrasi data transparan antar subvolume. Yang terakhir ini juga memiliki antarmuka pengguna. Sekarang Anda dapat dengan mudah memindahkan data terpanas ke drive dengan performa tertinggi di volume Anda.
Selain itu, dimungkinkan untuk segera membuang halaman kotor ke drive tersebut, sehingga secara signifikan mempercepat aplikasi yang sering memanggil fsync(2). Saya perhatikan bahwa fungsionalitas lapisan blok, yang disebut bcache, tidak memberikan kebebasan bertindak sama sekali. Volume logis baru didasarkan pada algoritma saya (ada paten yang sesuai). Softwarenya sudah cukup stabil, sangat memungkinkan untuk dicoba, diukur performanya, dll. Satu-satunya ketidaknyamanan adalah untuk saat ini Anda perlu memperbarui konfigurasi volume secara manual dan menyimpannya di suatu tempat.
Sejauh ini saya telah mampu mengimplementasikan ide-ide saya sebesar 10 persen, namun saya telah berhasil dalam apa yang saya anggap sebagai hal tersulit - menghubungkan volume logis dengan prosedur flash yang melakukan semua tindakan yang ditangguhkan di reiser4. Ini semua masih dalam cabang eksperimental “format41”.
Apakah Reiser4 lulus xfstests?
Setidaknya hal itu terjadi pada saya ketika saya sedang mempersiapkan rilis terakhir.
Apakah pada prinsipnya mungkin menjadikan Reiser4 sebagai jaringan (cluster) FS menggunakan plugin?
Itu mungkin, dan bahkan perlu! Jika Anda membuat file jaringan berdasarkan sistem file lokal yang dirancang dengan baik, hasilnya akan sangat mengesankan! Dalam FS jaringan modern, saya tidak puas dengan kehadiran tingkat penyimpanan backend, yang diimplementasikan menggunakan FS lokal mana pun. Keberadaan level ini sama sekali tidak bisa dibenarkan. FS jaringan harus berinteraksi langsung dengan lapisan blok, dan tidak meminta FS lokal untuk membuat file layanan lainnya!
Secara umum, membagi sistem file menjadi lokal dan jaringan adalah tindakan yang jahat. Hal ini muncul dari ketidaksempurnaan algoritma yang digunakan tiga puluh tahun yang lalu, dan belum ada yang diusulkan sebagai penggantinya. Ini juga merupakan alasan munculnya banyak komponen perangkat lunak yang tidak diperlukan (berbagai layanan, dll.). Dalam cara yang baik, seharusnya hanya ada satu FS dalam bentuk modul kernel dan satu set utilitas pengguna yang diinstal pada setiap mesin - sebuah node cluster. FS ini bersifat lokal dan jaringan. Dan tidak ada lagi!
Jika tidak ada yang berhasil dengan Reiser4 di Linux, saya ingin menawarkan FS untuk FreeBSD (kutipan dari wawancara sebelumnya: “...FreeBSD... memiliki akar akademis... Dan ini berarti bahwa dengan tingkat kemungkinan yang tinggi kita akan menemukan bahasa yang sama dengan pengembang”)?
Jadi, seperti yang baru kami ketahui, semuanya telah berjalan sempurna dengan Linux: ada port Reiser4 terpisah yang berfungsi untuknya dalam bentuk cabang master dari repositori kami. Saya belum melupakan FreeBSD! Menawarkan! Saya siap bekerja sama dengan mereka yang mengetahui seluk-beluk FreeBSD dengan baik. Omong-omong: yang sangat saya sukai dari komunitas mereka adalah bahwa keputusan di sana dibuat oleh dewan ahli independen yang diperbarui, yang tidak ada hubungannya dengan penipuan pemerintah terhadap satu orang tetap.
Bagaimana Anda menilai komunitas pengguna Linux saat ini? Apakah ini menjadi lebih “pop”?
Mengingat sifat pekerjaan saya, cukup sulit bagi saya untuk menilai hal ini. Sebagian besar pengguna datang kepada saya dengan laporan bug dan permintaan untuk memperbaiki bagian tersebut. Pengguna sebagai pengguna. Ada yang lebih paham, ada pula yang kurang. Setiap orang diperlakukan sama. Nah, jika pengguna mengabaikan instruksi saya, maka permisi: perintah abaikan juga akan dimasukkan dari pihak saya.
Apakah mungkin untuk memprediksi perkembangan sistem file untuk lima sampai sepuluh tahun ke depan? Menurut Anda apa tantangan utama yang mungkin dihadapi pengembang FS?
Ya, membuat ramalan seperti itu tidaklah sulit. Sudah lama tidak ada pengembangan sistem file di hulu. Hanya penampilan seperti itu yang tercipta. Pengembang sistem file lokal mengalami masalah yang terkait dengan desain yang buruk. Peringatan perlu dibuat di sini. Saya tidak menganggap apa yang disebut "penyimpanan", "menjilati" dan mem-porting kode sebagai pengembangan dan pengembangan. Dan saya tidak mengklasifikasikan kesalahpahaman yang disebut “Btrfs” sebagai perkembangan karena alasan yang sudah saya jelaskan.
Setiap tambalan hanya memperburuk masalahnya. Dengan baik. dan selalu ada berbagai macam “penginjil” yang menganggap “semuanya berhasil”. Pada dasarnya mereka adalah anak-anak sekolah dan mahasiswa yang membolos perkuliahan. Bayangkan saja: hal itu berhasil untuknya, tetapi profesornya tidak. Sungguh memacu adrenalin! Dari sudut pandang saya, kerugian terbesar disebabkan oleh "pengrajin" yang dengan antusias "mengikat" fitur-fitur luar biasa dari Btrfs ke semua jenis lapisan seperti systemd, docker, dll. - ini sudah menyerupai metastasis.
Sekarang mari kita coba membuat ramalan untuk lima sampai sepuluh tahun. Saya sudah membuat daftar singkat apa yang akan kita lakukan di Reiser4. Tantangan utama bagi pengembang FS lokal dari hulu adalah (ya, sudah menjadi) ketidakmampuan untuk melakukan pekerjaan yang layak untuk mendapatkan gaji. Tanpa ide apa pun di bidang penyimpanan data, mereka akan terus mencoba menambal VFS, XFS, dan ext4 yang malang ini. Situasi dengan VFS terlihat sangat lucu dengan latar belakang ini, mengingatkan pada hiruk pikuk modernisasi sebuah restoran di mana tidak ada koki, dan tidak ada koki yang diharapkan.
Sekarang kode VFS, tanpa syarat apa pun, mengunci beberapa halaman memori secara bersamaan dan mengundang FS yang mendasarinya untuk mengoperasikannya. Ini diperkenalkan untuk meningkatkan kinerja Ext4 pada operasi penghapusan, namun mudah dipahami, penguncian bersamaan seperti itu sepenuhnya tidak kompatibel dengan model transaksi tingkat lanjut. Artinya, Anda tidak akan bisa begitu saja menambahkan dukungan untuk beberapa sistem file pintar di kernel. Saya tidak tahu bagaimana situasinya di area lain Linux, tetapi sejauh menyangkut sistem file, pengembangan apa pun di sini kemungkinan besar tidak akan kompatibel dengan kebijakan yang diterapkan oleh Torvalds dalam praktiknya (proyek akademis dikeluarkan, dan penipu yang tidak tahu apa itu pohon B, kredit kepercayaan tanpa akhir dikeluarkan). Oleh karena itu, kursus ditetapkan untuk pembusukan yang lambat. Tentu saja, mereka akan berusaha sekuat tenaga untuk menganggapnya sebagai “pembangunan”.
Selanjutnya, “penjaga” sistem file, menyadari bahwa Anda tidak dapat memperoleh banyak keuntungan dari “penyimpanan” saja, akan mencoba bisnis yang lebih menguntungkan. Biasanya, ini adalah sistem file terdistribusi dan virtualisasi. Mungkin mereka akan memindahkan ZFS yang modis ke tempat lain yang belum ada. Tapi, seperti semua FS dari hulu, menyerupai pohon Tahun Baru: jika Anda bisa menggantungkan beberapa benda kecil lainnya di atasnya, maka Anda tidak bisa masuk lebih dalam. Saya akui bahwa membangun sistem perusahaan yang serius berdasarkan ZFS adalah mungkin, tetapi karena kita sekarang sedang mendiskusikan masa depan, dengan sedih saya hanya dapat menyatakan bahwa ZFS tidak ada harapan dalam hal ini: dengan perangkat virtual mereka, orang-orang telah memutus pasokan oksigen. bagi diri mereka sendiri dan generasi mendatang untuk pengembangan lebih lanjut. ZFS sudah ketinggalan zaman. Dan ext4 dan XFS bahkan belum ada kemarin lusa.
Perlu disebutkan secara terpisah tentang konsep sensasional "sistem file Linux generasi berikutnya". Ini adalah proyek yang sepenuhnya politis dan pemasaran yang diciptakan untuk mendapatkan peluang, bisa dikatakan, untuk “menyematkan masa depan sistem file” di Linux di balik karakter tertentu. Faktanya adalah Linux dulunya “hanya untuk bersenang-senang”. Tapi sekarang ini pada dasarnya adalah mesin penghasil uang. Mereka dibuat semaksimal mungkin. Misalnya, sangat sulit untuk membuat produk perangkat lunak yang bagus, tetapi “pengembang” yang cerdas telah lama menyadari bahwa tidak perlu bersusah payah sama sekali: Anda dapat berhasil menjual perangkat lunak yang tidak ada yang diumumkan dan dipromosikan di semua jenis masyarakat. acara - yang utama adalah slide presentasi harus berisi lebih banyak "fitur".
Sistem file sempurna untuk ini, karena Anda dapat dengan aman menawar hasilnya selama sepuluh tahun. Nah, jika seseorang kemudian mengeluh tentang kurangnya hasil ini, maka dia tidak mengerti apa pun tentang sistem file! Hal ini mengingatkan kita pada piramida finansial: di puncak adalah para petualang yang memulai kekacauan ini, dan segelintir orang yang “beruntung”: mereka “menarik dividen”, yaitu. menerima uang untuk pengembangan, mendapat pekerjaan bergaji tinggi sebagai manajer, “muncul” di konferensi, dll.
Berikutnya adalah mereka yang “tidak beruntung”: mereka akan menghitung kerugian, menghadapi konsekuensi dari penerapan produk perangkat lunak yang tidak dapat digunakan ke dalam produksi, “dll. Masih banyak lagi dari mereka. Nah, di dasar piramida ada banyak sekali pengembang yang “menggergaji” kode yang tidak berguna. Merekalah yang paling merugi, karena waktu yang terbuang tidak dapat dikembalikan. Piramida seperti itu sangat bermanfaat bagi Torvalds dan rekan-rekannya. Dan semakin banyak piramida ini, semakin baik bagi mereka. Untuk memberi makan piramida seperti itu, apa pun bisa dimasukkan ke dalam intinya. Tentu saja di depan umum mereka mengatakan sebaliknya. Tapi saya menilai bukan dari kata-kata, tapi dari tindakan.
Jadi, “masa depan sistem file di Linux” adalah satu lagi perangkat lunak yang sangat dipromosikan, namun sulit digunakan. Setelah Btrfs, dengan kemungkinan besar, tempat "masa depan" seperti itu akan diambil oleh Bcachefs, yang merupakan upaya lain untuk melintasi lapisan blok Linux dengan sistem file (contoh buruknya menular). Dan yang khas: ada masalah yang sama seperti di Btrfs. Saya sudah lama mencurigai hal ini, dan entah bagaimana saya tidak dapat menahan diri dan melihat kodenya - itu benar!
Penulis Bcachefs dan Btrfs, saat membuat FS mereka, secara aktif menggunakan sumber orang lain, hanya memiliki sedikit pemahaman tentangnya. Situasi ini sangat mengingatkan pada permainan anak-anak “ponsel rusak”. Dan secara kasar saya bisa membayangkan bagaimana kode ini akan dimasukkan ke dalam kernel. Sebenarnya, tidak ada yang akan melihat “garu” (semua orang akan menginjaknya nanti). Setelah banyak perdebatan tentang gaya kode, tuduhan pelanggaran yang tidak ada, dll., sebuah kesimpulan akan dibuat tentang "kesetiaan" penulis, seberapa baik dia "berinteraksi" dengan pengembang lain, dan seberapa sukses semua ini dapat dilakukan. kemudian dijual ke korporasi.
Hasil akhirnya tidak akan menarik minat siapa pun. Dua puluh tahun yang lalu, mungkin saya tertarik, namun sekarang pertanyaannya berbeda: apakah mungkin untuk mempromosikan hal ini sehingga orang-orang tertentu akan dipekerjakan dalam sepuluh tahun ke depan. Dan sayangnya, tidak lazim untuk bertanya-tanya tentang hasil akhirnya.
Secara umum, saya sangat menyarankan untuk tidak mulai menemukan kembali sistem file Anda dari awal. Karena investasi finansial yang signifikan sekalipun tidak akan cukup untuk mendapatkan sesuatu yang kompetitif dalam sepuluh tahun. Tentu saja, saya sedang berbicara tentang proyek-proyek serius, dan bukan tentang proyek-proyek yang dimaksudkan untuk “didorong” ke dalam kernel. Jadi, cara yang lebih efektif untuk mengekspresikan diri adalah dengan mengikuti perkembangan nyata, seperti kami. Hal ini, tentu saja, tidak mudah untuk dilakukan - tetapi hal ini berlaku pada proyek tingkat tinggi mana pun.
Pertama, Anda perlu mengatasi sendiri masalah yang akan saya usulkan. Setelah itu, karena yakin akan keseriusan niat Anda, saya akan mulai membantu. Secara tradisional, kami hanya menggunakan pengembangan kami sendiri. Pengecualian adalah algoritma kompresi dan beberapa fungsi hash. Kami tidak mengirim pengembang untuk melakukan perjalanan ke konferensi, dan kemudian kami tidak duduk dan menggabungkan ide-ide orang lain (“mungkin apa yang akan terjadi”), seperti yang biasa dilakukan di sebagian besar startup.
Kami mengembangkan sendiri semua algoritma. Saat ini saya tertarik pada aspek aljabar dan kombinatorial dari ilmu penyimpanan data. Khususnya bidang berhingga, asimtotik, bukti pertidaksamaan. Ada juga pekerjaan untuk programmer biasa, tapi saya harus segera memperingatkan Anda: semua saran untuk "melihat FS lain dan melakukan hal yang sama" diabaikan. Patch yang ditujukan untuk integrasi lebih dekat dengan Linux melalui VFS juga akan disertakan di sana.
Jadi, kami tidak punya menyapu, tapi kami punya pemahaman ke mana kami harus bergerak, dan kami punya keyakinan bahwa arah ini adalah arah yang benar. Pemahaman ini tidak datang dalam bentuk manna dari surga. Izinkan saya mengingatkan Anda bahwa kami memiliki 29 tahun pengalaman pengembangan, dua sistem file yang ditulis dari awal. Dan jumlah utilitas pemulihan data yang sama. Dan ini banyak sekali!
Sumber: opennet.ru