ລະບົບໄຟລ໌ virtual ໃນ Linux: ເປັນຫຍັງພວກມັນຕ້ອງການແລະເຮັດວຽກແນວໃດ? ພາກທີ 2

ສະບາຍດີທຸກຄົນ, ພວກເຮົາແບ່ງປັນກັບພາກສ່ວນທີສອງຂອງການພິມເຜີຍແຜ່ "ລະບົບໄຟລ໌ virtual ໃນ Linux: ເປັນຫຍັງພວກມັນຕ້ອງການແລະເຮັດວຽກແນວໃດ?" ທ່ານສາມາດອ່ານພາກທໍາອິດ ທີ່ນີ້. ຂໍໃຫ້ພວກເຮົາເຕືອນທ່ານວ່າຊຸດຂອງສິ່ງພິມນີ້ແມ່ນກໍານົດເວລາທີ່ຈະກົງກັບການເປີດຕົວການຖ່າຍທອດໃຫມ່ໃນຫຼັກສູດ. "ຜູ້ເບິ່ງແຍງລະບົບ Linux", ເຊິ່ງເລີ່ມຕົ້ນໃນໄວໆນີ້.

ວິທີການກວດສອບ VFS ໂດຍໃຊ້ eBPF ແລະເຄື່ອງມື bcc

ວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະເຂົ້າໃຈວິທີການ kernel ເຮັດວຽກຢູ່ໃນໄຟລ໌ sysfs ແມ່ນການເບິ່ງມັນໃນການປະຕິບັດ, ແລະວິທີທີ່ງ່າຍທີ່ສຸດທີ່ຈະເບິ່ງ ARM64 ແມ່ນການໃຊ້ eBPF. eBPF (ສັ້ນສໍາລັບ Berkeley Packet Filter) ປະກອບດ້ວຍເຄື່ອງ virtual ແລ່ນຢູ່ໃນ ຫຼັກ, ທີ່ຜູ້ໃຊ້ສິດທິພິເສດສາມາດຮ້ອງຂໍ (query) ຈາກ​ບັນ​ຊີ​ຄໍາ​ສັ່ງ​. ແຫຼ່ງ kernel ບອກຜູ້ອ່ານສິ່ງທີ່ kernel ສາມາດເຮັດໄດ້; ການເຮັດວຽກຂອງເຄື່ອງມື eBPF ໃນລະບົບທີ່ໂຫລດໄດ້ສະແດງໃຫ້ເຫັນວ່າ kernel ກໍາລັງເຮັດຫຍັງ.

ໂຊກດີ, ການເລີ່ມຕົ້ນໃຊ້ eBPF ແມ່ນຂ້ອນຂ້າງງ່າຍໂດຍການຊ່ວຍເຫຼືອຂອງເຄື່ອງມື bcc, ເຊິ່ງມີຢູ່ໃນຊຸດຈາກການແຈກຢາຍທົ່ວໄປ Linux ແລະ​ເປັນ​ເອ​ກະ​ສານ​ລາຍ​ລະ​ອຽດ​ Bernard Gregg. ເຄື່ອງມື bcc ແມ່ນ Python scripts ທີ່ມີການແຊກຂະຫນາດນ້ອຍຂອງລະຫັດ C, ຊຶ່ງຫມາຍຄວາມວ່າໃຜທີ່ຄຸ້ນເຄີຍກັບທັງສອງພາສາສາມາດດັດແປງໃຫ້ເຂົາເຈົ້າໄດ້ຢ່າງງ່າຍດາຍ. IN bcc/tools ມີ 80 ສະຄິບ Python, ຊຶ່ງຫມາຍຄວາມວ່າສ່ວນຫຼາຍແມ່ນຜູ້ພັດທະນາຫຼືຜູ້ເບິ່ງແຍງລະບົບຈະສາມາດເລືອກບາງສິ່ງບາງຢ່າງທີ່ເຫມາະສົມສໍາລັບການແກ້ໄຂບັນຫາ.
ເພື່ອໃຫ້ໄດ້ຢ່າງນ້ອຍຄວາມຄິດທີ່ເລິກເຊິ່ງກ່ຽວກັບສິ່ງທີ່ VFSs ເຮັດໃນລະບົບແລ່ນ, ພະຍາຍາມ vfscount ຫຼື vfsstat. ນີ້ຈະສະແດງໃຫ້ເຫັນ, ໃຫ້ເວົ້າວ່າ, ການໂທຫຼາຍສິບ vfs_open() ແລະ "ເພື່ອນຂອງລາວ" ເກີດຂື້ນທຸກໆວິນາທີ.

