Pada musim semi ini, kami telah membahas beberapa topik pengantar, seperti cara memeriksa kecepatan drive Anda dan apa itu RAID . Pada yang kedua dari mereka, kami bahkan berjanji untuk terus mempelajari kinerja berbagai topologi multi-disk di ZFS. Ini adalah sistem file generasi berikutnya yang sedang diterapkan di mana-mana: dari Apple ke Ubuntu .

Nah, hari ini adalah hari terbaik untuk mengenal ZFS, pembaca yang ingin tahu. Perlu diketahui bahwa, menurut penilaian konservatif oleh pengembang OpenZFS Matt Arens, "ini benar-benar rumit."

Tetapi sebelum kita sampai ke angka - dan mereka akan, saya berjanji - untuk semua varian konfigurasi ZFS vosmidiskovoy, Anda perlu berbicara tentang cara melakukan ZFS menyimpan data pada disk.

Zpool, vdev, dan perangkat

Diagram kumpulan lengkap ini mencakup tiga vdev tambahan, satu untuk setiap kelas, dan empat untuk RAIDz2.

Biasanya tidak ada alasan untuk membuat kumpulan jenis dan ukuran vdev yang tidak pantas - tetapi jika Anda mau, tidak ada yang menghalangi Anda untuk melakukan ini.

Untuk benar-benar memahami sistem file ZFS , Anda perlu hati-hati melihat struktur yang sebenarnya. Pertama, ZFS menggabungkan level tradisional manajemen volume dan sistem file. Kedua, ia menggunakan mekanisme salinan transaksional saat menulis. Fitur-fitur ini berarti bahwa sistem secara struktural sangat berbeda dari sistem file biasa dan array RAID. Set pertama blok bangunan dasar untuk dipahami: kumpulan penyimpanan (zpool), perangkat virtual (vdev), dan perangkat nyata (perangkat).

zpool

Kolam penyimpanan zpool adalah struktur ZFS teratas. Setiap kumpulan berisi satu atau lebih perangkat virtual. Pada gilirannya, masing-masing berisi satu atau lebih perangkat nyata (perangkat). Kolam virtual adalah blok otonom. Satu komputer fisik dapat berisi dua atau lebih kumpulan yang terpisah, tetapi masing-masingnya sepenuhnya independen dari yang lain. Pools tidak dapat berbagi perangkat virtual.

Redundansi ZFS ada di level perangkat virtual, tetapi tidak di level pool. Pada level pool, sama sekali tidak ada redundansi - jika ada drive vdev atau vdev khusus hilang, maka seluruh pool hilang bersamaan dengannya.

Kumpulan penyimpanan modern dapat bertahan dari kehilangan cache atau log perangkat virtual - meskipun mereka dapat kehilangan sejumlah kecil data kotor jika kehilangan log vdev selama pemadaman listrik atau kerusakan sistem.

Ada kesalahpahaman umum bahwa "pita data" (strip) ZFS direkam di seluruh kumpulan. Ini tidak benar. Zpool sama sekali bukan RAID0 yang menyenangkan, ini adalah JBOD yang menyenangkan dengan mekanisme distribusi yang kompleks dan dapat diubah.

Sebagian besar, entri didistribusikan di antara perangkat virtual yang tersedia sesuai dengan ruang yang tersedia, sehingga secara teoritis semuanya akan terisi secara bersamaan. Dalam versi ZFS yang lebih baru, penggunaan saat ini (pemanfaatan) vdev diperhitungkan - jika satu perangkat virtual secara signifikan lebih dimuat daripada yang lain (misalnya, karena beban baca), itu akan sementara dilewati untuk ditulis, meskipun terdapat koefisien ruang bebas tertinggi.

Mekanisme deteksi daur ulang yang dibangun ke dalam metode distribusi catatan ZFS modern dapat mengurangi latensi dan meningkatkan throughput selama periode beban tinggi yang tidak biasa - tetapi ini bukan carte blanchetanpa campur tangan mencampur HDD lambat dan SSD cepat dalam satu kelompok. Kumpulan yang tidak sama seperti itu masih akan bekerja pada kecepatan perangkat paling lambat, yaitu seolah-olah seluruhnya terdiri dari perangkat tersebut.

