Apa arti di balik batas ZFS?


10

Menurut Wikipedia , ZFS memiliki batasan berikut:

  • Maks. ukuran volume : 256 triliun yobibytes (2 128 bytes)
  • Maks. ukuran file : 16 exbibytes (2 64 bytes)
  • Maks. jumlah file :
  • Maks. panjang nama file : 255 karakter ASCII (lebih sedikit untuk pengkodean karakter multibyte seperti Unicode)

Mengapa ia memiliki batasan ini? Apa yang membatasi hal-hal ini secara internal? Mengapa ZFS tidak bisa memiliki ukuran volume yang secara teori tidak terbatas, atau panjang nama file, dan sebagainya?

Jawaban:


27

Apa yang membatasi hal-hal ini secara internal?

Jawaban panjang

Batas ZFS didasarkan pada bilangan bulat ukuran tetap karena itulah cara tercepat untuk melakukan aritmatika di komputer.

Alternatif ini disebut aritmatika presisi arbitrer , tetapi inheren lambat . Inilah sebabnya mengapa aritmatika presisi arbitrer adalah add-on library di sebagian besar bahasa pemrograman, bukan cara standar untuk melakukan aritmatika. Ada pengecualian, tetapi ini biasanya DSL yang berorientasi matematika seperti bcatau Bahasa Wolfram .

Jika Anda ingin aritmatika cepat, Anda menggunakan kata-kata ukuran tetap, titik.

Kecepatan yang dihasilkan dari aritmatika presisi yang sewenang-wenang cukup buruk di dalam RAM komputer, tetapi ketika sebuah sistem file tidak tahu berapa banyak bacaan yang perlu dibuat untuk memuat semua angka yang diperlukan ke dalam RAM, itu akan sangat mahal. Sebuah sistem file yang didasarkan pada bilangan bulat berukuran sewenang-wenang harus menyatukan masing-masing angka dari beberapa blok, yang membutuhkan banyak I / O tambahan dari beberapa hit disk relatif terhadap sistem file yang mengetahui seberapa besar blok metadata-nya.

Sekarang mari kita bahas impor praktis dari masing-masing batas tersebut:

Maks. ukuran volume

2 128 byte sudah tak terbatas secara efektif. Kita dapat menulis angka itu sebagai kira-kira 10 38 byte, yang berarti untuk mencapai batas itu, Anda harus memiliki kumpulan ZFS seukuran Bumi di mana setiap satu dari 10 50 atomnya digunakan untuk menyimpan data, dan masing-masing byte disimpan oleh suatu elemen yang tidak lebih besar dari 10 12 atom.

10 12 atom terdengar sangat banyak, tetapi itu hanya sekitar 47 pikogram silikon .

Kepadatan data dalam gram adalah 2,5 × 10 -13  g / byte untuk penyimpanan microSD, pada saat penulisan ini: kartu SD terbesar yang tersedia adalah 1 TB, dan beratnya sekitar 0,25g.¹ Kartu microSD tidak terbuat dari murni silikon, tetapi Anda tidak dapat mengabaikan kemasannya, karena kami juga membutuhkannya di komputer-Bumi kami; kita akan mengasumsikan bahwa kerapatan plastik yang rendah dan kerapatan pin logam yang lebih tinggi rata-rata sama kerapatannya dengan silikon. Kami juga membutuhkan beberapa slop di sini untuk menjelaskan interkoneksi antar-chip, dll.

Pico- apapun adalah 10 -12 , jadi  nomor 47 pg dan 2.5 × 10 -13 g / B kami di atas adalah tentang urutan besarnya terpisah. Itu berarti bahwa untuk perkiraan pertama, untuk membangun satu kumpulan ZFS berukuran maksimal dari kartu microSD terbesar yang tersedia saat ini, Anda mungkin harus menggunakan atom seukuran planet seukuran Bumi, dan kemudian hanya jika Anda memulai dengan sesuatu yang dekat dengan campuran yang tepat dari silikon, karbon, emas, dll. sehingga Anda tidak berakhir dengan begitu banyak terak yang Anda hancurkan perkiraan.

Jika Anda merasa tidak adil bahwa saya menggunakan penyimpanan flash di sini alih-alih sesuatu yang lebih padat seperti kaset atau disk, pertimbangkan kecepatan data yang terlibat, serta fakta bahwa kami bahkan belum mencoba mempertimbangkan redundansi atau penggantian perangkat. Kita harus mengasumsikan bahwa kumpulan ZFS seukuran Bumi ini akan terdiri dari vdev yang tidak perlu diganti, dan bahwa mereka dapat mentransfer data dengan cukup cepat sehingga Anda dapat mengisi kumpulan tersebut dalam waktu yang wajar. Hanya penyimpanan solid-state yang masuk akal di sini.

