Halo semuanya, kami berbagi dengan Anda bagian kedua dari publikasi “Sistem file virtual di Linux: mengapa diperlukan dan bagaimana cara kerjanya?” Anda dapat membaca bagian pertama . Izinkan kami mengingatkan Anda bahwa rangkaian publikasi ini dijadwalkan bertepatan dengan peluncuran aliran baru pada kursus tersebut , yang akan segera dimulai.
Cara memonitor VFS menggunakan alat eBPF dan bcc
Cara termudah untuk memahami bagaimana kernel beroperasi pada file sysfs adalah dengan melihatnya dalam praktik, dan cara termudah untuk menonton ARM64 adalah dengan menggunakan eBPF. eBPF (kependekan dari Berkeley Packet Filter) terdiri dari mesin virtual yang berjalan , yang dapat diminta oleh pengguna yang memiliki hak istimewa (query) dari baris perintah. Sumber kernel memberi tahu pembaca apa yang dapat dilakukan kernel; menjalankan alat eBPF pada sistem yang dimuat menunjukkan apa yang sebenarnya dilakukan kernel.
Untungnya, memulai menggunakan eBPF cukup mudah dengan bantuan alat , yang tersedia sebagai paket dari distribusi umum dan didokumentasikan secara rinci . Peralatan bcc adalah skrip Python dengan sedikit sisipan kode C, yang berarti siapa pun yang akrab dengan kedua bahasa tersebut dapat dengan mudah memodifikasinya. DI DALAM bcc/tools Ada 80 skrip Python, yang berarti kemungkinan besar pengembang atau administrator sistem akan dapat memilih sesuatu yang cocok untuk menyelesaikan masalah.
Untuk mendapatkan setidaknya gambaran dangkal tentang pekerjaan apa yang dilakukan VFS pada sistem yang sedang berjalan, cobalah vfscount или vfsstat. Ini akan menunjukkan, katakanlah, lusinan panggilan vfs_open() dan “teman-temannya” terjadi setiap detik.
vfsstat.pyadalah skrip Python dengan sisipan kode C yang hanya menghitung panggilan fungsi VFS.
Mari kita berikan contoh yang lebih sepele dan lihat apa yang terjadi ketika kita memasukkan USB flash drive ke komputer dan sistem mendeteksinya.
Menggunakan eBPF Anda dapat melihat apa yang terjadi
/sysketika flash drive USB dimasukkan. Contoh sederhana dan kompleks ditampilkan di sini.
Dalam contoh yang ditunjukkan di atas, bcc alat mencetak pesan ketika perintah dijalankan sysfs_create_files(). Kami melihatnya sysfs_create_files() diluncurkan menggunakan kworker streaming sebagai respons terhadap fakta bahwa flash drive dimasukkan, tetapi file apa yang dibuat? Contoh kedua menunjukkan kekuatan eBPF. Di Sini trace.py Mencetak jejak balik kernel (opsi -K) dan nama file yang dibuat sysfs_create_files(). Penyisipan pernyataan tunggal adalah kode C yang menyertakan string format yang mudah dikenali yang disediakan oleh skrip Python yang menjalankan LLVM kompiler tepat waktu. Ini mengkompilasi baris ini dan menjalankannya di mesin virtual di dalam kernel. Tanda tangan fungsi penuh sysfs_create_files () harus direproduksi pada perintah kedua sehingga format string dapat merujuk ke salah satu parameter. Kesalahan pada bagian kode C ini mengakibatkan kesalahan yang dapat dikenali dari kompiler C. Misalnya, jika parameter -l dihilangkan, Anda akan melihat "Gagal mengkompilasi teks BPF". Pengembang yang akrab dengan C dan Python akan menemukan alatnya bcc mudah untuk diperluas dan diubah.
Ketika drive USB dimasukkan, penelusuran balik kernel akan menunjukkan bahwa PID 7711 adalah sebuah thread kworkeryang membuat file tersebut «events» в sysfs. Oleh karena itu, panggilan dari sysfs_remove_files() akan menunjukkan bahwa menghapus drive mengakibatkan file terhapus events, yang sesuai dengan konsep umum penghitungan referensi. Pada saat yang sama, melihat sysfs_create_link () dengan eBPF saat memasukkan drive USB akan menunjukkan bahwa setidaknya 48 tautan simbolik telah dibuat.
Jadi apa gunanya file acara? Penggunaan Untuk pencarian , menunjukkan apa penyebabnya disk_add_events (), dan lainnya "media_change"Atau "eject_request" dapat direkam dalam file acara. Di sini lapisan blok kernel menginformasikan ruang pengguna bahwa "disk" telah muncul dan dikeluarkan. Perhatikan betapa informatifnya metode penelitian ini dengan memasukkan drive USB, dibandingkan dengan mencoba mencari tahu cara kerja sesuatu hanya dari sumbernya.
Sistem file root read-only mengaktifkan perangkat yang tertanam
Tentu saja, tidak ada seorang pun yang mematikan server atau komputernya dengan mencabut steker dari stopkontak. Tapi kenapa? Hal ini karena sistem file yang terpasang pada perangkat penyimpanan fisik mungkin memiliki penulisan yang lambat, dan struktur data yang mencatat statusnya mungkin tidak disinkronkan dengan penulisan ke penyimpanan. Jika ini terjadi, pemilik sistem harus menunggu hingga boot berikutnya untuk meluncurkan utilitas. fsck filesystem-recovery dan, dalam kasus terburuk, kehilangan data.
Namun, kita semua tahu bahwa banyak perangkat IoT, serta router, termostat, dan mobil, kini menjalankan Linux. Banyak dari perangkat ini memiliki sedikit atau tidak ada antarmuka pengguna, dan tidak ada cara untuk mematikannya dengan "bersih". Bayangkan menghidupkan mobil dengan baterai mati ketika daya ke unit kontrol mati terus-menerus melompat-lompat. Bagaimana bisa sistemnya booting tanpa lama fsckkapan mesin akhirnya mulai hidup? Dan jawabannya sederhana. Perangkat yang tertanam bergantung pada sistem file root (disingkat ro-rootfs (sistem file root hanya-baca)).
ro-rootfs menawarkan banyak manfaat yang kurang jelas dibandingkan keasliannya. Salah satu keuntungannya adalah malware tidak dapat menulis ke dalamnya /usr или /lib, jika tidak ada proses Linux yang dapat menulis di sana. Alasan lainnya adalah bahwa sebagian besar sistem file yang tidak dapat diubah sangat penting untuk dukungan lapangan pada perangkat jarak jauh, karena personel pendukung bergantung pada sistem lokal yang secara nominal identik dengan sistem lapangan. Mungkin manfaat yang paling penting (tetapi juga paling berbahaya) adalah bahwa ro-rootfs memaksa pengembang untuk memutuskan objek sistem mana yang tidak dapat diubah pada tahap desain sistem. Bekerja dengan ro-rootf bisa terasa canggung dan menyakitkan, karena variabel const sering kali ada dalam bahasa pemrograman, namun manfaatnya dengan mudah membenarkan biaya tambahan.
penciptaan rootfs Read-only membutuhkan upaya ekstra untuk pengembang tertanam, dan di sinilah VFS berperan. Linux mengharuskan file berada di dalam /var dapat ditulis, dan sebagai tambahan, banyak aplikasi populer yang menjalankan sistem tertanam akan mencoba membuat konfigurasi dot-files в $HOME. Salah satu solusi untuk file konfigurasi di direktori home biasanya adalah dengan membuat dan membangunnya terlebih dahulu rootfs. Untuk /var Salah satu pendekatan yang mungkin adalah memasangnya pada partisi terpisah yang dapat ditulisi / dipasang hanya-baca. Alternatif populer lainnya adalah menggunakan pengikatan pengikat atau overlay.
Pemasangan yang dapat ditautkan dan ditumpuk, penggunaannya oleh kontainer
Eksekusi perintah man mount adalah cara terbaik untuk mempelajari tentang mount yang dapat diikat dan dihamparkan, yang memberikan kemampuan kepada pengembang dan administrator sistem untuk membuat sistem file di satu jalur dan kemudian mengeksposnya ke aplikasi di jalur lain. Untuk sistem tertanam, ini berarti kemampuan untuk menyimpan file di /var pada flash drive read-only, tetapi jalur pemasangan overlay atau yang dapat ditautkan dari tmpfs в /var saat memuat, itu akan memungkinkan aplikasi untuk menulis catatan di sana (coretan). Saat berikutnya Anda mengaktifkan perubahan /var akan hilang. Pemasangan overlay menciptakan kesatuan di antara keduanya tmpfs dan sistem file yang mendasarinya dan memungkinkan Anda membuat perubahan nyata pada file yang ada di dalamnya ro-tootf sedangkan mount yang dapat diikat dapat membuat yang baru menjadi kosong tmpfs folder terlihat sebagai dapat ditulisi ro-rootfs cara. Ketika overlayfs ini yang benar (proper) jenis sistem file, mount yang dapat diikat diimplementasikan di .
Berdasarkan deskripsi overlay dan linkable mount, tidak ada yang terkejut akan hal itu mereka digunakan secara aktif. Mari kita lihat apa yang terjadi saat kita menggunakannya untuk menjalankan container menggunakan alat tersebut mountsnoop dari bcc.
Tantangan system-nspawn memulai wadah saat berjalan mountsnoop.py.
Mari kita lihat apa yang terjadi:
Luncurkan mountsnoop saat container sedang "booting" menunjukkan bahwa runtime container sangat bergantung pada mount yang ditautkan (Hanya awal dari keluaran panjang yang ditampilkan).
Di sini systemd-nspawn menyediakan file yang dipilih procfs и sysfs host ke container sebagai jalur ke sana rootfs... Selain MS_BIND flag yang mengatur mount yang mengikat, beberapa flag lain pada mount menentukan hubungan antara perubahan pada namespace host dan container. Misalnya, pemasangan tertaut dapat melewati perubahan /proc и /sys ke dalam wadah, atau menyembunyikannya tergantung pada panggilannya.
Kesimpulan
Memahami cara kerja Linux mungkin tampak seperti tugas yang mustahil, karena kernel itu sendiri berisi sejumlah besar kode, kecuali aplikasi ruang pengguna Linux dan antarmuka panggilan sistem di perpustakaan C seperti glibc. Salah satu cara untuk membuat kemajuan adalah dengan membaca kode sumber dari satu subsistem kernel, dengan penekanan pada pemahaman panggilan sistem dan header ruang pengguna, serta antarmuka kernel internal utama, seperti tabel file_operations. Pengoperasian file memberikan prinsip "semuanya adalah file", sehingga sangat menyenangkan untuk dikelola. File sumber kernel C di direktori tingkat atas fs/ menyajikan implementasi sistem file virtual, yang merupakan lapisan pembungkus yang menyediakan kompatibilitas luas dan relatif sederhana antara sistem file populer dan perangkat penyimpanan. Menghubungkan dan memasang overlay melalui namespace Linux adalah keajaiban VFS yang memungkinkan pembuatan container read-only dan sistem file root. Dikombinasikan dengan pemeriksaan kode sumber, alat inti eBPF, dan antarmukanya bcc
membuat eksplorasi inti lebih mudah dari sebelumnya.
Teman, tulis, apakah artikel ini bermanfaat bagi Anda? Mungkin Anda punya komentar atau komentar? Dan mereka yang tertarik dengan kursus Administrator Linux diundang , yang akan berlangsung pada 18 April.
Sumber: www.habr.com