vfsstat.py ແມ່ນສະຄຣິບ Python ທີ່ມີລະຫັດ C ທີ່ນັບພຽງແຕ່ການເອີ້ນຟັງຊັນ VFS.

ໃຫ້ພວກເຮົາຍົກຕົວຢ່າງເລັກນ້ອຍແລະເບິ່ງວ່າມີຫຍັງເກີດຂື້ນເມື່ອພວກເຮົາໃສ່ USB flash drive ເຂົ້າໄປໃນຄອມພິວເຕີແລະລະບົບກວດພົບມັນ.

ການນໍາໃຊ້ eBPF ທ່ານສາມາດເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນໃນ /sysເມື່ອໃສ່ USB flash drive. ຕົວຢ່າງທີ່ງ່າຍດາຍແລະສະລັບສັບຊ້ອນແມ່ນສະແດງຢູ່ທີ່ນີ້.

ໃນຕົວຢ່າງທີ່ສະແດງຂ້າງເທິງ, bcc ເຄື່ອງມື trace.py ພິມຂໍ້ຄວາມເມື່ອຄຳສັ່ງຖືກແລ່ນ sysfs_create_files(). ພວກເຮົາເຫັນວ່າ sysfs_create_files() ຖືກເປີດຕົວໂດຍໃຊ້ kworker stream ເພື່ອຕອບສະຫນອງຄວາມຈິງທີ່ວ່າ flash drive ໄດ້ຖືກໃສ່, ແຕ່ວ່າໄຟລ໌ໃດທີ່ຖືກສ້າງຂື້ນ? ຕົວຢ່າງທີສອງສະແດງໃຫ້ເຫັນເຖິງພະລັງງານຂອງ eBPF. ທີ່ນີ້ trace.py ພິມ kernel backtrace (-K ທາງເລືອກ) ແລະຊື່ຂອງໄຟລ໌ທີ່ຖືກສ້າງຂຶ້ນ sysfs_create_files(). ການໃສ່ຄຳຖະແຫຼງດຽວແມ່ນລະຫັດ C ທີ່ປະກອບມີສະຕຣິງຮູບແບບທີ່ສາມາດຮັບຮູ້ໄດ້ງ່າຍທີ່ສະໜອງໃຫ້ໂດຍສະຄຣິບ Python ທີ່ແລ່ນ LLVM compiler ພຽງ​ແຕ່​ໃນ​ເວ​ລາ​. ມັນລວບລວມເສັ້ນນີ້ແລະປະຕິບັດມັນຢູ່ໃນເຄື່ອງ virtual ພາຍໃນ kernel. ລາຍເຊັນຟັງຊັນເຕັມ sysfs_create_files () ຕ້ອງໄດ້ຮັບການຜະລິດຄືນໃຫມ່ໃນຄໍາສັ່ງທີສອງເພື່ອໃຫ້ສະຕຣິງຮູບແບບສາມາດອ້າງອີງໃສ່ຫນຶ່ງຂອງພາລາມິເຕີ. ຄວາມຜິດພາດຂອງລະຫັດ C ນີ້ສົ່ງຜົນໃຫ້ເກີດຄວາມຜິດພາດທີ່ຮັບຮູ້ໄດ້ຈາກ C compiler. ຕົວຢ່າງ, ຖ້າພາລາມິເຕີ -l ຖືກລະເວັ້ນ, ທ່ານຈະເຫັນ "ລົ້ມເຫລວໃນການລວບລວມຂໍ້ຄວາມ BPF." ຜູ້ພັດທະນາທີ່ຄຸ້ນເຄີຍກັບ C ແລະ Python ຈະຊອກຫາເຄື່ອງມື bcc ງ່າຍທີ່ຈະຂະຫຍາຍແລະປ່ຽນແປງ.