vdev

Setiap kumpulan penyimpanan terdiri dari satu atau lebih perangkat virtual (perangkat virtual, vdev). Pada gilirannya, setiap vdev mencakup satu atau lebih perangkat nyata. Sebagian besar perangkat virtual digunakan untuk menyimpan data dengan mudah, tetapi ada beberapa kelas vdev pembantu, termasuk CACHE, LOG, dan SPECIAL. Masing-masing tipe vdev ini dapat memiliki satu dari lima topologi: perangkat tunggal, RAIDz1, RAIDz2, RAIDz3, atau mirror.

RAIDz1, RAIDz2, dan RAIDz3 adalah variasi khusus dari apa yang orang tua sebut dengan RAID ganda (diagonal) paritas. 1, 2, dan 3 merujuk pada berapa banyak blok paritas yang dialokasikan untuk setiap pita data. Alih-alih memisahkan disk untuk paritas, perangkat RAIDz virtual mendistribusikan paritas ini secara merata di seluruh disk. Array RAIDz dapat kehilangan banyak disk karena memiliki blok paritas; jika dia kehilangan yang lain, dia akan gagal dan mengambil kolam penyimpanan dengannya.

Di perangkat virtual cermin (mirror vdev), setiap blok disimpan di setiap perangkat di vdev. Meskipun cermin dua-lebar yang paling umum, bisa ada jumlah perangkat yang sewenang-wenang di cermin - dalam instalasi besar, tiga yang sering digunakan untuk meningkatkan kinerja membaca dan toleransi kesalahan. Cermin vdev dapat bertahan dari kegagalan sementara setidaknya satu perangkat di vdev terus berfungsi.

Vdev tunggal pada dasarnya berbahaya. Perangkat virtual semacam itu tidak akan selamat dari kegagalan tunggal - dan jika digunakan sebagai penyimpanan atau vdev khusus, maka kegagalannya akan menyebabkan penghancuran seluruh kumpulan. Berhati-hatilah di sini.

Peralatan virtual CACHE, LOG, dan SPECIAL dapat dibuat menggunakan salah satu dari topologi yang tercantum di atas - tetapi ingat bahwa kehilangan alat virtual SPECIAL berarti kehilangan kumpulan, sehingga topologi yang berlebihan sangat disarankan.

alat

Ini mungkin istilah termudah untuk dipahami dalam ZFS - ini secara harfiah adalah perangkat akses blok acak. Ingatlah bahwa perangkat virtual terdiri dari perangkat individual, dan kumpulan ini terdiri dari perangkat virtual.

Disk - magnetic atau solid-state - adalah perangkat blok paling umum yang digunakan sebagai blok bangunan vdev. Namun, perangkat apa pun dengan pegangan di / dev cocok - sehingga Anda dapat menggunakan seluruh array RAID perangkat keras sebagai perangkat terpisah.

File mentah sederhana adalah salah satu perangkat blok alternatif terpenting yang dapat dibangun dari vdev. Tes kolam dari file jarang - Cara yang sangat mudah untuk memeriksa perintah kumpulan dan melihat berapa banyak ruang yang tersedia di kumpulan atau perangkat virtual dari topologi ini.

Anda dapat membuat kumpulan uji dari file jarang hanya dalam beberapa detik - tetapi jangan lupa untuk menghapus seluruh kumpulan dan komponen-komponennya nanti.

Misalkan Anda ingin meletakkan server pada delapan disk dan berencana untuk menggunakan disk 10 TB (~ 9300 GiB) - tetapi Anda tidak yakin yang mana Topologi paling sesuai dengan kebutuhan Anda. Dalam contoh di atas, dalam hitungan detik kami membangun kumpulan uji dari file jarang - dan sekarang kita tahu bahwa RAIDz2 vdev dari delapan drive 10 TB menyediakan 50 TiB kapasitas yang berguna.

