Zfs: Dukungan COW cp (--reflink)

Tautan ke utas diskusi zfs untuk permintaan fitur ini:
http://groups.google.com/a/zfsonlinux.org/group/zfs-discuss/browse_thread/thread/9af181ed0129b77c#

Saya ragu apakah ini diperlukan -- karena fungsionalitasnya sudah tersedia di tingkat kumpulan data (sistem file), dan ZFS dimaksudkan untuk diimplementasikan dengan kumpulan data (sistem file) berbutir halus.

1. Saya tidak melihat alasan mengapa kuota harus khusus untuk fitur ini. Sudah jika Anda mengaktifkan salinan zfs, setiap penulisan baru akan menulis 2 atau 3 kali jumlah blok yang diharapkan aplikasi. Sistem berbasis ZFS dimaksudkan untuk memiliki ruang kosong yang cukup, dan kuota sulit untuk dihitung/dipahami dan lebih memaafkan daripada kuota pada sistem yang tidak memiliki KK.
2. Kompresi yang sama tidak masalah. Jika Anda memiliki kumpulan data kloning dan mengubah kompresi pada salah satunya -- data yang ada tidak berubah, pengaturan kompresi baru hanya penting untuk penulisan baru.
3. Jelas jika kunci enkripsi berbeda, maka data tidak dapat disimpan dalam blok yang sama dan KK tidak berlaku.
4. Atribut salinan, seperti pengaturan kompresi, hanya berlaku untuk penulisan baru. Ini tidak berbeda secara semantik dengan mengkloning kumpulan data (atau mempromosikan snapshot).
5. Masalah ini mirip dengan 3.

KK sudah diterapkan di seluruh kumpulan data tertentu -- misalnya klon atau kumpulan data dengan snapshot (dipromosikan atau sebaliknya). Oleh karena itu, saya mengusulkan versi yang lebih berguna secara umum dari permintaan ini: terapkan atau izinkan COW untuk semua operasi penyalinan di pangkalan kumpulan yang sama pada pengaturan yang diterapkan pada kumpulan data dan tingkat kumpulan.

Hanya untuk mengulangi di sini apa yang telah dibahas di https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups=#!msg/zfs -discuss/mvGB7QEpt3w/r4xZ3eD7nn0J -- snapshot, dedup dan sebagainya sudah memberikan _sebagian besar_ manfaat pemutusan hardlink COW, tetapi tidak semua.

Secara khusus, binari dan lib dengan nomor inode yang sama dipetakan ke lokasi memori yang sama untuk dieksekusi, yang menghasilkan penghematan memori. Ini sangat penting dengan virtualisasi berbasis wadah di mana Anda mungkin memiliki lusinan atau ratusan salinan identik dari libc6 atau sshd atau Apache dalam memori. KSM membantu di sana, tetapi membutuhkan madvise() dan tidak gratis (biayanya CPU saat runtime).

Hardlink COW pada dasarnya gratis.

linux-vserver (http://linux-vserver.org/) sudah menambal ext[234] dan saya pikir jfs untuk mengaktifkan fungsionalitas pemutus hardlink COW semacam ini dengan menyalahgunakan atribut yang tidak dapat diubah dan atribut yang tidak digunakan linux-vserver digunakan kembali sebagai " break-hardlink-and-remove-immutable-bit-ketika-dibuka-untuk-menulis".

Akan sangat bagus untuk memiliki fitur yang sama di zfsonlinux; kekurangannya adalah satu-satunya alasan saya tidak dapat menempatkan volume vservers saya di zfs (kurangnya dukungan posix atau nfsv4 acl adalah alasan lainnya).

Jadi, untuk memperjelas, saya meminta semantik berikut:

1. buat hardlink ke file dan atur beberapa xattr(?) di atasnya.
2. jika file dibuka untuk dibaca, semuanya berjalan seperti biasa.
3. jika file dibuka untuk menulis, contoh file yang akan dibuka akan dihapus, dan salinan baru dari file asli ditempatkan di sana; open() berhasil dan pegangan file yang dihasilkan merujuk ke salinan baru.

Ini tidak akan merusak aplikasi yang ada karena fitur tersebut tidak akan diaktifkan secara default (Anda harus mengatur xattr khusus pada file untuk menggunakannya).

Seperti yang dibahas di utas kami saat ini menggunakan http://www.xmailserver.org/flcow.html di ext4 untuk file/dir level COW. Ini berfungsi, tetapi kami lebih suka jika kami menggunakan ZFS agar sistem file mengurus kebaikan COW. (Untuk kasus penggunaan sempit kami, kami mungkin dapat melakukan semua yang perlu kami lakukan dengan sistem file per direktori, tetapi membuat kode kami hanya berfungsi dengan ` cp akan menyenangkan untuk dimiliki.)

Saya ingin bertemu untuk fitur ini. Ketika saya menyerahkannya 2 tahun yang lalu ada sekitar 30 masalah sebelumnya, sekarang ada sekitar 500. Ini bergerak semakin jauh dengan masalah yang diciptakan sebelumnya seperti dalam perluasan alam semesta. Saya mengerti ini permintaan fitur dan bukan perbaikan bug tetapi itu akan membuat ZFS jauh lebih menarik bagi orang-orang.
Memotret seluruh sistem file ZFS untuk mencapai klon dari 1 file jelas berlebihan, tidak dapat diganti.

Salah satu masalah dengan penerapan ini adalah bahwa entri direktori diimplementasikan sebagai pasangan nama-nilai, yang sekilas, tidak memberikan cara yang jelas untuk melakukan ini. Saya baru menyadari hari ini bahwa nilai dibagi menjadi 3 bagian. 4 bit teratas menunjukkan jenis file, 48 bit bawah adalah objek sebenarnya dan 12 bit tengah tidak digunakan. Salah satu bit yang tidak digunakan dapat digunakan kembali untuk mengimplementasikan reflink.

Menerapkan reflink akan membutuhkan lebih dari sekadar menandai sedikit, tetapi fakta bahwa kami memiliki bit cadangan yang tersedia seharusnya menjadi informasi yang berguna bagi siapa saja yang memutuskan untuk mengerjakan ini.

Hai Ryao, terima kasih telah memperhatikan ini :-) Jika deduplikasi tidak memerlukan bit seperti itu atau struktur direktori yang berbeda, maka reflink juga tidak memerlukannya. Saya melihat reflink sebagai cara untuk melakukan copy+deduplicate file tertentu tanpa biaya yang terkait dengan copy dan deduplication, tetapi dengan hasil akhir yang sama... Bukankah begitu?