Perkiraan di atas cukup kasar, dan kepadatan penyimpanan terus meningkat, tetapi tetap hal-hal dalam perspektif: di masa depan, untuk melakukan aksi ini membangun kolam ZFS berukuran maksimal, kita masih perlu menggunakan total kerak untuk- sumber daya inti dari planet kecil .

Maks. ukuran file

Jadi kita punya sistem file ukuran planet sekarang. Apa yang bisa kita katakan tentang ukuran file yang tersimpan di dalamnya?

Mari kita berikan setiap orang di planet ini potongan yang sama besarnya dari kolam itu:

10 38  ÷ 10 10  ≈ 10 28  ÷ 10 19  ≈ 10 9

Itu ukuran kumpulan dibagi dengan populasi Earth² dibagi dengan ukuran file maksimum, dalam angka bulat.

Dengan kata lain, setiap orang dapat menyimpan sekitar satu miliar file berukuran maksimal dalam irisan kecil pribadi mereka dari array penyimpanan ZFS seukuran Bumi.

(Jika itu mengganggu Anda bahwa array penyimpanan kami masih seukuran planet di sini dalam contoh ini, ingatlah bahwa itu harus sebesar itu untuk mencapai batas pertama di atas, sehingga wajar untuk terus menggunakannya untuk contoh ini sini.)

Ukuran file maksimum per file adalah 16  EiB di bawah ZFS, yang 16x lebih besar dari ukuran volume maksimum ext4 , yang dianggap sangat besar saat ini.

Bayangkan seseorang menggunakan potongan Planet ZFS mereka (sebelumnya dikenal sebagai Earth) untuk menyimpan cadangan gambar disk ext4 berukuran maksimal. Selanjutnya, pelanggan gila ini (selalu ada satu) telah memutuskan untuk tarmenaikkannya, 16 per file, hanya untuk mencapai batas ukuran file maksimum ZFS. Setelah melakukannya, pelanggan itu masih memiliki ruang untuk melakukannya lagi sekitar satu miliar kali.

Jika Anda khawatir tentang batasan ini, itulah jenis masalah yang harus Anda bayangkan perlu diselesaikan. Dan itu bahkan tanpa masuk ke bandwidth data yang diperlukan yang diperlukan untuk mentransfer file itu ke layanan cadangan online sekali .

Mari kita juga menjadi jelas tentang betapa tidak mungkinnya Bumi-komputer itu. Pertama, Anda harus mencari cara untuk membangunnya tanpa membiarkannya runtuh dengan sendirinya di bawah gaya gravitasi dan menjadi cair di pusat. Maka Anda harus mencari cara bagaimana membuatnya menggunakan setiap atom tunggal di Bumi tanpa sisa terak.

Sekarang, karena Anda telah mengubah permukaan bumi-komputer menjadi Hellscape, semua orang yang mencoba memanfaatkan komputer itu harus tinggal di tempat lain, tempat di mana Anda sering mendengar orang mengutuk kecepatan-of- penundaan cahaya yang menambah latensi pada setiap transaksi antara komputer-Bumi dan di mana pun mereka tinggal sekarang. Jika Anda berpikir ~ 10 ms waktu ping Internet Anda adalah masalah hari ini, bayangkan menempatkan 2,6 detik cahaya antara keyboard dan komputer jika kami memindahkan populasi Bumi ke bulan sehingga kami dapat membuat Bumi-komputer ini.

Volume dan ukuran file ZFS adalah fiksi ilmiah yang besar.

Maks. jumlah file per direktori

2 48 kira-kira 10 14 file per direktori, yang hanya akan menjadi masalah bagi aplikasi yang mencoba memperlakukan ZFS sebagai sistem file datar .

Bayangkan seorang peneliti Internet yang menyimpan file tentang setiap alamat IP di Internet. Katakanlah ada tepat 2 32 IP dilacak setelah terlebih dahulu mengurangi ruang kendur di ruang IPv4 lama dan kemudian menambahkan host sekarang menggunakan alamat IPv6 untuk membuat aritmatika keluar bagus. Apa masalah yang peneliti ini coba atasi yang mengharuskannya untuk membangun sistem pengarsipan yang dapat menyimpan lebih dari 2 16 - 65536! - file per IP?

Katakanlah peneliti ini juga menyimpan file per port TCP, sehingga hanya dengan satu file per IP: kombinasi port, kami telah memakan 2 16 pengganda.

Cara mengatasinya sederhana: simpan file per-IP dalam subdirektori bernama IP, dan simpan file per-port dalam subdirektori dari direktori yang menyimpan file per-IP. Sekarang peneliti kami dapat menyimpan 10 14 file per IP: kombinasi port, cukup untuk sistem pemantauan Internet global jangka panjang.