ເມື່ອໄດ USB ຖືກໃສ່, kernel backtrace ຈະສະແດງໃຫ້ເຫັນວ່າ PID 7711 ເປັນ thread. kworkerທີ່ສ້າງໄຟລ໌ «events» в sysfs. ຕາມ​ນັ້ນ​ແລ້ວ, ຄຳ​ຮຽກຮ້ອງ​ຈາກ sysfs_remove_files() ຈະ​ສະ​ແດງ​ໃຫ້​ເຫັນ​ວ່າ​ການ​ລົບ drive ໄດ້​ເຮັດ​ໃຫ້​ໄຟລ​໌​ໄດ້​ຖືກ​ລົບ​ events, ເຊິ່ງກົງກັບແນວຄວາມຄິດທົ່ວໄປຂອງການນັບອ້າງອີງ. ໃນເວລາດຽວກັນ, ການເບິ່ງ sysfs_create_link () ກັບ eBPF ໃນຂະນະທີ່ໃສ່ໄດ USB ຈະສະແດງໃຫ້ເຫັນວ່າຢ່າງຫນ້ອຍ 48 ການເຊື່ອມຕໍ່ສັນຍາລັກໄດ້ຖືກສ້າງຂື້ນ.

ດັ່ງນັ້ນຈຸດຂອງໄຟລ໌ເຫດການແມ່ນຫຍັງ? ການ​ນໍາ​ໃຊ້ cscope ສໍາລັບການຄົ້ນຫາ __device_add_disk(), ສະແດງໃຫ້ເຫັນສິ່ງທີ່ມັນເຮັດໃຫ້ເກີດ disk_add_events (), ແລະບໍ່ວ່າຈະ "media_change", ຫຼື "eject_request" ສາມາດບັນທຶກໄວ້ໃນໄຟລ໌ເຫດການ. ທີ່ນີ້ kernel block layer ແຈ້ງໃຫ້ userspace ວ່າ "disk" ໄດ້ປາກົດແລະ ejected. ໃຫ້ສັງເກດວ່າວິທີການຄົ້ນຄ້ວານີ້ແມ່ນໃຫ້ຂໍ້ມູນແນວໃດໂດຍການໃສ່ໄດ USB, ເມື່ອທຽບກັບການພະຍາຍາມຄົ້ນຫາວິທີການເຮັດວຽກຢ່າງດຽວຈາກແຫຼ່ງ.

ລະບົບໄຟລ໌ຮາກແບບອ່ານຢ່າງດຽວເປີດໃຊ້ອຸປະກອນທີ່ຝັງໄວ້