@ robek 5 Saya yakin Anda benar, ini bisa dilakukan dengan relatif mudah dengan memanfaatkan dedup. Pada dasarnya, reflink ioctl() akan menyediakan antarmuka pengguna untuk deduplikasi per file. Selama kita berbicara tentang jumlah file aktif yang relatif kecil, seluruh tabel deduplikasi harus mudah di-cache dan kinerjanya akan baik. Jika diterapkan dengan cara ini, kami akan mewarisi perilaku dedup yang ada untuk kuota dan semacamnya. Ini paling masuk akal untuk file individual dalam sistem file yang lebih besar, karena direktori yang membuat kumpulan data baru masih akan menjadi yang terbaik.

Berikut adalah skenario yang menurut saya fitur ini akan sangat membantu:

Saya mengambil snapshot reguler dari koleksi video saya. Karena COW, foto-foto ini tidak memakan tempat. Namun, (kerabat muda|virus|alien bermusuhan) datang berkunjung dan menghapus beberapa video dari koleksi saya, dan saya ingin memulihkannya dari cuplikan praktis saya. Jika saya menggunakan cp secara normal, setiap video yang dipulihkan digandakan dalam snapshot dan di ruang aktif. Dengan cp --reflink, sistem file akan diberi sinyal ke COW file ke nama baru, tanpa mengambil ruang tambahan, bersama dengan membuat pemulihan seketika.

Selain itu, apakah ada cara untuk memindai volume ZFS dan menjalankan deduplikasi offline? Jika saya telah menyalin data, apakah ada cara untuk memulihkan ruang selain menghapus semua snapshot yang berisi data?

Pada Kamis, 16 Januari 2014 pukul 05:16:38PM -0800, hufman menulis:

Saya mengambil snapshot reguler dari koleksi video saya. Karena SAP, ini
snapshot tidak memakan tempat. Namun, (kerabat muda|virus|bermusuhan
alien) datang berkunjung dan menghapus beberapa video dari koleksi saya, dan saya
ingin memulihkannya dari snapshot praktis saya. Jika saya menggunakan cp biasanya,
setiap video yang dipulihkan diduplikasi dalam snapshot dan di ruang aktif.
Dengan cp --reflink, sistem file akan memberi sinyal kepada COW file ke a
nama baru, tanpa mengambil ruang tambahan, bersama dengan membuat pemulihan
seketika.

Saya tidak yakin saya melihat bagaimana itu akan berhasil; itu akan membutuhkan sistem file lintas
dukungan reflink (karena Anda akan menyalin dari snapshot dan menjadi nyata
fs).

Biasanya, untuk pulih dari situasi seperti itu, Anda hanya perlu memutar kembali ke
snapshot terbaru yang masih memiliki data yang hilang. Tentu saja, jika Anda mau
simpan beberapa perubahan yang dibuat sejak saat itu, ini kurang ideal.

Jika ini sering terjadi, mungkin Anda ingin mengaktifkan deduplikasi.
Dalam hal ini, menyalin file dari snapshot tidak akan menggunakan ekstra
ruang angkasa.

Selain itu, apakah ada cara untuk memindai volume ZFS dan menjalankan offline
deduplikasi?

