Gesaan dan konteks
Reka bentuk sistem yang meletakkan logik peranti blok maya dalam ruang pengguna (userspace): kernel mendedahkan peranti blok manakala perkhidmatan ruang pengguna mengendalikan gelung (loop), storan blok jauh atau pemetaan qcow2. Ia mesti menyokong I/O konkurensi tinggi, pemulihan ranap proses ruang pengguna, pengasingan kebenaran dan kebolehlihatan.
Linux ublk memisahkan rangka kerja ini kepada satah kawalan (control plane) dan satah data (data plane): /dev/ublk-control menguruskan peranti, /dev/ublkb* membawa I/O blok, dan perkhidmatan ruang pengguna mengambil permintaan serta melakukan komit hasil melalui laluan terus (passthrough) io_uring. Temu duga ini menguji kitaran hayat permintaan, semantik kegagalan dan sempadan keselamatan dan bukannya sekadar memindahkan I/O fail ke dalam suatu proses.
Perkara yang diuji oleh penemu duga
Tunjukkan sempadan antara kawalan, lapisan blok kernel, io_uring dan bahagian belakang (backend) ruang pengguna. Terangkan hubungan satu-ke-satu antara giliran (queues), tag, penimbal (buffers) dan penyelesaian (completions); pilih antara mod per-I/O dan kelompok (batch); tentukan semantik requeue, fail dan replay apabila pelayan keluar; serta kendalikan sifar-salin (zero-copy), keistimewaan, pengasingan bekas (container) dan metrik.
Soalan untuk dijelaskan terlebih dahulu
Beban kerja dan backend
Sahkan nisbah baca/tulis, saiz I/O, bilangan giliran, sasaran kependaman (latency), sama ada backend ialah fail setempat, NBD jauh atau format salin-semasa-tulis (copy-on-write), dan sama ada jaminan susunan diperlukan.
Kegagalan dan keselamatan data
Sahkan semantik untuk ranap ruang pengguna, sekatan rangkaian, penulisan backend pendek, penulisan pendua dan pembuangan peranti. Tentukan sama ada main semula (replay) boleh bertolak ansur dengan penulisan berganda.
Kebenaran dan penggunaan
Sahkan pihak yang boleh mencipta peranti, pihak yang boleh membaca /dev/ublkc*, sama ada perkhidmatan berjalan dalam bekas, keistimewaan sifar-salin yang dibenarkan dan cara penyewa (tenants) diasingkan.
Jawapan 30 saat
“Saya mengasingkan satah kawalan dan data. Kawalan merundingkan giliran, kedalaman dan ciri sebelum memulakan peranti; data mengambil permintaan daripada io_uring mengikut giliran dan tag serta melakukan komit hasil. Setiap permintaan mempunyai pemilik, keadaan dan had masa tamat (timeout). Apabila pelayan ruang pengguna keluar, saya merehatkan (quiesce) peranti dan memilih requeue, fail atau replay mengikut jaminan backend. Menyalin adalah lalai; sifar-salin terhad kepada backend yang dipercayai dan dibenarkan. Metrik meliputi kedalaman giliran, kependaman penyelesaian, percubaan semula, pengguguran dan masa pemulihan, dengan ujian ketekalan untuk pembuangan dan pemulihan.”
Jawapan mendalam langkah demi langkah
Langkah 1: Pisahkan satah kawalan
Dedahkan arahan untuk menambah, menetapkan/mendapatkan parameter, memulakan, menghentikan dan memadamkan peranti. Menambah satu peranti merundingkan nr_hw_queues, queue_depth dan saiz penimbal I/O maksimum; parameter dibekukan sebelum bermula, selepas itu /dev/ublkb* didedahkan. Perkhidmatan ruang pengguna menyimpan ID peranti dan maklumat khusus backend.
Langkah 2: Reka bentuk permintaan satah data
Lapisan blok memperuntukkan tag unik bagi setiap giliran, dan perkhidmatan ruang pengguna mengaitkan permintaan melalui (queue, tag). Kawasan dipetakan yang tetap menerangkan ofset, panjang, operasi dan bendera. Perkhidmatan menerima pemberitahuan melalui laluan terus io_uring dan melakukan komit status serta bait yang selesai kembali ke kernel.
Langkah 3: Pilih mod per-I/O atau kelompok
Arahan per-I/O tradisional mudah difahami, dengan satu daemon memiliki setiap tag. Mod kelompok menyediakan dan melakukan komit beberapa permintaan bagi setiap giliran, mengurangkan overhed panggilan sistem (syscall), dan membolehkan tugas berkongsi kerja secara dinamik. Jangan campurkan set arahan semasa migrasi; bandingkan kependaman ekor (tail latency), CPU dan pengimbangan beban di bawah tekanan.
Langkah 4: Tentukan mesin keadaan pemulihan
Gunakan keadaan seperti running, quiescing, recovering dan failed. Apabila pelayan keluar, hentikan penghantaran I/O baharu, tunggu atau tandakan permintaan dalam penerbangan (in-flight), dan keluarkan START_USER_RECOVERY. REISSUE sesuai untuk backend yang bertolak ansur dengan penulisan pendua; FAIL_IO menjadikan permintaan dalam penerbangan dan masa hadapan gagal secara eksplisit daripada mereka-reka kejayaan.
on_server_exit:
quiesce_device()
if policy == REISSUE:
requeue_inflight()
else:
fail_inflight_and_future_io()
wait_new_server_ready()
end_user_recovery()Langkah 5: Kendalikan penimbal dan sifar-salin
Laluan biasa menggunakan penimbal ruang pengguna yang diperuntukkan lebih awal dan salinan kernel, memberikan sempadan yang lebih mudah. Sifar-salin memerlukan penimbal tetap yang didaftarkan, penjajaran segmen backend, dan perkhidmatan dipercayai yang mengisi data READ serta melaporkan kiraan bait dengan betul. Kesilapan boleh mendedahkan penimbal kernel yang tidak dimulakan, jadi hadkan keistimewaan dan audit jangka hayat.
Langkah 6: Bina kebenaran dan pengasingan bekas
Asingkan arahan kawalan berkeistimewaan daripada akses peranti. Dengan peranti tidak berkeistimewaan, kernel masih menyemak pemilikan peranti aksara yang berkaitan; sebuah bekas hanya boleh melihat nod perantinya sendiri. Backend ruang pengguna tidak boleh menerima kebenaran fail, rangkaian atau KMS di luar peranti sasarannya.
Langkah 7: Sahkan prestasi dan ketepatan
Ukur IOPS, kependaman p50/p99, kedalaman giliran, CPU, bait yang disalin dan masa pemulihan dengan fio atau beban kerja seperti pengeluaran. Suntik ranap pelayan, masa tamat backend, penulisan pendek, pemadaman peranti dan penyerahan pendua. Sahkan setiap permintaan selesai sekali atau gagal secara eksplisit mengikut dasar; uji sempadan dan checksum dalam kedua-dua mod salin dan sifar-salin.
Jawapan model
Saya akan membahagikan sistem seperti ublk kepada satah kawalan, lapisan blok kernel, satah data io_uring dan backend ruang pengguna. Kawalan merundingkan giliran dan penimbal sebelum bermula; data menjejaki permintaan melalui (queue, tag) dan mengesahkan status serta kiraan bait semasa selesai. Ranap pelayan mencetuskan rehat dan pemulihan: main semula hanya untuk backend yang boleh bertolak ansur dengannya, jika tidak, gagalkan. Menyalin adalah lalai; sifar-salin terhad kepada perkhidmatan yang dipercayai, dijajarkan dan dibenarkan. Pelepasan memerlukan ujian kependaman ekor, suntikan kerosakan, pengasingan kebenaran dan ketekalan pembuangan.
Kesilapan biasa
- Kesilapan: Membenarkan pelayan ruang pengguna menutup peranti secara langsung. → Sebab ia gagal: Permintaan dalam penerbangan dan keadaan giliran kernel kekal tidak ditentukan. → Pembetulan: Hentikan penghantaran, rehatkan, kemudian gunakan dasar pemulihan.
- Kesilapan: Mendayakan sifar-salin untuk setiap backend. → Sebab ia gagal: Jangka hayat penimbal, keistimewaan dan risiko data yang tidak dimulakan meningkat. → Pembetulan: Salin secara lalai dan kawal sifar-salin berdasarkan keupayaan dan audit.
- Kesilapan: Melindungi semua giliran dengan satu kunci global. → Sebab ia gagal: Konkurensi pelbagai giliran menjadi bersiri. → Pembetulan: Pecahkan (shard) keadaan mengikut giliran/tag dan ukur perebutan (contention).
- Kesilapan: Hanya mengukur daya pemprosesan (throughput) I/O yang sihat. → Sebab ia gagal: Ranap, penulisan pendek dan penulisan pendua menentukan ketekalan. → Pembetulan: Sertakan mesin keadaan pemulihan dan suntikan kerosakan dalam ujian penerimaan.
Soalan susulan dan respons
Bilakah anda perlu memilih I/O kelompok?
Pilih kelompok apabila overhed panggilan sistem dan pemberitahuan mendominasi, giliran mempunyai konkurensi yang mencukupi, dan tugas boleh berkongsi kerja secara dinamik. Mod tradisional lebih mudah dinyahpepijat apabila pemilikan per-I/O penting atau konkurensi adalah rendah.
Bagaimanakah REISSUE mengelakkan kerosakan data?
Dayakannya hanya untuk backend idempoten atau yang mengesan pendua, menggunakan ID permintaan, versi penulisan atau penyahduplikasian log. Jika keidempotenan tidak dapat dibuktikan, gagalkan dan biarkan lapisan atas pulih.
Bagaimanakah anda mengehadkan kesan keselamatan sifar-salin?
Ikatkan pendaftaran penimbal, pembatalan pendaftaran dan kebenaran peranti kepada satu perkhidmatan yang dipercayai; sahkan alamat, panjang, penjajaran dan bait penyelesaian; serta larang pemetaan boleh tulis yang dikongsi merentas penyewa.
Bagaimanakah anda mengekalkan ketekalan semasa pemadaman peranti?
Hentikan permintaan baharu, tunggu permintaan yang diserahkan selesai atau gagal, sahkan bahawa giliran ruang pengguna kosong, kemudian lepaskan nod peranti dan pemetaan. Rekodkan masa tamat sebagai kegagalan yang boleh dikesan dan bukannya menggugurkannya secara senyap.