Kelas khusus perangkat lain adalah SPARE (cadangan). Perangkat hot-swappable, tidak seperti perangkat konvensional, milik seluruh kumpulan, bukan hanya satu perangkat virtual. Jika beberapa vdev di pool gagal, dan perangkat cadangan terhubung ke pool dan tersedia, maka secara otomatis akan bergabung dengan vdev yang terpengaruh.

Setelah tersambung ke vdev yang terpengaruh, perangkat cadangan mulai menerima salinan atau rekonstruksi data yang seharusnya ada di perangkat yang hilang. Dalam RAID tradisional, ini disebut pembangunan kembali, sedangkan di ZFS disebut "resilvering".

Penting untuk dicatat bahwa perangkat pengganti tidak secara permanen menggantikan perangkat yang gagal. Ini hanya pengganti sementara untuk mengurangi waktu di mana degradasi vdev diamati. Setelah administrator mengganti perangkat vdev yang gagal, redundansi dikembalikan ke perangkat permanen ini, dan SPARE terputus dari vdev dan kembali berfungsi sebagai cadangan untuk seluruh kumpulan.

Kumpulan Data, Blok, dan Sektor

Kumpulan blok bangunan berikutnya yang perlu Anda pahami dalam perjalanan kami melalui ZFS bukanlah perangkat keras yang banyak, tetapi bagaimana data disusun dan disimpan. Kami melewati beberapa level di sini - seperti metaslab - agar tidak menumpuk detail sembari mempertahankan pemahaman tentang keseluruhan struktur.

Himpunan data

Saat kami pertama kali membuat dataset, ini menunjukkan semua ruang pool yang tersedia. Kemudian kita mengatur kuota - dan mengubah titik mount. Sihir!

Zvol sebagian besar hanyalah sebuah dataset, tanpa lapisan sistem file-nya, yang kami ganti di sini dengan

sistem file ext4 yang benar-benar normal . ZFS dataset kira-kira sama dengan sistem file yang dipasang standar. Seperti sistem file biasa, sekilas tampaknya "hanya folder lain". Tetapi juga, seperti sistem file yang dipasang secara konvensional, setiap dataset ZFS memiliki set properti dasarnya sendiri.

Pertama-tama, dataset mungkin memiliki kuota yang ditetapkan. Jika diinstalzfs set quota=100G poolname/datasetname, maka Anda tidak dapat menulis ke folder yang terpasang/poolname/datasetnamelebih dari 100 GiB.

Perhatikan ada - dan tidak adanya - garis miring di awal setiap baris? Setiap set data memiliki tempat masing-masing dalam hierarki ZFS dan hierarki mount sistem. Tidak ada garis miring utama dalam hierarki ZFS - Anda mulai dengan nama kumpulan, dan kemudian jalur dari satu kumpulan data ke yang berikutnya. Misalnya, pool/parent/childuntuk dataset yang disebutkan di childbawah dataset induk parentdalam kumpulan dengan nama kreatif pool.

Secara default, mount point dari dataset akan setara dengan namanya dalam hirarki ZFS, dengan garis miring di awal - kolam renang dengan nama ini pooldipasang sebagai /pool, dataset yang parentdipasang pada /pool/parent, dan anak dataset dipasang childdi /pool/parent/child. Namun, titik pemasangan sistem untuk dataset dapat diubah.

Jika kami menunjukkanzfs set mountpoint=/lol pool/parent/child, maka set data pool/parent/childdipasang di sistem sebagai /lol.

Selain dataset, kita harus menyebutkan volume (zvol). Volume kira-kira mirip dengan kumpulan data, kecuali bahwa sebenarnya tidak memiliki sistem file - itu hanya perangkat blok. Anda dapat, misalnya, membuat zvoldengan nama mypool/myzvol, lalu memformatnya dengan sistem file ext4, dan kemudian me-mount sistem file ini - sekarang Anda memiliki sistem file ext4, tetapi dengan dukungan untuk semua fitur keamanan ZFS! Ini mungkin tampak konyol di satu komputer, tetapi jauh lebih masuk akal sebagai backend ketika mengekspor perangkat iSCSI.

