Peringatan: artikel ini berlaku untuk semua sistem file CoW di Linux yang mendukung reflink saat menyalin. Saat ini, ini adalah: BTRFS, XFS dan OCFS2.
Harap hindari dari holivars tentang FS mana yang lebih baik: Btrfs, XFS, Reiser4, NILFS2, ZFS atau yang tidak disebutkan.Latar belakang
- 21 Juli 2001 - Namesys menerbitkan pengumuman Reiser4 . DARPA mensponsori pengembangan.
- 20 November 2003 - Namesys menerbitkan beberapa tolok ukur Reiser4 .
- 24 Agustus 2004 - Namesys membuat rilis publik Reiser4 .
- 14 September 2004 - Pengumuman ZFS.
- 16 November 2005 - ZFS termasuk dalam OpenSolaris build 27.
- September 2006 - Hans Reiser ditangkap karena membunuh istri, Nina Reiser. Awal dari akhir Namesys
- 12 Juni 2007 - Pengumuman Btrfs oleh Chris Mason (mantan karyawan Namesys).
- 22 September 2011 - Tiket dengan permintaan implementasi reflink telah muncul di ZFSonLinux.
- 2012 - Btrfs diakui sebagai Oracle Linux yang stabil dan SUSE Linux Enterprise
- 21 Januari 2013 - label percobaan telah dihapus dengan Btrfs dalam kode sumber kernel Linux.
- Mei 2019 - Btrf dihapus dari RHEL 8 (alasan politik tersembunyi dicurigai sebagai Btrf dipromosikan oleh Oracle)
Salin Harapan dalam Sistem File Kontrak Karya
Ketika Reiser4 diumumkan pada tahun 2001, saya terinspirasi dan bersemangat tentang Copy-on-Write. Bayangkan saja, kami dapat dengan mudah dan sederhana memiliki banyak salinan proyek yang berbeda seperti yang Anda inginkan, dan secara fisik disk hanya akan menyimpan perbedaan di antara mereka!
Selain itu, kecepatan salin harus tumbuh tidak senonoh. Karena kenyataan bahwa ketika menyalin, hanya tautan reflink ke file lama yang akan dibuat. Saat menulis ke file baru seperti itu, sektor untuk data yang diubah akan dialokasikan secara otomatis. Akibatnya, kami akan memiliki sektor yang sama untuk bagian umum file, dan bagian yang berbeda akan direkam di sektor yang berbeda.
Itu kemudian tampak seperti obat mujarab untuk membuat akun untuk shared hosting, dan sekarang itu adalah solusi terbaik untuk mesin virtual ringan dan wadah. Bagaimanapun, kami tidak dapat membuang ruang pada file yang identik, pada saat yang sama memungkinkan pengguna untuk dengan mudah mengubahnya.
Namun, Hans Riser pergi ke atap dan membunuh istrinya, dan gagasannya (kemungkinan besar karena alasan politik) tidak termasuk dalam inti. Mungkin, setelah semua, ceritanya tergantung pada orang tertentu?
ZFS diterbitkan di bawah lisensi yang tidak kompatibel dengan Linux, dan karenanya tidak termasuk dalam kernel. Oleh karena itu, pengenalan ZFS di Linux diperlambat untuk waktu yang lama.
Setelah itu saya mulai menunggu Btrfs. Dan hanya 6 tahun setelah pengumuman, itu diakui oleh pengembang kernel Linux sebagai stabil.
Setelah itu, saya meluangkan waktu untuk menggunakan sistem Cow, karena paradigma Copy-on-Write itu sendiri menyiratkan peningkatan fragmentasi, karena perubahan data ditulis ke tempat baru setiap waktu.
Untuk HDD, fragmentasi membunuh kinerja, karena proses reposisi blok read head adalah operasi yang sangat panjang.
Oleh karena itu, saya pribadi menunda implementasi btrfs di komputer saya hingga beralih ke SSD.
Saya perhatikan bahwa SSD juga tidak suka fragmentasi, semua orang tahu bahwa untuk SSD, tulis / baca linear bisa puluhan kali lebih cepat daripada akses acak.
Tetapi kinerja SSD yang terfragmentasi tidak sedramatis HDD.
Jadi, bagaimana dengan kecepatan salin dengan KK?
Dan akhirnya, saatnya telah tiba. Ketika SSD menjadi cukup andal, saya mulai menggunakan sistem file CoW dengan kekuatan dan main. Lebih khusus lagi, Btrfs dan Nilfs2.
Menguasai kemungkinan foto yang menarik, untuk sementara saya lupa tentang harapan saya dari tahun 2000-an tentang penyalinan file yang sangat cepat.
Setelah beberapa waktu, saya memutuskan untuk melakukan tes. Dan sangat mengecewakan saya, saya tidak melihat peningkatan kecepatan dari CoW saat menyalin. Ini adalah hasil dari SSD SATA:
time cp -a /usr /usr1 real 0m15,572s user 0m0,240s sys 0m4,739s
Ternyata untuk menggunakan KK Anda harus menentukan kunci khusus.
time cp -a --reflink=auto /usr /usr2 real 0m3,166s user 0m0,178s sys 0m2,891s
Hanya dalam hal ini kita melihat keuntungan 5 kali lipat. By the way, ukuran keuntungan tumbuh tanpa batas dengan bertambahnya panjang file. Folder
/usr
yang saya salin sebagian besar adalah file kecil.
Saya sangat terkejut mengapa keuntungan utama dari sistem file CoW tidak digunakan secara default. Memang, untuk ini dia diciptakan!
Dalam hal ini, saya menguji penyalinan pada bagian Btrfs. Tetapi Anda akan mendapatkan hasil yang serupa dengan sistem file CoW lainnya yang mendukung reflink.
Apa masalahnya, Billy?
Masalahnya ada di cp. Secara default, ini tidak menggunakan CoW saat menyalin. Meskipun bisa.
Anda bisa mengatakan - Saya tidak menggunakan cp. Namun, di bawah kap Linux, digunakan hampir di mana-mana. Banyak program, ketika mereka perlu menyalin sesuatu, menggunakan cp
, dan bukan "sepeda" mereka.
Mengapa pengembang coreutils membuat keputusan yang ambigu, yang mencoret setengah dari kelebihan sistem file CoW?
Ternyata itulah yang diputuskan oleh Pádraig Brady, yang bertanggung jawab atas pengembangan GNU coreutils.
Berikut ini logikanya :
- Secara default, cp tidak menggunakan CoW, karena seseorang dapat menggunakan penyalinan untuk meningkatkan kemungkinan menyimpan file ke disk setelah penghancuran sistem file.
- Dalam hal kinerja, jika ada semacam proses penundaan-sensitif, Anda mungkin ingin catatan utama dibuat selama penyalinan, jadi jika ini terjadi nanti, mungkin ada jeda saat memposisikan ulang kepala hard drive. Harap dicatat bahwa dimulai dengan versi 8.24 coreutils, mv menggunakan opsi reflink secara default.
Teks jawaban Pádraig Brady dalam bahasa InggrisIni bukan default karena untuk alasan ketahanan seseorang mungkin ingin salinan dilakukan untuk melindungi terhadap korupsi data. Juga untuk alasan kinerja, Anda mungkin ingin agar penulisan terjadi pada waktu penyalinan alih-alih beberapa proses sensitif latensi yang bekerja pada file CoW dan ditunda oleh penulisan mungkin ke bagian lain dari disk mekanis. Perhatikan bahwa dari coreutils v8.24 mv akan reflink secara default, karena tidak memiliki kendala di atas.
Dalam hal kecepatan untuk mv, praktis tidak ada manfaat dari CoW saat memindahkan file. Dalam sistem file tunggal, mv hampir selalu berfungsi dengan sangat cepat.
Sekali lagi, muncul pertanyaan tentang pengaruh kepribadian terhadap sejarah. Dengan meletakkan beberapa huruf dalam kode sumber program secara berbeda, Anda dapat memperlambat penyalinan untuk puluhan / ratusan juta pengguna (di sini Anda perlu mempertimbangkan bahwa sekarang kebanyakan orang menggunakan layanan cloud dalam satu bentuk atau lainnya, bahkan jika mereka tidak memiliki komputer), mengurangi efisiensi penggunaan drive dan meningkatkan penjualan mereka di seluruh dunia.
Argumen pádraig parsing
Argumen pertama masuk akal. Pengguna yang tidak berpengalaman sebenarnya dapat membuat cadangan file yang berharga pada sistem file yang sama.
Argumen kedua. Jika Anda membaca komentar lebih lanjut tentang kelambatan dari Pádraig, Anda akan mendapati bahwa ia ada dalam situasi basis data di mana saat menulis ke file yang ada, mungkin ada penundaan karena sistem file mencari ruang kosong. Tetapi dalam kasus sistem file Kontrak Karya, sektor-sektor baru akan selalu dicari untuk direkam karena sifat Kontrak Karya, sebagaimana dicatat oleh Jan Kanis. Oleh karena itu, menurut pendapat saya, argumen kedua tidak dapat dipertahankan.
Namun, pada sistem KK, memang mungkin untuk mendapatkan keterlambatan atau bahkan kesalahan "Keluar dari ruang" saat menulis ke file database. Untuk menghindari hal ini, Anda harus membuat direktori kosong dengan Kontrak Karya dinonaktifkan untuk basis data.
Nonaktifkan CoW pada direktori / file seperti ini:
chattr +C /dir/file chattr +C /dir/dir
Ada juga opsi untuk me-mount nodatacow. Ini akan diterapkan ke semua file yang baru dibuat.
Tetapi bagaimana jika kita ingin menggunakan CoW saat menyalin secara default?
- Cara radikal adalah menambal coreutils. Mungkin membuat paket Anda di repositori pribadi Anda.
Menambal file cp.c :
-x->reflink_mode = REFLINK_NEVER; +x->reflink_mode = REFLINK_AUTO;
- Solusi yang kurang radikal adalah menulis alias cp untuk shell Anda. Untuk bash, misalnya:
Di folder /etc/profile.d
, buat cp_reflink.sh
cp_reflink.sh dengan konten:
Solusi ini akan bekerja di hampir semua kasus ketika cp diakses dari shell dengan nama. Tetapi jika / bin / cp akan digunakan dalam skrip, maka alias tidak akan berfungsi dan penyalinan akan terjadi seperti biasa.
Manajer file dan reflink
Status per 31 Oktober 2019:
- Midnight Commander - mendukung.
- Krusader - tidak mendukung.
- Lumba-lumba - tidak mendukung.
- Nautilus - tidak mendukung.
- Nemo - Mendukung.
Bahasa pemrograman, panggilan sistem dan reflink
Sebagian besar bahasa pemrograman tidak memiliki dukungan reflink.
Di C, banyak programmer masih menyalin
menggunakan loop dan buffer .
Panggilan sistem
sendfile tidak menggunakan reflink.
cp
menggunakan
panggilan sistem
ioctl dengan bendera FICLONE.
Saya pikir jika Anda perlu menyalin sesuatu dalam kode, disarankan untuk melakukannya seperti
cp
atau panggil
cp --reflink=auto
.
Kesimpulan
Dengan munculnya era virtualisasi dan SSD di mana-mana, menjadi sangat penting untuk menggunakan sistem file CoW. Mereka nyaman untuk membuat foto, penyalinan cepat. Bahkan, ketika menggunakan CoW saat menyalin, kami
secara otomatis melakukan deduplikasi data .
Saat ini, hanya 3 sistem file yang mendukung jenis salinan ini: BTRFS, XFS dan OCFS2.
Saya sangat berharap bahwa dukungan reflink akan selesai di ZFS dan NILFS2, karena mereka sudah mendukung KK melalui mekanisme internal.
Namun, di semua distribusi Linux, Kontrak Karya dinonaktifkan saat menyalin file, dan kita perlu menentukan kunci yang terkait secara eksplisit, atau menggunakan berbagai trik seperti alias atau patch.
18 tahun telah berlalu sejak pengumuman Reiser4, namun sejauh ini penyalinan CoW yang ringan belum memasuki kehidupan kita di mana-mana.
PS Docker dan CoW
Apakah Anda tahu bahwa Docker mendukung btrfs untuk penyimpanannya? Opsi ini harus diaktifkan. Ini tidak dipilih secara default.
Sistem file CoW dalam teori adalah pelengkap sempurna untuk virtualisasi yang mudah ketika mesin virtual yang berbeda menggunakan kernel yang sama.
Menurut pendapat saya, ini jauh lebih organik daripada OverlayFS dan Aufs, yang merupakan penopang teknologi untuk mensimulasikan Kontrak Karya.
Untuk menggunakan Btrfs di Docker Anda perlu:
- Dalam pemasangan Docker yang baru (tanpa gambar dan mesin virtual), pasang volume Btrf terpisah ke
/var/lib/docker
- Tambahkan Opsi ke File Konfigurasi Peluncuran Docker
Untuk Gentoo dan Calculate Linux, ini
/etc/conf.d/docker
DOCKER_OPTS="--storage-driver btrfs --data-root /var/lib/docker"
Dan di sini adalah
instruksi lengkap untuk semua distribusi.
Tambahan dari komentar
XFS dan CoW
constb (
source ): Pada XFS, CoW juga tidak selalu didukung. Anda perlu membuat sistem file dengan
mkfs.xfs -m reflink=1
.
Sudah pada FS yang dibuat, Anda tidak dapat "mengaktifkan" dukungan KK. ditambah, pada kernel hingga 4,11 dimasukkannya opsi ini menyebabkan peringatan merah di dmesg bahwa fitur ini eksperimental.
MacOS dan CoW
MMik (
sumber ): Di OS X, opsi yang mirip dengan perintah
cp
adalah
-c
.
Ini melibatkan penggunaan panggilan sistem atom
clonefile()
, yang membuat entri dalam sistem file tentang file baru di mana referensi ke blok data identik dengan aslinya. Atribut dan atribut diperluas dari file disalin, entri daftar kontrol akses (ACL), dengan pengecualian dari informasi pemilik file dan dengan reset bit setuid / setgid. Ini bekerja di dalam sistem file yang sama, membutuhkan dukungan oleh sistem file (atribut ATTR_VOL_CAPABILITIES, tandai VOL_CAP_INT_CLONE).
Didukung sejak OS X 10.12 (Sierra) dan hanya pada sistem file
APFS .
Ucapan Terima Kasih:
PPS Mengarahkan kesalahan yang diketahui secara pribadi. Saya meningkatkan karma untuk ini.
Anda dapat bereksperimen dengan sistem file
CoW dengan memesan mesin virtual dari
RUVDS dengan kupon di bawah ini.