ແນ່ນອນ, ບໍ່ມີໃຜປິດເຄື່ອງແມ່ຂ່າຍຫຼືຄອມພິວເຕີຂອງພວກເຂົາໂດຍການດຶງສຽບຈາກເຕົ້າຮັບ. ແຕ່ເປັນຫຍັງ? ນີ້ແມ່ນຍ້ອນວ່າລະບົບໄຟລ໌ທີ່ຕິດຕັ້ງຢູ່ໃນອຸປະກອນການເກັບຮັກສາທາງດ້ານຮ່າງກາຍອາດຈະຊັກຊ້າການຂຽນ, ແລະໂຄງສ້າງຂໍ້ມູນທີ່ບັນທຶກສະຖານະຂອງພວກເຂົາອາດຈະບໍ່ຖືກ synchronized ກັບ writes ກັບບ່ອນເກັບຮັກສາ. ເມື່ອສິ່ງດັ່ງກ່າວເກີດຂຶ້ນ, ເຈົ້າຂອງລະບົບຕ້ອງລໍຖ້າຈົນກ່ວາການບູດຄັ້ງຕໍ່ໄປເພື່ອເປີດນໍາໃຊ້ປະໂຫຍດ. fsck filesystem-recovery ແລະ, ໃນກໍລະນີຮ້າຍແຮງທີ່ສຸດ, ການສູນເສຍຂໍ້ມູນ.

ຢ່າງໃດກໍຕາມ, ພວກເຮົາທຸກຄົນຮູ້ວ່າອຸປະກອນ IoT ຈໍານວນຫຼາຍ, ເຊັ່ນດຽວກັນກັບ routers, ເຄື່ອງຄວບຄຸມອຸນຫະພູມແລະລົດ, ໃນປັດຈຸບັນດໍາເນີນການ Linux. ຫຼາຍໆອຸປະກອນເຫຼົ່ານີ້ມີສ່ວນຕິດຕໍ່ຜູ້ໃຊ້ພຽງເລັກນ້ອຍຫາບໍ່ມີ, ແລະບໍ່ມີວິທີທີ່ຈະປິດພວກມັນ "ສະອາດ." ຈິນຕະນາການເລີ່ມຕົ້ນລົດທີ່ມີຫມໍ້ໄຟທີ່ຕາຍແລ້ວໃນເວລາທີ່ພະລັງງານກັບຫນ່ວຍຄວບຄຸມແມ່ນ Linux ໂດດຂຶ້ນແລະລົງຢ່າງຕໍ່ເນື່ອງ. ມັນ​ເປັນ​ແນວ​ໃດ​ທີ່​ລະ​ບົບ​ເກີບ​ໂດຍ​ບໍ່​ມີ​ການ​ຍາວ​ fsckເຄື່ອງຈັກເລີ່ມແລ່ນເມື່ອໃດ? ແລະຄໍາຕອບແມ່ນງ່າຍດາຍ. ອຸປະກອນຝັງແມ່ນອີງໃສ່ລະບົບໄຟລ໌ຮາກ ພຽງ​ແຕ່​ສໍາ​ລັບ​ການ​ອ່ານ​ (ຫຍໍ້ ro-rootfs (ລະບົບໄຟລ໌ຮາກອ່ານເທົ່ານັ້ນ)).

ro-rootfs ສະເໜີຜົນປະໂຫຍດຫຼາຍຢ່າງທີ່ບໍ່ຊັດເຈນກວ່າຄວາມແທ້ຈິງ. ປະໂຫຍດອັນຫນຶ່ງແມ່ນວ່າ malware ບໍ່ສາມາດຂຽນໄປຫາ /usr ຫຼື /lib, ຖ້າບໍ່ມີຂະບວນການ Linux ສາມາດຂຽນຢູ່ທີ່ນັ້ນ. ອີກປະການຫນຶ່ງແມ່ນວ່າລະບົບໄຟລ໌ທີ່ບໍ່ປ່ຽນແປງໄດ້ຢ່າງຫຼວງຫຼາຍແມ່ນສໍາຄັນສໍາລັບການສະຫນັບສະຫນູນພາກສະຫນາມຂອງອຸປະກອນຫ່າງໄກສອກຫຼີກ, ນັບຕັ້ງແຕ່ພະນັກງານສະຫນັບສະຫນູນແມ່ນອີງໃສ່ລະບົບທ້ອງຖິ່ນທີ່ມີລັກສະນະດຽວກັນກັບລະບົບພາກສະຫນາມ. ບາງທີຜົນປະໂຫຍດທີ່ສໍາຄັນທີ່ສຸດ (ແຕ່ຍັງ insidious ຫຼາຍທີ່ສຸດ) ແມ່ນວ່າ ro-rootfs ບັງຄັບໃຫ້ນັກພັດທະນາຕັດສິນໃຈວ່າວັດຖຸລະບົບໃດທີ່ບໍ່ສາມາດປ່ຽນແປງໄດ້ໃນຂັ້ນຕອນການອອກແບບຂອງລະບົບ. ການເຮັດວຽກກັບ ro-rootfs ສາມາດເຮັດໃຫ້ງຸ່ມງ່າມແລະເຈັບປວດ, ຍ້ອນວ່າຕົວແປ const ມັກຈະຢູ່ໃນພາສາການຂຽນໂປລແກລມ, ແຕ່ຜົນປະໂຫຍດຂອງພວກມັນພຽງແຕ່ເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍເພີ່ມເຕີມ.