Blok

File diwakili oleh satu atau lebih blok. Setiap blok disimpan pada satu perangkat virtual. Ukuran blok biasanya sama dengan parameter recordsize , tetapi dapat dikurangi menjadi 2 ^ ashift jika berisi metadata atau file kecil.

Kami benar- benar tidak bergurau tentang kerusakan kinerja yang sangat besar jika Anda memasang ashift yang terlalu kecil

Di kumpulan ZFS, semua data, termasuk metadata, disimpan dalam blok. Ukuran blok maksimum untuk setiap set data ditentukan dalam propertirecordsize(ukuran rekaman). Ukuran catatan dapat bervariasi, tetapi ini tidak akan mengubah ukuran atau lokasi blok apa pun yang telah ditulis ke dataset - itu hanya valid untuk blok baru seperti yang ditulis.

Kecuali ditentukan lain, ukuran perekaman saat ini adalah 128 KiB secara default. Ini adalah semacam kompromi yang sulit di mana kinerja tidak akan ideal, tetapi tidak buruk dalam banyak kasus. Recordsizedapat diatur ke nilai apa pun dari 4K hingga 1M (dengan pengaturan tambahan recordsizeAnda dapat mengatur lebih banyak lagi, tetapi ini jarang merupakan ide yang bagus).

Blok apa pun merujuk ke data hanya satu file - Anda tidak dapat memeras dua file berbeda menjadi satu blok. Setiap file terdiri dari satu atau lebih blok, tergantung pada ukurannya. Jika ukuran file lebih kecil dari ukuran record, itu akan disimpan dalam blok yang lebih kecil - misalnya, blok dengan file 2 KiB akan menempati hanya satu sektor 4 KiB pada disk.

Jika file cukup besar dan membutuhkan beberapa blok, maka semua catatan dengan file ini akan memiliki ukuranrecordsize - termasuk catatan terakhir, bagian utama yang dapat berubah menjadi ruang yang tidak digunakan .

Volume Zvol tidak memiliki properti recordsize - sebaliknya mereka memiliki properti yang setara volblocksize.

Sektor

Blok bangunan terakhir yang paling mendasar adalah sektor ini. Ini adalah unit fisik terkecil yang dapat ditulis atau dibaca dari unit dasar. Selama beberapa dekade, sebagian besar disk menggunakan sektor 512-byte. Baru-baru ini, sebagian besar drive dikonfigurasikan untuk 4 sektor KiB, dan di beberapa - terutama SSD - 8 sektor KiB atau bahkan lebih.

ZFS memiliki properti yang memungkinkan Anda untuk mengatur ukuran sektor secara manual. Ini properti ashift. Agak membingungkan bahwa ashift adalah kekuatan dua. Misalnya, ini ashift=9berarti ukuran sektor 2 ^ 9, atau 512 byte.

ZFS meminta sistem operasi untuk informasi terperinci tentang setiap perangkat blok ketika ditambahkan ke vdev baru, dan secara teoritis secara otomatis menyetel ashift dengan benar berdasarkan informasi ini. Sayangnya, banyak disk berbohong tentang ukuran sektor mereka untuk menjaga kompatibilitas dengan Windows XP (yang tidak dapat memahami disk dengan ukuran sektor lainnya).

Ini berarti bahwa administrator ZFS sangat disarankan untuk mengetahui ukuran sektor aktual dari perangkat mereka dan menginstal secara manualashift. Jika terlalu kecil ashift diatur, maka jumlah operasi baca / tulis secara astronomis meningkat. Jadi, menulis "sektor" 512-byte ke sektor 4 KiB nyata berarti menulis "sektor" pertama, kemudian membaca sektor 4 KiB, mengubahnya dengan "sektor" 512-byte kedua, menuliskannya kembali ke sektor 4 KiB yang baru, dan seterusnya untuk setiap entri.

Di dunia nyata, hukuman seperti itu mengalahkan Samsung EVO ashift=13SSD , yang harus ditindaklanjuti , tetapi SSD ini terletak pada ukuran sektornya, dan karenanya diatur secara default ashift=9. Jika administrator sistem yang berpengalaman tidak mengubah pengaturan ini, maka SSD ini lebih lambat daripada HDD magnetik biasa.

