Hello semua, kami berkongsi dengan anda bahagian kedua penerbitan "Sistem fail maya di Linux: mengapa ia diperlukan dan bagaimana ia berfungsi?" Anda boleh membaca bahagian pertama . Biar kami mengingatkan anda bahawa siri penerbitan ini ditetapkan masanya bertepatan dengan pelancaran aliran baharu pada kursus , yang bermula tidak lama lagi.
Cara memantau VFS menggunakan alat eBPF dan bcc
Cara paling mudah untuk memahami cara kernel beroperasi pada fail sysfs adalah untuk melihatnya dalam amalan, dan cara paling mudah untuk menonton ARM64 ialah menggunakan eBPF. eBPF (singkatan dari Berkeley Packet Filter) terdiri daripada mesin maya yang berjalan masuk , yang pengguna istimewa boleh meminta (query) daripada baris arahan. Sumber kernel memberitahu pembaca apa yang kernel boleh lakukan; menjalankan alat eBPF pada sistem yang dimuatkan menunjukkan perkara yang sebenarnya dilakukan oleh kernel.
Nasib baik, mula menggunakan eBPF agak mudah dengan bantuan alat , yang tersedia sebagai pakej daripada pengedaran umum dan didokumenkan secara terperinci . Alatan bcc ialah skrip Python dengan sisipan kecil kod C, yang bermaksud sesiapa yang biasa dengan kedua-dua bahasa boleh mengubah suainya dengan mudah. DALAM bcc/tools Terdapat 80 skrip Python, yang bermaksud kemungkinan besar pembangun atau pentadbir sistem akan dapat memilih sesuatu yang sesuai untuk menyelesaikan masalah tersebut.
Untuk mendapatkan sekurang-kurangnya idea cetek tentang kerja yang dilakukan oleh VFS pada sistem yang sedang berjalan, cuba vfscount atau vfsstat. Ini akan menunjukkan, katakan, bahawa berpuluh-puluh panggilan vfs_open() dan "rakannya" berlaku secara literal setiap saat.
vfsstat.pyialah skrip Python dengan sisipan kod C yang hanya mengira panggilan fungsi VFS.
Mari kita berikan contoh yang lebih remeh dan lihat apa yang berlaku apabila kita memasukkan pemacu kilat USB ke dalam komputer dan sistem mengesannya.
Menggunakan eBPF anda boleh melihat perkara yang berlaku di dalamnya
/sysapabila pemacu kilat USB dimasukkan. Contoh mudah dan kompleks ditunjukkan di sini.
Dalam contoh yang ditunjukkan di atas, bcc alat mencetak mesej apabila arahan dijalankan sysfs_create_files(). Kita nampak itu sysfs_create_files() telah dilancarkan menggunakan kworker strim sebagai tindak balas kepada fakta bahawa pemacu kilat telah dimasukkan, tetapi fail apa yang dicipta? Contoh kedua menunjukkan kuasa eBPF. Di sini trace.py Mencetak jejak belakang kernel (pilihan-K) dan nama fail yang telah dibuat sysfs_create_files(). Sisipan pernyataan tunggal ialah kod C yang merangkumi rentetan format yang mudah dikenali yang disediakan oleh skrip Python yang menjalankan LLVM penyusun tepat dalam masa. Ia menyusun baris ini dan melaksanakannya dalam mesin maya di dalam kernel. Tandatangan fungsi penuh sysfs_create_files () mesti dihasilkan semula dalam arahan kedua supaya rentetan format boleh merujuk kepada salah satu parameter. Ralat dalam sekeping kod C ini mengakibatkan ralat yang boleh dikenali daripada pengkompil C. Sebagai contoh, jika parameter -l diabaikan, anda akan melihat "Gagal menyusun teks BPF." Pembangun yang biasa dengan C dan Python akan menemui alatan tersebut bcc mudah untuk berkembang dan berubah.
Apabila pemacu USB dimasukkan, jejak belakang kernel akan menunjukkan bahawa PID 7711 ialah benang kworkeryang mencipta fail Β«eventsΒ» Π² sysfs. Sehubungan itu, panggilan daripada sysfs_remove_files() akan menunjukkan bahawa mengalih keluar pemacu mengakibatkan fail dipadamkan events, yang sepadan dengan konsep umum pengiraan rujukan. Pada masa yang sama, melihat sysfs_create_link () dengan eBPF semasa memasukkan pemacu USB akan menunjukkan bahawa sekurang-kurangnya 48 pautan simbolik telah dibuat.
Jadi apa gunanya fail acara? Penggunaan Untuk carian , menunjukkan apa yang menyebabkannya disk_add_events (), dan sama ada "media_change"Atau "eject_request" boleh direkodkan dalam fail acara. Di sini lapisan blok kernel memberitahu ruang pengguna bahawa "cakera" telah muncul dan dikeluarkan. Perhatikan betapa bermaklumat kaedah penyelidikan ini dengan memasukkan pemacu USB, berbanding dengan cuba memikirkan cara perkara berfungsi semata-mata daripada sumber.
Sistem fail akar baca sahaja membolehkan peranti terbenam
Sudah tentu, tiada siapa yang mematikan pelayan atau komputer mereka dengan menarik palam dari soket. Tapi kenapa? Ini kerana sistem fail yang dipasang pada peranti storan fizikal mungkin telah ketinggalan menulis dan struktur data yang merekodkan keadaannya mungkin tidak disegerakkan dengan menulis ke storan. Apabila ini berlaku, pemilik sistem perlu menunggu sehingga but seterusnya untuk melancarkan utiliti. fsck filesystem-recovery dan, dalam kes yang paling teruk, kehilangan data.
Walau bagaimanapun, kita semua tahu bahawa banyak peranti IoT, serta penghala, termostat dan kereta, kini menjalankan Linux. Kebanyakan peranti ini mempunyai sedikit atau tiada antara muka pengguna, dan tiada cara untuk mematikannya "bersih". Bayangkan memulakan kereta dengan bateri yang mati apabila kuasa ke unit kawalan sentiasa melompat ke atas dan ke bawah. Bagaimanakah sistem but tanpa masa yang lama fsckbila enjin akhirnya mula hidup? Dan jawapannya mudah. Peranti terbenam bergantung pada sistem fail akar (disingkat ro-rootfs (sistem fail akar baca sahaja)).
ro-rootfs menawarkan banyak faedah yang kurang jelas daripada keaslian. Satu kelebihan ialah perisian hasad tidak boleh menulis kepadanya /usr atau /lib, jika tiada proses Linux boleh menulis di sana. Satu lagi ialah sistem fail yang sebahagian besarnya tidak berubah adalah penting untuk sokongan medan peranti jauh, kerana kakitangan sokongan bergantung pada sistem tempatan yang secara nominalnya sama dengan sistem medan. Mungkin faedah yang paling penting (tetapi juga paling berbahaya) ialah ro-rootfs memaksa pembangun untuk memutuskan objek sistem mana yang akan tidak berubah pada peringkat reka bentuk sistem. Bekerja dengan ro-rootfs boleh menjadi janggal dan menyakitkan, kerana pembolehubah const selalunya dalam bahasa pengaturcaraan, tetapi faedahnya dengan mudah membenarkan overhed tambahan.
penciptaan rootfs Baca sahaja memerlukan sedikit usaha tambahan untuk pembangun terbenam, dan di sinilah VFS muncul. Linux memerlukan fail berada dalam /var boleh ditulis, dan sebagai tambahan, banyak aplikasi popular yang menjalankan sistem terbenam akan cuba membuat konfigurasi dot-files Π² $HOME. Satu penyelesaian untuk fail konfigurasi dalam direktori rumah biasanya adalah pra-menjana dan membinanya rootfs. Untuk /var Satu pendekatan yang mungkin adalah untuk melekapkannya pada partition boleh tulis yang berasingan, manakala / dipasang baca sahaja. Alternatif lain yang popular ialah menggunakan pelekap bind atau overlay.
Pelekap boleh dipaut dan boleh disusun, penggunaannya oleh bekas
Melaksanakan perintah man mount ialah cara terbaik untuk mempelajari tentang pelekap boleh diikat dan bertindih, yang memberikan pembangun dan pentadbir sistem keupayaan untuk mencipta sistem fail dalam satu laluan dan kemudian mendedahkannya kepada aplikasi dalam laluan lain. Untuk sistem terbenam, ini bermakna keupayaan untuk menyimpan fail dalam /var pada pemacu kilat baca sahaja, tetapi tindanan atau laluan pelekap yang boleh dipautkan daripada tmpfs Π² /var apabila memuatkan, ia akan membenarkan aplikasi menulis nota di sana (scrawl). Kali seterusnya anda menghidupkan perubahan kepada /var akan hilang. Lekap tindanan mewujudkan kesatuan antara tmpfs dan sistem fail asas dan membolehkan anda membuat perubahan yang nyata pada fail sedia ada dalam ro-tootf manakala pelekap yang boleh diikat boleh membuat yang baru kosong tmpfs folder kelihatan sebagai boleh ditulis dalam ro-rootfs cara. manakala overlayfs ini yang betul (proper) jenis sistem fail, pelekap boleh diikat dilaksanakan dalam .
Berdasarkan perihalan tindanan dan lekap yang boleh dipautkan, tiada siapa yang terkejut mereka digunakan secara aktif. Mari lihat apa yang berlaku apabila kita menggunakan untuk menjalankan bekas menggunakan alat mountsnoop daripada bcc.
Panggil system-nspawn memulakan bekas sambil berlari mountsnoop.py.
Mari lihat apa yang berlaku:
Pelancaran mountsnoop semasa bekas sedang "boot" menunjukkan bahawa masa jalan kontena sangat bergantung pada pelekap yang dipautkan (Hanya permulaan output panjang ditunjukkan).
ia adalah systemd-nspawn menyediakan fail terpilih dalam procfs ΠΈ sysfs hos ke bekas sebagai laluan kepadanya rootfs... Selain itu MS_BIND bendera yang menyediakan pelekap mengikat, beberapa bendera lain pada pelekap mentakrifkan hubungan antara perubahan pada ruang nama hos dan bekas. Sebagai contoh, pelekap yang dipautkan boleh melangkau perubahan ke /proc ΠΈ /sys ke dalam bekas, atau sembunyikannya bergantung pada panggilan.
Kesimpulan
Memahami kerja dalaman Linux boleh kelihatan seperti tugas yang mustahil, kerana kernel itu sendiri mengandungi sejumlah besar kod, mengetepikan aplikasi ruang pengguna Linux dan antara muka panggilan sistem dalam perpustakaan C seperti glibc. Satu cara untuk membuat kemajuan ialah membaca kod sumber satu subsistem kernel, dengan penekanan pada pemahaman panggilan sistem dan pengepala ruang pengguna, serta antara muka kernel dalaman utama, seperti jadual file_operations. Operasi fail menyediakan prinsip "semuanya adalah fail", menjadikannya sangat menyeronokkan untuk diuruskan. Fail sumber kernel C dalam direktori peringkat atas fs/ mempersembahkan pelaksanaan sistem fail maya, yang merupakan lapisan pembalut yang menyediakan keserasian yang luas dan agak mudah antara sistem fail dan peranti storan yang popular. Memautkan dan melekap tindanan melalui ruang nama Linux ialah keajaiban VFS yang membolehkan anda membuat bekas baca sahaja dan sistem fail akar. Digabungkan dengan pemeriksaan kod sumber, alat teras eBPF dan antara mukanya bcc
menjadikan penerokaan teras lebih mudah berbanding sebelum ini.
Kawan, tulis, adakah artikel ini berguna kepada anda? Mungkin anda mempunyai sebarang komen atau teguran? Dan mereka yang berminat dengan kursus Linux Administrator dijemput ke , yang akan berlangsung pada 18 April.
Sumber: www.habr.com