Tidak ada yang saya tahu. Yang dapat Anda lakukan adalah: aktifkan dedup, lalu salin setiap file
ke nama baru, hapus file asli dan ganti nama file baru menjadi yang lama
nama. Ini jelas tidak melakukan apa pun untuk menghilangkan duplikat snapshot yang ada.

Jika saya telah menyalin data, apakah ada cara untuk memulihkan
ruang selain menghapus semua snapshot yang berisi data?

Selain memutar kembali ke snapshot, tidak, saya rasa tidak.

andras

                            E = mc^2 + 3d6

Terima kasih atas tanggapan Anda!

Kasus penggunaan saya untuk reflink adalah bahwa kami sedang membangun alat debugging rekaman dan replay (https://github.com/mozilla/rr) dan setiap kali proses debuggee memetakan file, kami perlu membuat salinan file itu jadi kita bisa memetakannya lagi nanti tidak berubah. Reflink membuatnya gratis. Snapshot sistem file tidak akan bekerja untuk kami; mereka lebih berat, canggung untuk kasus penggunaan ini, dan jauh lebih sulit untuk diterapkan di alat kami.

Saya juga menggunakan ini, saya menggunakan sistem file zfs yang berbeda untuk mengontrol persyaratan IO yang berbeda. Saat ini aplikasi saya untuk memindahkan item di antara sistem file ini harus melakukan salinan lengkap, yang berfungsi, tetapi membuat hal-hal cukup tidak responsif secara teratur, karena menyalin lusinan gigabyte data. Saya akan mempertimbangkan untuk menggunakan deduplikasi, tetapi sumber daya saya cukup terbatas.

Saya ingin melakukan ini sebagai proyek GSoC 2014 saya, tetapi saya tidak tahu apakah ZFSOnLinux berpartisipasi dalam GSoC.

ZFSOnLinux tidak berpartisipasi, tetapi Gentoo berpartisipasi. Kumpulkan proposal dan saya dan orang lain akan meninjaunya. Jika terlihat bagus, saya bersedia membimbing ini.

Sebanyak saya menginginkan fitur ini, saya khawatir ini mungkin merupakan gsoc
penyalahgunaan dalam beberapa cara. pease pastikan untuk membaca aturan dengan hati-hati.
Pada 11 Maret 2014 17:27, "Richard Yao" [email protected] menulis:

ZFSOnLinux tidak berpartisipasi, tetapi Gentoo berpartisipasi. Kumpulkan proposal
dan saya dan yang lainnya akan mengulasnya. Jika terlihat bagus, saya bersedia menjadi mentor
ini.

—
Balas email ini secara langsung atau lihat di Gi tHubhttps://github.com/zfsonlinux/zfs/issues/405#issuecomment -37363140
.

@ryao Hmm, ide illumos halaman 1 mengatakan saya juga bisa mengusulkan ide untuk OpenZFS. Bukankah ZoL bagian dari OpenZFS?

@yshui OpenZFS adalah proyek payung untuk berbagai platform ZFS. Itu tidak secara langsung berpartisipasi dalam GSoC, tetapi beberapa platform anggotanya berpartisipasi. Illumos dan FreeBSD berpartisipasi dalam GSoC. ZoL tidak, tetapi bisa secara tidak langsung melalui Gentoo, yang juga berpartisipasi dalam GSoC.

@ryao saya mengerti. Maaf saya tidak membaca komentar Anda sebelum membalas email Anda.

Jika seseorang memutuskan untuk mengerjakan ini, saya senang membantu mengarahkan mereka ke arah yang benar.

Saya telah mencatat kemungkinan cara melakukan ini di #2554 sebagai tanggapan atas pertanyaan tentang deduplikasi gaya btrfs melalui reflinks. Saya menggandakannya di sini untuk referensi di masa mendatang:

Direktori di ZFS adalah pasangan nama-nilai. Menambahkan reflink ke itu tidak sepele. Satu ide yang mungkin berhasil adalah mengganti penunjuk blok di pohon tipuan dengan pengidentifikasi objek dan menggunakan ZAP untuk menyimpan pemetaan antara id objek dan tupel (jumlah referensi, penunjuk blok). Itu akan melibatkan perubahan format disk dan hanya akan berlaku untuk file yang baru dibuat. Setiap akses blok akan mengalami tipuan tambahan. Membuat reflink di bawah skema ini akan membutuhkan duplikasi seluruh pohon tipuan dan memperbarui entri ZAP yang sesuai dalam satu grup transaksi.

Memikirkannya, pohon tipuan itu sendiri selalu jauh lebih kecil daripada data itu sendiri, sehingga tindakan menulis akan dibatasi pada beberapa persentase data. Kami sudah mengalami penalti semacam ini dari implementasi deduplikasi yang ada, tetapi pada penalti yang jauh lebih tinggi karena kami harus melakukan pencarian acak pada setiap akses data. Membiarkan pengguna hanya menyalin metadata melalui reflink tampaknya lebih disukai daripada mengarahkan salinan data dengan mengacak data melalui userland. Ini dapat menghindari hukuman dengan adanya dedup=on karena semua data telah diproses sebelumnya oleh algoritme deduplikasi kami.

Karena itu, DDT memiliki jumlah referensi sendiri untuk setiap blok, jadi kita perlu menerapkan ini dengan cara yang kompatibel dengan itu atau mengubahnya. Kita juga perlu mempertimbangkan interaksi dengan snapshot.

Berikut adalah teknik yang mungkin bisa diterapkan:

https://www.usenix.org/legacy/event/lsf07/tech/rodeh.pdf

Ada beberapa peringatan:

1. Perhatian harus diberikan dengan interaksi antara ini dan snapshot kumpulan data. Snapshot berisi daftar blok referensi yang mungkin perlu diperbarui.
2. Seperti yang saya katakan di bulan Juli, DDT memiliki jumlah referensi dan kita perlu menerapkan ini dengan cara yang kompatibel.
3. Teknik yang dijelaskan tidak dapat diterapkan pada kumpulan data ZFS yang ada. Cara Jeff merancang pohon tipuan mengeksploitasi beberapa properti angka yang mencegah kita tiba-tiba menggunakan kembali dua entri, yang dibutuhkan oleh algoritme. Itu juga mungkin membatasi ukuran file maksimum kami (saya perlu memeriksa) karena hilangnya 2 entri di pohon tipuan berarti bahwa total penyimpanan yang dapat dialamatkan berkurang. Ini berarti bahwa kami hanya dapat mendukung reflink pada kumpulan data baru yang dibuat dengan fitur ini jika diimplementasikan. Kumpulan data lama tidak dapat ditingkatkan, meskipun send/recv kemungkinan dapat digunakan untuk membuat yang baru dalam format baru.

Saya terlambat ke pesta ini tetapi saya ingin memberikan kasus penggunaan yang pasti dan nyata untuk ini yang tidak dipenuhi oleh klon.

Kami memiliki kotak pasir proses yang mengimpor file yang tidak dapat diubah. Idealnya, setiap file yang diimpor dapat dimodifikasi oleh proses, tetapi modifikasi tersebut tidak boleh mengubah file asli yang tidak dapat diubah. Oke, itu bisa diselesaikan dengan sistem file kloning dan COW. Namun, dari kotak pasir ini kami juga ingin mengekstrak file keluaran (mungkin sangat besar). Ini melempar kunci pas dalam rencana kami. Kami tidak dapat dengan mudah mengimpor data dari klon kembali ke sistem file induk tanpa melakukan salinan byte demi byte.

Saya pikir ini adalah masalah yang layak dipecahkan. Klon (setidaknya, seperti yang ada saat ini) bukanlah jawaban yang tepat.

Maaf jika saya kehilangan sesuatu dalam diskusi jarak jauh ini, tetapi bagi saya tampaknya semua orang berpikir dalam snapshot, klon, dedup, dll.

Saya, secara pribadi, penggemar berat dedup. Tapi saya tahu ini memiliki banyak kekurangan memori, karena dilakukan secara online. Di BTRFS dan WAFL, dedup dilakukan secara offline. Jadi, semua memori ini hanya digunakan selama proses dedup.

Saya pikir maksud asli dari permintaan ini adalah untuk menambahkan fungsionalitas "kloning/dedup" ke cp. Tetapi tidak dengan mengaktifkan dedup online ke sistem file, atau dengan menyalin terlebih dahulu dan mereka menghapus file tersebut. Biarkan sistem file membuat instance "file" lain, di mana datanya adalah kumpulan sektor Kontrak Karya dari file lain.

Bergantung pada bagaimana ZFS menyesuaikan data secara internal, saya dapat membayangkan ini bahkan digunakan untuk "memindahkan" file antar sistem file di kumpulan yang sama. Tidak ada blok disk payload yang perlu disentuh, hanya metadata.

Oke, ada kasus di mana ukuran blok, kompresi, dll diatur secara berbeda. Tapi IIRC, ini hanya "valid" untuk file yang lebih baru. File lama akan menyimpan apa yang sudah ada di disk. Jadi, menurut saya ini bukan masalah. Mungkin crypto, seperti yang sudah dikatakan @darthur pada 2011, yang bahkan BUKAN fitur nyata...

Sudah ada fitur seperti itu di WALF. Silakan, lihat ini: http://community.netapp.com/t5/Microsoft-Cloud-and-Virtualization-Discussions/What-is-SIS-Clone/td-p/6462

Mari kita mulai mengkloning file tunggal!!!

@ dioni21 mungkin Anda harus mempertimbangkan zvol yang diformat dengan btrfs.

Saya minta maaf menjadi orang menjengkelkan yang memunculkan utas lama, tetapi saya menemukan masalah ini dan tampaknya sangat berguna.
Jadi saya hanya ingin bertanya apakah ini dijadwalkan untuk rilis? Ini mungkin bukan bagian dari 0,7 tetapi saya ingin melihatnya setelah itu.
Jadi apakah ada orang lain yang mengerjakan fitur ini? Dan apakah ada rencana untuk menerapkannya? Sekarang enkripsi akan membuatnya menjadi 0,7 (saya pikir), ini adalah faktor lain yang perlu dipikirkan.

Fitur ini akan sempurna untuk kebutuhan kita.
Seorang pengguna menyiapkan file besar untuk sebuah proyek.
Pengguna mengirimkan file-file itu.
File-file itu saat ini disalin ke direktori
untuk QA dan pemrosesan lainnya.
Sebagian besar waktu, file tersebut OK dan tidak perlu dikirim ulang.
Namun, karena salinan kami memiliki duplikasi besar-besaran.
Menggunakan snapshot zfs tidak benar-benar berfungsi untuk kami.
Kita harus membuat sejumlah besar dari mereka
dan menjaga mereka di sekitar selamanya.
Tapi salinan reflink akan sempurna.

@galt : Meskipun saya setuju bahwa fitur COW yang diuraikan di sini akan sangat bagus untuk dimiliki, tampaknya kasus penggunaan Anda mengaktifkan de-duplikasi pada dataset zfs yang berisi aslinya & salinan sudah secara efektif menghemat ruang yang saat ini ditempati oleh 'un -membutuhkan' salinan identik. Atau apakah saya melewatkan sesuatu?

Bukankah deduplikasi sangat intensif RAM?

Ya.

Alih-alih hanya menyalin file, saya akan menyebutnya dengan
cp --reflink=selalu sumber target
yang berarti bahwa ia beroperasi di seluruh tingkat file.

Ini sangat berbeda dengan mengaktifkan fitur zfs dedup dan menghabiskan 1GB/TB pada RAM untuk hash dedup.
Juga, ini adalah operasi super cepat karena hanya beberapa metadata yang perlu disalin
untuk membuat reflink.

Fitur tersebut telah diimplementasikan pada XFS (setidaknya untuk pengujian) sejak Januari 2017.
http://strugglers.net/~andy/blog/2017/01/10/xfs-reflinks-and-deduplication/

APFS: APple File System baru saja dirilis 25 September 2017 di OS High Sierra dan iOS.
Ini memiliki banyak fitur hebat dari zfs dan btrfs dan ocfs2 seperti copy-on-write, reflink,
snapshot dan klon.

Mengutip:
[...] yang saya tahu yang berfungsi juga di XFS adalah duperemove.
https://github.com/markfasheh/duperemove
Anda harus menggunakan git checkout dari duperemove agar ini berfungsi.

Bukankah fitur ini secara teknis harus diimplementasikan ke hulu, melalui proyek openzfs? Ini sepertinya bukan masalah ZFS di Linux ...

Pertanyaan kedua: apakah praktis untuk mengimplementasikan desain ZFS yang diberikan? Berdasarkan apa yang saya baca, reflink tidak pernah benar-benar menjadi bagian dari desain ZFS untuk memulai dan karena itu mungkin tidak praktis untuk diterapkan ...

Pertanyaan pertama: poin bagus. openzfs seharusnya.

Pertanyaan kedua: sebagian besar mesin copy-on-write yang dibutuhkan sudah tersedia.
Cukup mudah untuk membuat salinan reflink, dibandingkan dengan membuat snapshot dan klon.
Pada dasarnya hanya perlu menduplikasi inode dan meta data yang terkait (tetapi tidak
blok data aktual dari file). Mungkin perlu memperbarui beberapa tanda atau jumlah
pada inode dan blok.

Adakah yang bisa mengarahkan saya ke repositori openzfs?
Saya tidak melihat satu pun.

Halaman ini menyiratkan tidak ada satu:
http://open-zfs.org/wiki/FAQ#Do_you_plan_to_release_OpenZFS_under_a_license_other_than_the_CDDL.3F
MENGUTIP:
Mengapa ada empat repositori yang berbeda?

Setiap repositori mendukung sistem operasi yang berbeda. Meskipun inti dari OpenZFS adalah platform-independen, ada sejumlah besar perubahan spesifik platform yang perlu dipertahankan untuk bagian-bagian ZFS yang berinteraksi dengan sistem operasi lainnya (VFS, manajemen memori, disk i/o, dll.).
Apakah fitur dan peningkatan baru dibagikan di antara repositori yang berbeda?

Ya. Setiap implementasi secara teratur mem-porting perubahan platform-independen dari implementasi lainnya. Salah satu tujuan OpenZFS adalah untuk menyederhanakan proses porting ini.

ryao ingin menambahkan reflink ke zfs pada tahun 2014.
https://lists.gt.net/gentoo/dev/285286?do=post_view_threaded

@galt Sepertinya tidak ada repositori OpenZFS "utama". Saya menduga hal terdekat yang akan Anda temukan adalah build OpenSolaris ZFS asli, yang akan menjadi rasa Illumos dan/atau OpenIndiana. Karena itu, sepertinya ada upaya (atau minatnya) untuk menyatukan kode (kode ZFS inti dan berbagai lapisan port khusus platform): http://open-zfs.org/wiki/Reduce_code_differences

Itu buruk... bayangkan jika tim ZoL menemukan reflink, saya akan menganggap itu bukan hal sepele untuk mem-porting fitur itu ke Illumos atau FreeBSD, misalnya. Saya harap inisiatif penyatuan di atas berhasil, jika tidak, basis kode ZFS akan menjadi terlalu terfragmentasi dan sulit untuk didukung dalam jangka panjang... :kecewa:

@galt @rouben tidak ada masalah sama sekali dengan repo yang berbeda dll, hanya saja tidak sepele untuk menambahkan fungsi ini di ZFS.

Repositori OpenZFS upstream terletak di https://github.com/openzfs/openzfs. Fitur-fitur yang dikembangkan di Linux, FreeBSD, dan Illumos di-feed back upstream sesuai dengan repositori ini. Setiap platform kemudian menarik kembali perubahan yang mereka butuhkan.

Mengenai dukungan reflink, ini adalah sesuatu yang telah dibahas pada pertemuan pengembang OpenZFS sebelumnya dan beberapa kemungkinan desain telah diusulkan. Ini pasti dapat dilakukan, tetapi kami ingin melakukannya dengan cara portabel yang efisien yang idealnya dapat dimanfaatkan oleh semua platform.

Saya seharusnya menambahkan bahwa siapa pun yang tertarik dipersilakan untuk bergabung dengan kami di OpenZFS Developer Summit 2017 mendatang di mana kami akan mendiskusikan semua hal tentang OpenZFS!

fwiw oracle telah melakukan ini secara internal, lihat https://www.youtube.com/watch?v=c1ek1tFjhH8#t =18m55s untuk slide yang merujuk pada ini (ada juga tanya jawab nanti dalam pembicaraan yang mengonfirmasi bahwa ini adalah reflink)

sepertinya pertanyaan tentang reflink sekitar 43m45s.

22-11-2017 16:07 GMT-08:00 Chris Wedgwood [email protected] :

fwiw Oracle telah melakukan ini secara internal, lihat
https://www.youtube.com/watch?v=c1ek1tFjhH8#t =18m55s untuk slide
mengacu pada ini (ada juga tanya jawab nanti dalam pembicaraan yang mengkonfirmasi ini
adalah reflink)

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/zfsonlinux/zfs/issues/405#issuecomment-346505559 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAGt3cT2bF6EfZPCd7t-jSjWlnGLN6D5ks5s5LczgaJpZM4AKZEt
.

Anehnya dia bilang itu reflink di linux. dan sepertinya mengatakan itu
ada di Linux.
Tetapi apakah itu berarti tersedia di openzfs? Atau akan segera?

22-11-2017 19:18 GMT-08:00 Galt Barber [email protected] :

sepertinya pertanyaan tentang reflink sekitar 43m45s.

22-11-2017 16:07 GMT-08:00 Chris Wedgwood [email protected] :

fwiw Oracle telah melakukan ini secara internal, lihat
https://www.youtube.com/watch?v=c1ek1tFjhH8#t =18m55s untuk slide
mengacu pada ini (ada juga tanya jawab nanti dalam pembicaraan yang mengkonfirmasi ini
adalah reflink)

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/zfsonlinux/zfs/issues/405#issuecomment-346505559 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAGt3cT2bF6EfZPCd7t-jSjWlnGLN6D5ks5s5LczgaJpZM4AKZEt
.

Saya kira itu berarti hanya dilakukan secara internal, dan belum di OpenZFS.
Sangat buruk.

22-11-2017 19:19 GMT-08:00 Galt Barber [email protected] :

Anehnya dia bilang itu reflink di linux. dan sepertinya mengatakan itu
ada di Linux.
Tetapi apakah itu berarti tersedia di openzfs? Atau akan segera?

22-11-2017 19:18 GMT-08:00 Galt Barber [email protected] :

sepertinya pertanyaan tentang reflink sekitar 43m45s.

22-11-2017 16:07 GMT-08:00 Chris Wedgwood [email protected] :

fwiw Oracle telah melakukan ini secara internal, lihat
https://www.youtube.com/watch?v=c1ek1tFjhH8#t =18m55s untuk slide
mengacu pada ini (ada juga tanya jawab nanti dalam pembicaraan yang mengkonfirmasi ini
adalah reflink)

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/zfsonlinux/zfs/issues/405#issuecomment-346505559 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAGt3cT2bF6EfZPCd7t-jSjWlnGLN6D5ks5s5LczgaJpZM4AKZEt
.

Menabrak lagi.
Dengan dorongan semi-terbaru oleh Ubuntu dari Kubernetes berdasarkan LXD, yang merekomendasikan kumpulan ZFS untuk kinerja, ZFS secara umum mendapatkan lebih banyak perhatian. Sementara snapshot/dedup berguna ketika saya memutar salinan seluruh sistem file wadah, menyalin file besar dari dalam wadah ke luar wadah, atau antar wadah masih selambat sistem file lainnya, yang merupakan akhir yang signifikan. manfaat/perubahan yang terlihat oleh pengguna jika perilaku --reflink=always tersedia untuk diimplementasikan ke dalam alat LXD.

Dalam kasus penggunaan pribadi saya, kami memiliki server build otomatis untuk CI yang perlu membangun banyak varian berbeda dari basis kode yang sangat besar. Kami mengkloning satu kali, dan melakukan pengaturan dasar, lalu kami membuat banyak salinan direktori untuk menjalankan varian yang berbeda. Kami tidak menyentuh file apa pun yang ada selama pembuatan, kami hanya menambahkannya, tetapi karena IO disk adalah faktor utama, kami tidak dapat menggunakan opsi pemasangan tipe overlay. Kami juga tidak akan mengikat diri untuk hanya berfungsi pada satu sistem file, seperti yang diperlukan untuk menerapkan ini sebagai snapshot untuk setiap varian. Implementasi yang akan berguna adalah implementasi yang transparan melalui sesuatu seperti perilaku default --reflink=always pada perintah cp .

Saya pikir cukup jelas bahwa --reflink=always dari perintah cp akan menjadi penggunaan COW yang paling umum untuk sebagian besar pengguna ZFS jika tersedia, karena masalah ini, jumlah masalah yang telah digabungkan menjadi yang satu ini, dan pencarian web sederhana untuk pertanyaan yang terkait dengan KK dalam sistem file menunjukkan.

Menabrak lagi. Ada berita tentang masalah ini? Karena sifat KK dari ZFS, reflink adalah fitur yang jelas (tetapi tidak selalu sepele untuk diterapkan)...

FYI, versi terbaru ccache dapat menggunakan reflinks untuk menyalin file objek masuk dan keluar dari cache objek. Yang merupakan kasus penggunaan yang cukup rapi.

Sekarang alat sinkronisasi _syncthing_ menggunakan salinan sapi (https://docs.syncthing.net/advanced/folder-copyrangemethod.html)

syncthing adalah tentang xfs dan os lainnya tetapi tidak zfs.

Saya memiliki RedHat 8 di rumah, dan instalasi default menggunakan xfs sehingga saya dapat menguji ini, dan itu berfungsi dengan baik:
cp --reflink=selalu testReflink1 testReflink2
Ini menyalin dengan cepat tanpa menduplikasi blok data (COW), yang keren!

Tapi itu tidak zfs.

Saya menggunakan reflinks cukup banyak pada btrfs pada mesin workstation saya untuk membuat cadangan sementara yang ringan di tingkat direktori dan (karena kurangnya kata/konsep yang lebih baik di sini) untuk meniru fungsionalitas overlay tanpa semua overhead untuk menyiapkan overlay yang sebenarnya.

Ada kalanya ini akan sangat berguna pada kumpulan data ZFS saya dan saya ingin memanfaatkannya.

9 tahun, tidak ada yang dilakukan.
Ini dia...
Tolong, dapatkah seseorang menjelaskan mengapa btrfs mengimplementasikan fitur ini, tetapi zfs tidak?
Apa yang begitu sulit tentang itu? Saya tidak tahu banyak tentang internal ZFS.

Lihat presentasi Pawel Dawidek minggu ini di OpenZFS Summit:
https://openzfs.org/wiki/OpenZFS_Developer_Summit_2020_talks#File_Cloning_with_Block_Reference_Table_.28Pawel_Dawidek.29

@Logarithmus apakah Anda membayar seseorang untuk mengembangkan atau mendukung OpenZFS untuk Anda? Jika tidak, saya tidak yakin mengapa menurut Anda tidak apa-apa untuk mengeluh tentang fitur yang hilang dalam proyek yang dapat Anda gunakan secara gratis. Jika ya, maka Anda harus berbicara dengan vendor Anda, bukan ke hulu.

@Logarithmus apakah Anda membayar seseorang untuk mengembangkan atau mendukung OpenZFS untuk
Anda? Jika tidak, saya tidak yakin mengapa menurut Anda tidak apa-apa untuk mengeluh tentang
fitur yang hilang dalam proyek yang dapat Anda gunakan secara gratis. Jika ya, maka
Anda harus berbicara dengan vendor Anda, bukan hulu.
Maaf jika pesan saya sebelumnya terlihat menyinggung Anda. Saya mengeluh
tentang itu karena AFAIK selama 9 tahun tidak ada yang mencoba menerapkan ini
fitur. Ini terlihat agak mengejutkan bagi saya, karena dukungan reflink adalah
fitur yang berguna dalam skenario tertentu.

Beberapa bulan yang lalu saya akhirnya mendapat waktu luang untuk memigrasikan laptop saya dari
EXT4 ke sistem file yang lebih modern, dengan snapshot, enkripsi, dan
kompresi. Sulit untuk memutuskan antara BTRFS dan ZFS. Pada akhirnya
Saya telah memilih ZFS, karena mereka mengatakan itu lebih stabil daripada BTRFS, dan saya
baca cerita horor tentang BTRFS kehilangan data Anda dan gagal
Gunung. Saya tahu bahwa ZFS dan BTRFS adalah sistem file CoW, dan karenanya
reflinks harus bekerja pada kedua sistem file.

Tapi kemarin saya menemukan kebenaran pahit setelah menjalankan cp -- reflink=always . Saya perlu menyalin beberapa direktori dengan pohon subdirektori besar, dan kemudian menimpa
sebagian besar file di dalamnya, jadi saya tidak ingin membuang waktu untuk inisial
penyalinan. Sayangnya, itu gagal. Kemudian saya mulai mencari dan menemukan ini
masalah. Saya langsung kagum bahwa masalah itu terbuka 9 tahun yang lalu.

Setelah itu saya menemukan bahwa BTRFS tidak memiliki masalah dengan symlink.
Apalagi sudah memiliki dukungan kompresi ZSTD. ZFS sekarang memilikinya
dukungan hanya di pra-rilis. Di sisi lain, BTRFS tidak memiliki
enkripsi asli. Tapi seperti yang saya mengerti (beri tahu saya jika saya salah), seseorang bisa
jalankan BTRFS dengan kompresi di dalam LUKS, karena dalam hal ini enkripsi
terjadi SETELAH kompresi. Ini adalah fakta yang diketahui bahwa enkripsi SEBELUM
kompresi membuat kompresi tidak relevan karena sifatnya yang seperti acak
dari data terenkripsi.

Kesimpulannya, sekarang saya memikirkan kembali pilihan ZFS saya. Saya berpikir bahwa dengan
backup reguler kemungkinan kehilangan data dengan BTRFS mendekati
nol.

PS Dapatkah seseorang merekomendasikan saya beberapa yang komprehensif dan terkini
perbandingan ZFS vs BTRFS?

@Logarithmus ... tapi kemarin saya menemukan kebenaran pahit setelah menjalankan cp -- reflink=always .

Ya, saya mengerti: reflink agak diterima begitu saja dari sistem file modern. Sayangnya, seperti yang Anda temukan, itu tidak diterapkan di ZFS saat ini (dan terima kasih kepada @adamdmoss untuk membagikan tautan di atas!).

Saya perlu menyalin beberapa direktori dengan pohon subdirektori besar, dan kemudian menimpa sebagian besar file di dalamnya, jadi saya tidak ingin membuang waktu untuk penyalinan awal.

Bisakah saya menyarankan menggunakan hardlink ( cp -al ) untuk melakukan pra-seed direktori tujuan, lalu menghapus file yang akan ditimpa? Jika menggunakan rsync (tanpa --inplace ), Anda dapat (dalam banyak kasus) bahkan menghindari pass hapus. Tentu, ini bukan substitusi yang benar untuk reflink (ketika sebagian menimpa file yang di-hardlink, semua "salinan" akan ditimpa), tetapi ini dapat berguna dalam beberapa kasus. _Penafian penuh: bekerja dengan hardlink dapat membingungkan. Jika Anda tidak mengenal mereka dengan baik, cukup berhenti di sini dan buat salinan sederhana._

Setelah itu saya menemukan bahwa BTRFS tidak memiliki masalah dengan symlink. Apalagi sudah memiliki dukungan kompresi ZSTD. ZFS sekarang memiliki dukungan seperti itu hanya di pra-rilis.

Ketahuilah bahwa kompresi BTRFS sering kali menghasilkan penghematan yang jauh lebih rendah daripada ZFS: karena kompresi berbasis blok dan BTRFS menggunakan blok 4K, rasio kompresi secara signifikan lebih rendah daripada ukuran blok ZFS yang lebih besar (128K secara default). Saya akan menyarankan Anda untuk melakukan beberapa perbandingan langsung.

Adakah yang bisa merekomendasikan saya perbandingan ZFS vs BTRFS yang komprehensif dan terkini?

Saya tidak yakin ini adalah tempat yang tepat untuk bertanya. Namun, menyederhanakan sebanyak mungkin: BTRFS berfungsi dengan baik untuk menyimpan banyak file yang jarang berubah (yaitu: tugas server file, partisi root dan rumah), tetapi gagal untuk setiap beban kerja penimpaan (yaitu: database, mesin virtual, dll) di mana kinerjanya benar-benar tank.

Lihat presentasi Pawel Dawidek minggu ini di OpenZFS Summit:
https://openzfs.org/wiki/OpenZFS_Developer_Summit_2020_talks#File_Cloning_with_Block_Reference_Table_.28Pawel_Dawidek.29

Video presentasi ini sekarang tersedia: https://youtu.be/WqJoytkNrt8?t=3043