Sebagai perbandingan, untuk ukuran yang terlalu besarashifthampir tidak ada penalti. Tidak ada penurunan nyata dalam produktivitas, dan peningkatan ruang yang tidak digunakan sangat kecil (atau sama dengan nol dengan kompresi diaktifkan). Oleh karena itu, kami sangat menyarankan agar drive yang benar-benar menggunakan sektor 512-byte diinstal ashift=12atau bahkan ashift=13untuk melihat dengan percaya diri ke masa depan.

Properti ashiftdiatur untuk setiap perangkat virtual vdev, dan bukan untuk pool , karena banyak orang berpikir keliru - dan tidak berubah setelah instalasi. Jika Anda secara tidak sengaja terjatuh ashiftketika menambahkan vdev baru ke kolam, maka Anda mencemari kolam ini dengan perangkat berkinerja rendah dan, sebagai aturan, tidak ada cara lain selain menghancurkan kolam dan memulai dari awal lagi. Bahkan menghapus vdev tidak akan menyelamatkan Anda dari pengaturan yang rusakashift!

— ,

, , « » « »,

, — , ,

Copy on Write (CoW) adalah fondasi dasar dari apa yang membuat ZFS luar biasa. Konsep dasarnya sederhana - jika Anda meminta sistem file tradisional untuk memodifikasi file, itu akan melakukan persis apa yang Anda minta. Jika Anda meminta sistem file dengan menyalin selama perekaman untuk melakukan hal yang sama, itu akan mengatakan "baik" - tetapi itu akan berbohong kepada Anda.

Sebagai gantinya, sistem file salin-tulis menulis versi baru dari blok yang dimodifikasi, dan kemudian memperbarui metadata file untuk memutus koneksi dengan blok lama dan mengaitkan blok baru yang baru saja Anda tulis.

Memutuskan sambungan unit lama dan menghubungkan yang baru dilakukan dalam satu operasi, sehingga tidak dapat terganggu - jika Anda mengatur ulang daya setelah ini terjadi, Anda memiliki versi file yang baru, dan jika Anda mengatur ulang daya lebih awal, maka Anda memiliki versi yang lama. Bagaimanapun, tidak akan ada konflik dalam sistem file.

Menyalin ketika menulis ke ZFS terjadi tidak hanya di level sistem file, tetapi juga di level manajemen disk. Ini berarti bahwa ZFS tidak tunduk pada ruang dalam catatan ( lubang di RAID ) - sebuah fenomena ketika strip hanya berhasil merekam sebagian sebelum sistem crash, dengan array rusak setelah reboot. Di sini strip adalah atom, vdev selalu konsisten, dan Bob adalah pamanmu .

ZIL: ZFS Intent Log

ZFS — , ZIL,

, ZIL, .

SLOG, LOG-, — — , , — vdev, ZIL

ZIL — ZIL SLOG,

Ada dua kategori utama operasi tulis - sinkron (sinkron) dan asinkron (async). Untuk sebagian besar beban kerja, sebagian besar operasi penulisan tidak sinkron - sistem file memungkinkan Anda untuk menggabungkannya dan mengirimkannya dalam batch, mengurangi fragmentasi dan meningkatkan throughput secara signifikan.

Rekaman sinkron adalah hal yang sangat berbeda. Ketika suatu aplikasi meminta penulisan yang sinkron, ia memberi tahu sistem file: "Anda harus melakukan ini pada memori yang tidak mudah menguap sekarang , dan sampai saat itu saya tidak bisa berbuat apa-apa lagi." Oleh karena itu, rekaman sinkron harus segera dilakukan ke disk - dan jika itu meningkatkan fragmentasi atau mengurangi bandwidth, maka jadilah itu.