ການສ້າງ rootfs Read-only ຮຽກຮ້ອງໃຫ້ມີຄວາມພະຍາຍາມພິເສດບາງຢ່າງສໍາລັບນັກພັດທະນາທີ່ຝັງໄວ້, ແລະນີ້ແມ່ນບ່ອນທີ່ VFS ເຂົ້າມາໃນຮູບ. Linux ຮຽກຮ້ອງໃຫ້ໄຟລ໌ຢູ່ໃນ /var ສາມາດຂຽນໄດ້, ແລະນອກຈາກນັ້ນ, ແອັບພລິເຄຊັນທີ່ນິຍົມຫຼາຍທີ່ໃຊ້ລະບົບຝັງຕົວຈະພະຍາຍາມສ້າງການຕັ້ງຄ່າ dot-files в $HOME. ການແກ້ໄຂຫນຶ່ງສໍາລັບໄຟລ໌ການຕັ້ງຄ່າໃນໄດເລກະທໍລີເຮືອນແມ່ນປົກກະຕິແລ້ວການສ້າງກ່ອນແລະສ້າງໃຫ້ເຂົາເຈົ້າເຂົ້າໄປໃນ rootfs. ສຳ ລັບ /var ວິທີຫນຶ່ງທີ່ເປັນໄປໄດ້ແມ່ນການຕິດຕັ້ງມັນຢູ່ໃນການແບ່ງປັນທີ່ສາມາດຂຽນໄດ້ແຍກຕ່າງຫາກ, ໃນຂະນະທີ່ / ຕິດຕັ້ງແບບອ່ານເທົ່ານັ້ນ. ທາງເລືອກອື່ນທີ່ເປັນທີ່ນິຍົມແມ່ນການໃຊ້ bind ຫຼື overlay mounts.

mounts ເຊື່ອມຕໍ່ແລະ stackable, ການນໍາໃຊ້ຂອງເຂົາເຈົ້າໂດຍບັນຈຸ