Batas ukuran direktori ZFS bukanlah yang saya sebut "fiksi ilmiah besar," seperti yang kita ketahui tentang aplikasi nyata saat ini yang dapat mencapai batas ini, tetapi kekuatan hierarki berarti Anda bisa menambahkan lapisan direktori lain jika Anda menghadapi membatasi.

Batas ini mungkin ditetapkan serendah ini murni untuk menghindari membuat struktur data yang diperlukan untuk menemukan file dalam direktori yang diberikan terlalu besar untuk masuk ke dalam RAM. Ini mendorong Anda untuk mengatur data Anda secara hierarkis untuk menghindari masalah ini sejak awal.

Maks. panjang nama file

Meskipun batas satu ini memang tampak ketat, sebenarnya masuk akal.

Batas ini tidak berasal dari ZFS. Saya percaya ini tanggal kembali ke FFS di 4.2BSD . Saya tidak dapat menemukan kutipan, tetapi ketika batas ini masih muda, seseorang menunjukkan bahwa ini adalah ruang yang cukup untuk "surat pendek untuk nenek."

Jadi, itu menimbulkan pertanyaan: mengapa Anda perlu memberi nama file Anda lebih deskriptif dari itu? Setiap kebutuhan sebenarnya yang lebih besar dari itu mungkin membutuhkan hierarki, di mana Anda mengalikan batas dengan jumlah level dalam hierarki, ditambah satu. Artinya, jika file tersebut tertanam 3 level dalam hierarki, batas nama path lengkap adalah 4 × 255 = 1020 karakter.

Pada akhirnya, batas ini adalah batas manusia, bukan batas teknologi. Nama file adalah untuk digunakan manusia, dan manusia benar-benar tidak perlu lebih dari 255 karakter untuk menggambarkan konten file. Batas yang lebih tinggi tidak akan membantu. Keterbatasannya sudah lama (1983) karena manusia belum memperoleh kemampuan untuk mengatasi nama file yang lebih lama sejak saat itu.

Jika Anda bertanya dari mana nilai "255" yang tampak aneh itu berasal, itu adalah beberapa batasan berdasarkan ukuran byte 8-bit. 2 8 adalah 256, dan nilai N-1 yang digunakan di sini mungkin berarti mereka menggunakan terminator nol untuk menandai akhir dari string nama file dalam bidang 256-byte dalam metadata per-file.

Jawaban singkat

Secara praktis, apa yang membatasi?


Catatan kaki:

  1. Saya mengukur ini menggunakan skala yang ditentukan dengan akurasi 0,01 g.

  2. 7,55 miliar , pada tulisan ini. Di atas, kita menyelesaikan ini menjadi 10 10 , yang seharusnya kita dapatkan pada pertengahan abad ini .


3
Baca menyenangkan, terima kasih! Jumlah minimum untuk PATH_MAXpada sistem POSIX adalah 256. Ini dapat terdiri dari komponen paling banyak NAME_MAXkarakter masing-masing (nilai ini setidaknya 14).
Kusalananda

2
Jawaban yang sangat bagus Untuk menambah bagian nama file: Nama file panjang sebenarnya mengurangi kegunaan bagi manusia, terutama jika dicampur dengan nama pendek (ukuran layar lebih banyak diperlukan untuk menampilkannya, tata letak akan terpengaruh, riwayat shell akan lebih sulit dibaca dll.), Dan mereka masih kalah dengan sistem penandaan yang fleksibel dan dapat dicari (yang tidak dimiliki ZFS, sayangnya).
user121391

Itu luar biasa, tetapi mengapa mereka melumpuhkan nama file hingga 255 karakter? Ada beberapa kasus penggunaan yang sangat praktis untuk itu, misalnya judul buku atau kertas yang panjang dan bersamaan dengan daftar nama penulis. Dan ada perangkat lunak yang rusak ketika tidak dapat menulis nama file lengkap, misalnya youtube-dlsaat mengunduh video dari kursus semacam itu.
Dan Dascalescu

@DanDascalescu saya membenarkan itu dalam jawaban dan memberikan solusi.
Warren Young

@ WarrenYoung: tidak perlu dibenarkan, karena Anda tidak memaksakan batas. Namun, saya tidak merasa seperti itu, bagian "Max filename length" membahas keberatan saya (dengan contoh judul "course / book / paper"). Saya ingin nama file buku / kursus / video saya mandiri, tidak secara artifisial dipecah menjadi sebuah direktori (misalnya penulis) plus nama file. Lihat nol, satu, aturan tak terhingga dan jalankan pencarian sederhana untuk "nama file terlalu lama" - jendela itu mengungkapkan puluhan juta hasil.
Dan Dascalescu
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.