ZFS memproses catatan sinkron secara berbeda dari sistem file biasa - alih-alih segera mengunggahnya ke penyimpanan biasa, ZFS mencatatnya di area penyimpanan khusus yang disebut log maksud ZFS - ZFS Intent Log, atau ZIL. Kuncinya adalah bahwa catatan-catatan ini juga tetap ada dalam memori, yang dikumpulkan bersama dengan permintaan tulis asinkron biasa, untuk kemudian dibuang ke penyimpanan sebagai TXG yang sangat normal (Grup Transaksi, Grup Transaksi).

Dalam operasi normal, ZIL direkam dan tidak pernah dibaca lagi. Ketika, setelah beberapa saat, rekaman dari ZIL diperbaiki di penyimpanan utama dalam TXG biasa dari RAM, mereka terputus dari ZIL. Satu-satunya hal ketika sesuatu dibaca dari ZIL adalah saat mengimpor kolam.

Jika ZFS lumpuh - sistem operasi mogok atau pemadaman listrik - ketika ada data di ZIL, data ini akan dibaca selama impor kumpulan berikutnya (misalnya, ketika sistem darurat dimulai kembali). Segala sesuatu yang ada di ZIL akan dibaca, digabungkan ke dalam grup TXG, berkomitmen untuk penyimpanan utama, dan kemudian diputuskan dari ZIL selama proses impor.

Salah satu kelas pembantu vdev disebut LOG atau SLOG, perangkat LOG sekunder. Dia memiliki satu tugas - untuk menyediakan kumpulan dengan perangkat vdev yang terpisah dan, lebih disukai, lebih cepat, dengan resistensi yang sangat tinggi, untuk menyimpan ZIL, alih-alih menyimpan ZIL dalam penyimpanan vdev utama. ZIL sendiri berperilaku sama terlepas dari lokasi penyimpanan, tetapi jika vdev dengan LOG memiliki kinerja penulisan yang sangat tinggi, maka penulisan sinkron akan lebih cepat.

Menambahkan vdev dengan LOG ke kumpulan tidak dapat meningkatkan kinerja penulisan asinkron - bahkan jika Anda memaksa semua penulisan ke ZIL dengan zfs set sync=always, mereka masih akan terikat ke repositori utama di TXG dengan cara yang sama dan pada kecepatan yang sama seperti tanpa log. Satu-satunya peningkatan kinerja langsung adalah penundaan dalam perekaman sinkron (karena kecepatan log yang lebih tinggi mempercepat operasi sync).

Namun, dalam lingkungan yang sudah membutuhkan sejumlah besar penulisan sinkron, vdev LOG dapat secara tidak langsung mempercepat penulisan asinkron dan bacaan tanpa-cache. Mengunggah catatan ZIL ke vdev LOG terpisah berarti lebih sedikit kompetisi untuk IOPS di penyimpanan utama, yang pada tingkat tertentu meningkatkan kinerja semua operasi baca dan tulis.

Jepretan

Mekanisme copy copy juga merupakan fondasi penting untuk snapshot ZFS atom dan replikasi asinkron tambahan. Sistem file aktif memiliki pohon penunjuk yang menandai semua catatan dengan data saat ini - ketika Anda mengambil snapshot, Anda cukup membuat salinan pohon penunjuk ini.

Ketika catatan ditimpa dalam sistem file aktif, ZFS pertama menulis versi baru dari blok ke ruang yang tidak terpakai. Itu kemudian melepaskan versi lama dari blok dari sistem file saat ini. Tetapi jika beberapa snapshot mengacu pada blok lama, itu tetap tidak berubah. Blok lama tidak akan benar-benar dikembalikan sebagai ruang kosong sampai semua foto yang tertaut ke blok ini dihancurkan!

Replikasi

Steam 2015 158 126 927 . rsync — ZFS « » 750% .

40- Windows 7 — . ZFS 289 , rsync — «» 161 , , rsync --inplace.

, rsync . 1,9 — , ZFS 1148 , rsync, rsync --inplace