ການ​ປະ​ຕິ​ບັດ​ຄໍາ​ສັ່ງ​ man mount ເປັນວິທີທີ່ດີທີ່ສຸດທີ່ຈະຮຽນຮູ້ກ່ຽວກັບ mounts bindable ແລະ overlayable, ເຊິ່ງໃຫ້ນັກພັດທະນາແລະຜູ້ບໍລິຫານລະບົບສາມາດສ້າງລະບົບໄຟລ໌ໃນເສັ້ນທາງຫນຶ່ງແລະຫຼັງຈາກນັ້ນເປີດເຜີຍມັນກັບແອັບພລິເຄຊັນໃນອີກ. ສໍາລັບລະບົບຝັງ, ນີ້ຫມາຍຄວາມວ່າຄວາມສາມາດໃນການເກັບຮັກສາໄຟລ໌ໃນ /var ຢູ່ໃນ flash drive ທີ່ອ່ານໄດ້ຢ່າງດຽວ, ແຕ່ເປັນ overlay ຫຼື linkable mount path ຈາກ tmpfs в /var ເມື່ອໂຫລດ, ມັນຈະຊ່ວຍໃຫ້ແອັບພລິເຄຊັນຂຽນບັນທຶກຢູ່ທີ່ນັ້ນ (ກວາດລ້າ). ໃນຄັ້ງຕໍ່ໄປທີ່ທ່ານເປີດການປ່ຽນແປງ /var ຈະສູນເສຍ. mount overlay ສ້າງສະຫະພາບລະຫວ່າງ tmpfs ແລະລະບົບໄຟລ໌ທີ່ຕິດພັນແລະອະນຸຍາດໃຫ້ທ່ານເພື່ອເຮັດໃຫ້ການປ່ຽນແປງ ostensible ກັບໄຟລ໌ທີ່ມີຢູ່ແລ້ວໃນ ro-tootf ໃນຂະນະທີ່ mountable bindable ສາມາດເຮັດໃຫ້ອັນໃຫມ່ຫວ່າງເປົ່າ tmpfs ໂຟນເດີທີ່ເຫັນໄດ້ເປັນລາຍລັກອັກສອນໃນ ro-rootfs ວິທີ. ໃນຂະນະທີ່ overlayfs ນີ້​ແມ່ນ​ຫນຶ່ງ​ທີ່​ຖືກ​ຕ້ອງ (proper) ປະເພດລະບົບໄຟລ໌, mountable bindable ແມ່ນປະຕິບັດໃນ VFS namespace.

ອີງຕາມຄໍາອະທິບາຍຂອງ overlay ແລະ mount ເຊື່ອມຕໍ່, ບໍ່ມີໃຜແປກໃຈວ່າ ກ່ອງບັນຈຸ Linux ເຂົາເຈົ້າໄດ້ຖືກນໍາໃຊ້ຢ່າງຫ້າວຫັນ. ໃຫ້ເຮົາເບິ່ງວ່າເກີດຫຍັງຂຶ້ນເມື່ອເຮົາໃຊ້ systemd-n ການຜະລິດ ເພື່ອດໍາເນີນການບັນຈຸໂດຍໃຊ້ເຄື່ອງມື mountsnoop ຈາກ bcc.

ທ້າທາຍ system-nspawn ເລີ່ມຕົ້ນຕູ້ຄອນເທນເນີໃນຂະນະທີ່ແລ່ນ mountsnoop.py.

ມາເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນ:

ເປີດຕົວ mountsnoop ໃນຂະນະທີ່ container ແມ່ນ "booting" ສະແດງໃຫ້ເຫັນວ່າ runtime ຂອງ container ແມ່ນສູງຂື້ນກັບ mount ທີ່ຖືກເຊື່ອມຕໍ່ (ພຽງແຕ່ຈຸດເລີ່ມຕົ້ນຂອງຜົນຜະລິດຍາວແມ່ນສະແດງໃຫ້ເຫັນ).

ມັນເປັນ systemd-nspawn ໃຫ້ໄຟລ໌ທີ່ເລືອກໃນ procfs и sysfs host to container ເປັນເສັ້ນທາງໄປຫາມັນ rootfs... ນອກຈາກ MS_BIND ທຸງທີ່ຕັ້ງ mount binding, ບາງທຸງອື່ນໆກ່ຽວກັບ mount ໄດ້ກໍານົດຄວາມສໍາພັນລະຫວ່າງການປ່ຽນແປງກັບ host ແລະ container namespaces. ຕົວຢ່າງ, mount ທີ່ເຊື່ອມຕໍ່ສາມາດຂ້າມການປ່ຽນແປງໄປ /proc и /sys ເຂົ້າໄປໃນຖັງ, ຫຼືເຊື່ອງພວກມັນຂຶ້ນກັບການໂທ.

ສະຫລຸບ