Setelah Anda memahami cara kerja snapshot, mudah untuk memahami inti dari replikasi. Karena snapshot adalah hanya pohon pointer ke catatan, maka jika kita membuat zfs sendsnapshot, maka kita mengirim pohon ini dan semua catatan yang terkait dengannya. Ketika kami melewati ini zfs senddi zfs receiveke objek sasaran, itu menulis baik isi sebenarnya dari blok dan pohon pointer yang referensi blok ke set data sasaran.

Semuanya menjadi lebih menarik di detik zfs send. Sekarang kami memiliki dua sistem, yang masing-masing berisi poolname/datasetname@1, dan Anda mengambil snapshot baru poolname/datasetname@2. Oleh karena itu, di kumpulan sumber yang Anda miliki datasetname@1dan datasetname@2, dan di kumpulan target sejauh ini hanya snapshot pertama datasetname@1.

Karena kita memiliki snapshot umum antara sumber dan targetdatasetname@1, kita bisa melakukan incremental zfs send di atasnya. Saat kami memberi tahu sistem zfs send -i poolname/datasetname@1 poolname/datasetname@2, ia membandingkan dua pohon pointer. Pointer apa pun yang ada hanya di @2, jelas, merujuk ke blok baru - jadi kita perlu isi dari blok ini.

Pada sistem jarak jauh, pemrosesan tambahan sendsama mudahnya. Pertama, kami merekam semua entri baru yang termasuk dalam aliran send, dan kemudian menambahkan pointer ke blok ini. Voila, dalam @2sistem baru kami !

Replikasi incremental asinkron ZFS adalah peningkatan besar dibandingkan metode non-snapshot sebelumnya seperti rsync. Dalam kedua kasus, hanya data yang berubah yang dikirimkan - tetapi rsync harus terlebih dahulu membacadari disk semua data di kedua sisi untuk memeriksa jumlah dan membandingkannya. Sebaliknya, replikasi ZFS hanya membaca pohon pointer - dan semua blok yang tidak terwakili dalam snapshot umum.

Kompresi sebaris

Mekanisme tulis-salin juga menyederhanakan sistem kompresi bawaan. Dalam sistem file tradisional, kompresi bermasalah - baik versi lama dan versi baru dari data yang diubah berada di ruang yang sama.

Jika Anda mempertimbangkan sepotong data di tengah file yang memulai kehidupannya sebagai megabyte nol mulai 0x00000000 dan seterusnya - sangat mudah untuk mengompresnya ke satu sektor pada disk. Tetapi apa yang terjadi jika kita mengganti megabyte nol ini dengan megabyte data yang tidak dapat dikompres seperti JPEG atau pseudo-random noise? Tiba-tiba, megabyte data ini tidak hanya membutuhkan satu, tetapi 256 sektor dengan 4 KiB, dan di tempat ini pada disk hanya satu sektor yang dicadangkan.

ZFS tidak memiliki masalah seperti itu, karena catatan yang diubah selalu ditulis ke ruang yang tidak digunakan - blok asli hanya menempati satu sektor 4 KiB, dan catatan baru akan mengambil 256, tetapi ini bukan masalah - fragmen yang baru saja diubah dari "tengah" file akan ditulis ke ruang yang tidak digunakan terlepas dari apakah ukurannya telah berubah atau tidak, jadi untuk ZFS ini adalah situasi yang normal.

Kompresi ZFS bawaan dinonaktifkan secara default, dan sistem menawarkan algoritma plug-in - sekarang di antaranya adalah LZ4, gzip (1-9), LZJB dan ZLE.

LZ4 adalah algoritma streaming yang menawarkan kompresi dan dekompresi yang sangat cepat dan keuntungan kinerja untuk kebanyakan kasus penggunaan - bahkan pada CPU yang cukup lambat.
GZIP — , Unix-. 1-9, CPU 9. ( ) , c CPU — , .
LZJB — ZFS. , LZ4 .
ZLE - pengodean level nol, Pengodean Tingkat Nol. Itu tidak menyentuh data normal sama sekali, tetapi kompres urutan nol besar. Berguna untuk kumpulan data yang sepenuhnya tidak dapat dimampatkan (misalnya, JPEG, MP4, atau format lain yang sudah dikompresi), karena mengabaikan data yang tidak dapat dimampatkan, tetapi memampatkan ruang yang tidak digunakan dalam catatan yang dihasilkan.

Kami merekomendasikan kompresi LZ4 untuk hampir semua kasus penggunaan; Hukuman kinerja untuk menghadapi data yang mampat sangat kecil, dan kinerja keuntungan untuk data khas adalah signifikan. Menyalin gambar mesin virtual untuk instalasi baru sistem operasi Windows (OS yang baru diinstal, belum ada data di dalamnya) dengan compression=lz4lulus 27% lebih cepat daripada dengan compression=none, dalam tes 2015 ini .

ARC - cache pengganti adaptif

ZFS adalah satu-satunya sistem file modern yang kita ketahui yang menggunakan mekanisme caching baca sendiri, dan tidak mengandalkan cache halaman sistem operasi untuk menyimpan salinan blok yang baru dibaca dalam RAM.

Meskipun cache sendiri bukan tanpa masalah - ZFS tidak dapat menanggapi permintaan alokasi memori baru secepat kernel, sehingga panggilan malloc()alokasi memori baru mungkin gagal jika membutuhkan RAM yang saat ini ditempati oleh ARC. Tetapi ada alasan bagus untuk menggunakan cache Anda sendiri, setidaknya untuk saat ini.

Semua sistem operasi modern yang terkenal, termasuk MacOS, Windows, Linux dan BSD, menggunakan algoritma LRU (Paling Baru Digunakan) untuk mengimplementasikan halaman cache. Ini adalah algoritma primitif yang menaikkan blok cache “naik antrian” setelah setiap pembacaan dan mendorong blok “turun antrian” sebagaimana diperlukan untuk menambahkan kesalahan cache yang baru (blok yang seharusnya dibaca dari disk, bukan dari cache) naik.

Biasanya, algoritme berfungsi dengan baik, tetapi pada sistem dengan dataset kerja yang besar, LRU dengan mudah mengarah ke thrashing - crowding out blok yang sering dibutuhkan untuk memberikan ruang bagi blok yang tidak akan pernah dibaca dari cache lagi.

BUSUR - Algoritma yang jauh lebih naif, yang dapat dianggap sebagai cache "tertimbang". Setelah setiap pembacaan blok yang di-cache, itu menjadi sedikit "lebih berat" dan menjadi lebih sulit untuk keluar - dan bahkan setelah crowding out blok dilacak untuk periode waktu tertentu. Blok yang telah diperas tetapi kemudian perlu dibaca kembali ke cache juga akan menjadi "lebih berat".

Hasil akhir dari semua ini adalah cache dengan hit rasio yang jauh lebih besar - rasio antara hit dalam cache (baca dari cache) dan meleset (baca dari disk). Ini adalah statistik yang sangat penting - tidak hanya cache mengenai pesanan layanan mereka sendiri yang lebih cepat, kesalahan cache juga dapat dilayani lebih cepat, karena semakin banyak cache hit, semakin sedikit permintaan disk secara bersamaan dan semakin sedikit penundaan untuk sisa kesalahan yang harus dilayani dengan mendorong.

Kesimpulan

Setelah mempelajari semantik dasar ZFS - cara menyalin berfungsi saat menulis, serta hubungan antara kumpulan penyimpanan, perangkat virtual, blok, sektor, dan file - kami siap untuk mendiskusikan kinerja nyata dengan angka nyata.

Pada bagian selanjutnya, kita akan melihat kinerja aktual dari pool dengan mirror vdev dan RAIDz, dibandingkan satu sama lain, serta dibandingkan dengan topologi kernel Linux tradisional RAID, yang telah kita periksa sebelumnya .

Pada awalnya kami ingin mempertimbangkan hanya dasar-dasar - topologi ZFS sendiri - tetapi setelah ini kami akan siap untuk berbicara tentang penyetelan dan penyetelan ZFS yang lebih maju, termasuk penggunaan tipe vdev tambahan seperti L2ARC, SLOG dan Alokasi Khusus.

Dasar-Dasar ZFS: Penyimpanan dan Kinerja