ຄວາມເຂົ້າໃຈໃນການເຮັດວຽກພາຍໃນຂອງ Linux ສາມາດເບິ່ງຄືວ່າເປັນວຽກທີ່ເປັນໄປບໍ່ໄດ້, ເນື່ອງຈາກວ່າ kernel ຕົວຂອງມັນເອງມີລະຫັດຈໍານວນຫຼວງຫຼາຍ, ປ່ອຍໃຫ້ຄໍາຮ້ອງສະຫມັກພື້ນທີ່ຜູ້ໃຊ້ Linux ແລະການໂຕ້ຕອບການໂທລະບົບໃນຫ້ອງສະຫມຸດ C ເຊັ່ນ: glibc. ວິທີຫນຶ່ງທີ່ຈະເຮັດໃຫ້ຄວາມຄືບຫນ້າແມ່ນການອ່ານລະຫັດແຫຼ່ງຂອງລະບົບຍ່ອຍ kernel, ໂດຍເນັ້ນໃສ່ຄວາມເຂົ້າໃຈກ່ຽວກັບການໂທລະບົບແລະສ່ວນຫົວຂອງພື້ນທີ່ຂອງຜູ້ໃຊ້, ເຊັ່ນດຽວກັນກັບການໂຕ້ຕອບ kernel ພາຍໃນຕົ້ນຕໍ, ເຊັ່ນ: ຕາຕະລາງ. file_operations. ການດໍາເນີນງານຂອງໄຟລ໌ສະຫນອງຫຼັກການ "ທຸກສິ່ງທຸກຢ່າງເປັນໄຟລ໌", ເຮັດໃຫ້ມັນມີຄວາມສຸກໂດຍສະເພາະໃນການຄຸ້ມຄອງ. ໄຟລ໌ຕົ້ນສະບັບ C kernel ໃນໄດເລກະທໍລີລະດັບສູງສຸດ fs/ ນໍາສະເຫນີການປະຕິບັດຂອງລະບົບໄຟລ໌ virtual, ເຊິ່ງເປັນຊັ້ນ wrapper ທີ່ສະຫນອງຄວາມເຂົ້າກັນໄດ້ຢ່າງກວ້າງຂວາງແລະຂ້ອນຂ້າງງ່າຍດາຍລະຫວ່າງລະບົບໄຟລ໌ທີ່ນິຍົມແລະອຸປະກອນເກັບຮັກສາ. ການເຊື່ອມໂຍງແລະການວາງຊ້ອນກັນຜ່ານ namespaces Linux ແມ່ນ magic ຂອງ VFS ທີ່ເຮັດໃຫ້ການສ້າງ containers ແບບອ່ານເທົ່ານັ້ນແລະລະບົບໄຟລ໌ຮາກ. ສົມທົບກັບການກວດສອບລະຫັດແຫຼ່ງ, ເຄື່ອງມືຫຼັກ eBPF ແລະການໂຕ້ຕອບຂອງມັນ bcc
ເຮັດ​ໃຫ້​ການ​ສໍາ​ຫຼວດ​ຫຼັກ​ງ່າຍ​ຂຶ້ນ​ກ​່​ວາ​ທີ່​ເຄີຍ​.

ເພື່ອນໆ, ຂຽນ, ບົດຄວາມນີ້ເປັນປະໂຫຍດກັບທ່ານບໍ? ບາງທີເຈົ້າມີຄວາມຄິດເຫັນຫຼືຂໍ້ສັງເກດ? ແລະຜູ້ທີ່ມີຄວາມສົນໃຈໃນຫຼັກສູດ Linux Administrator ແມ່ນເຊີນເຂົ້າຮ່ວມ ມື້ເປີດ​ເຊິ່ງຈະ​ໄຂ​ຂຶ້ນ​ໃນ​ວັນ​ທີ 18 ​ເມສາ​ນີ້.

ສ່ວນ ທຳ ອິດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com