ვირტუალური ფაილური სისტემები Linux-ში: რატომ არის საჭირო და როგორ მუშაობს ისინი? Ნაწილი 2

მოგესალმებით ყველას, ჩვენ გაგიზიარებთ პუბლიკაციის მეორე ნაწილს "ვირტუალური ფაილური სისტემები Linux-ში: რატომ არის საჭირო და როგორ მუშაობს ისინი?" შეგიძლიათ წაიკითხოთ პირველი ნაწილი აქ. შეგახსენებთ, რომ პუბლიკაციების ეს სერია დროულად ემთხვევა კურსზე ახალი ნაკადის დაწყებას "ლინუქსის ადმინისტრატორი", რომელიც ძალიან მალე იწყება.

როგორ დავაკვირდეთ VFS-ს eBPF და bcc ინსტრუმენტების გამოყენებით

უმარტივესი გზა იმის გასაგებად, თუ როგორ მუშაობს ბირთვი ფაილებზე sysfs არის მისი პრაქტიკაში დანახვა და ARM64-ის ყურების ყველაზე მარტივი გზა eBPF-ის გამოყენებაა. eBPF (ბერკლის პაკეტის ფილტრის შემოკლება) შედგება ვირტუალური მანქანისგან, რომელიც მუშაობს ბირთვი, რომელიც პრივილეგირებულ მომხმარებლებს შეუძლიათ მოითხოვონ (query) ბრძანების ხაზიდან. ბირთვის წყაროები ეუბნებიან მკითხველს, რა შეუძლია ბირთვს; დატვირთულ სისტემაზე eBPF ინსტრუმენტების გაშვება აჩვენებს, თუ რას აკეთებს სინამდვილეში ბირთვი.

საბედნიეროდ, eBPF-ის გამოყენების დაწყება საკმაოდ მარტივია ინსტრუმენტების დახმარებით ძვ.წ., რომლებიც ხელმისაწვდომია პაკეტების სახით ზოგადი განაწილებიდან Linux და დეტალურად არის დოკუმენტირებული ბერნარდ გრეგი. ხელსაწყოები bcc არის პითონის სკრიპტები C კოდის მცირე ჩანართებით, რაც ნიშნავს, რომ ნებისმიერს, ვინც ორივე ენას იცნობს, ადვილად შეუძლია მათი შეცვლა. IN bcc/tools არსებობს 80 პითონის სკრიპტი, რაც ნიშნავს, რომ დიდი ალბათობით დეველოპერს ან სისტემის ადმინისტრატორს შეეძლება აირჩიოს რაიმე შესაფერისი პრობლემის გადასაჭრელად.
მინიმუმ ზედაპირული წარმოდგენის მისაღებად, თუ რას აკეთებენ VFS-ები გაშვებულ სისტემაზე, სცადეთ vfscount ან vfsstat. ეს აჩვენებს, ვთქვათ, რომ ათობით ზარი vfs_open() და "მისი მეგობრები" ხდება ფაქტიურად ყოველ წამს.

vfsstat.py არის პითონის სკრიპტი C კოდის ჩანართებით, რომელიც უბრალოდ ითვლის VFS ფუნქციის ზარებს.

მოდით მოვიყვანოთ უფრო ტრივიალური მაგალითი და ვნახოთ, რა ხდება, როდესაც USB ფლეშ დრაივს ჩავსვამთ კომპიუტერში და სისტემა აღმოაჩენს მას.

eBPF-ის გამოყენებით შეგიძლიათ ნახოთ რა ხდება მასში /sysროდესაც ჩასმულია USB ფლეშ დრაივი. აქ მოცემულია მარტივი და რთული მაგალითი.

ზემოთ მოყვანილ მაგალითში, bcc ინსტრუმენტი კვალი.py ბეჭდავს შეტყობინებას ბრძანების გაშვებისას sysfs_create_files(). ჩვენ ამას ვხედავთ sysfs_create_files() გამოყენებით დაიწყო kworker ნაკადი იმის საპასუხოდ, რომ ფლეშ დრაივი იყო ჩასმული, მაგრამ რა ფაილი შეიქმნა? მეორე მაგალითი გვიჩვენებს eBPF-ის ძალას. Აქ trace.py ბეჭდავს kernel backtrace-ს (-K ვარიანტი) და შექმნილი ფაილის სახელს sysfs_create_files(). ერთი განცხადების ჩასმა არის C კოდი, რომელიც მოიცავს ადვილად ცნობად ფორმატის სტრიქონს, რომელიც მოწოდებულია Python სკრიპტით, რომელიც აწარმოებს LLVM-ს. მხოლოდ დროული შემდგენელი. ის ადგენს ამ ხაზს და ახორციელებს მას ბირთვის შიგნით ვირტუალურ მანქანაში. სრული ფუნქციის ხელმოწერა sysfs_create_files () უნდა იყოს რეპროდუცირებული მეორე ბრძანებაში ისე, რომ ფორმატის სტრიქონი შეიძლება მიუთითებდეს ერთ-ერთ პარამეტრზე. C კოდის ამ ნაწილში შეცდომები იწვევს C შემდგენლის ცნობად შეცდომებს. მაგალითად, თუ -l პარამეტრი გამოტოვებულია, ნახავთ "BPF ტექსტის შედგენა ვერ მოხერხდა". დეველოპერები, რომლებიც იცნობენ C და Python-ს, იპოვიან ინსტრუმენტებს bcc ადვილად გაფართოება და შეცვლა.

როდესაც USB დრაივი ჩასმულია, ბირთვის უკან დახევა აჩვენებს, რომ PID 7711 არის ძაფი kworkerრომელმაც შექმნა ფაილი «events» в sysfs. შესაბამისად, ზარი sysfs_remove_files() აჩვენებს, რომ დისკის წაშლის შედეგად ფაილი წაიშალა events, რომელიც შეესაბამება მითითების დათვლის ზოგად კონცეფციას. ამავე დროს, ყურება sysfs_create_link () eBPF-ით USB დისკის ჩასმისას გამოჩნდება, რომ შეიქმნა მინიმუმ 48 სიმბოლური ბმული.

რა აზრი აქვს მოვლენების ფაილს? გამოყენება cscope საძიებლად __device_add_disk(), აჩვენებს რას იწვევს disk_add_events (), და არც "media_change"ან "eject_request" შეიძლება ჩაიწეროს მოვლენის ფაილში. აქ ბირთვის ბლოკის ფენა აცნობებს მომხმარებლის სივრცეს, რომ "დისკი" გამოჩნდა და ამოღებული. გაითვალისწინეთ, რამდენად ინფორმაციულია კვლევის ეს მეთოდი USB დისკის ჩასმით, ვიდრე იმის გარკვევასთან შედარებით, თუ როგორ მუშაობს ყველაფერი მხოლოდ წყაროდან.

მხოლოდ წაკითხვადი root ფაილური სისტემები რთავს ჩაშენებულ მოწყობილობებს

რა თქმა უნდა, არავინ თიშავს სერვერს ან მის კომპიუტერს შტეფსელიდან ამოღებით. Მაგრამ რატომ? ეს იმიტომ ხდება, რომ ფიზიკურ შესანახ მოწყობილობებზე დამონტაჟებულ ფაილურ სისტემებს შეიძლება ჰქონდეთ დაგვიანებული ჩაწერა და მონაცემთა სტრუქტურები, რომლებიც ჩაწერენ მათ მდგომარეობას, შეიძლება არ იყოს სინქრონიზებული საცავში ჩაწერებთან. როდესაც ეს მოხდება, სისტემის მფლობელებმა უნდა დაელოდონ შემდეგ ჩატვირთვას პროგრამის გასაშვებად. fsck filesystem-recovery და, უარეს შემთხვევაში, მონაცემების დაკარგვა.

თუმცა, ჩვენ ყველამ ვიცით, რომ ბევრი IoT მოწყობილობა, ისევე როგორც მარშრუტიზატორები, თერმოსტატები და მანქანები, ახლა მუშაობს Linux-ზე. ბევრ ამ მოწყობილობას აქვს მცირე ან საერთოდ არ აქვს მომხმარებლის ინტერფეისი და არ არსებობს მათი "სუფთა" გამორთვის საშუალება. წარმოიდგინეთ, აწარმოებთ მანქანას მკვდარი ბატარეით, როდესაც საკონტროლო განყოფილებას მიეწოდება Linux გამუდმებით მაღლა და ქვევით ხტუნავს. როგორ ხდება, რომ სისტემა ჩაიტვირთება ხანგრძლივი გარეშე fsckროდის იწყებს ძრავა საბოლოოდ მუშაობას? და პასუხი მარტივია. ჩაშენებული მოწყობილობები ეყრდნობა root ფაილურ სისტემას მხოლოდ კითხვისთვის (შემოკლებით ro-rootfs (მხოლოდ წაკითხვადი root ფაილური სისტემა)).

ro-rootfs გთავაზობთ ბევრ სარგებელს, რომლებიც ნაკლებად აშკარაა, ვიდრე ავთენტურობა. ერთი უპირატესობა ის არის, რომ მავნე პროგრამას არ შეუძლია დაწეროს /usr ან /lib, თუ ლინუქსის პროცესს არ შეუძლია იქ ჩაწერა. მეორე ის არის, რომ დიდწილად შეუცვლელი ფაილური სისტემა კრიტიკულია დისტანციური მოწყობილობების საველე მხარდაჭერისთვის, რადგან დამხმარე პერსონალი ეყრდნობა ადგილობრივ სისტემებს, რომლებიც ნომინალურად იდენტურია საველე სისტემებისთვის. ალბათ ყველაზე მნიშვნელოვანი (მაგრამ ყველაზე მზაკვრული) სარგებელი არის ის, რომ ro-rootfs აიძულებს დეველოპერებს გადაწყვიტონ, რომელი სისტემის ობიექტები იქნება უცვლელი სისტემის დიზაინის ეტაპზე. Ro-rootf-ებთან მუშაობა შეიძლება იყოს უხერხული და მტკივნეული, რადგან const ცვლადები ხშირად გვხვდება პროგრამირების ენებში, მაგრამ მათი სარგებელი ადვილად ამართლებს დამატებით ხარჯებს.

შექმნა rootfs მხოლოდ წაკითხვა მოითხოვს დამატებით ძალისხმევას ჩაშენებული დეველოპერებისთვის და სწორედ აქ ჩნდება VFS. Linux მოითხოვს, რომ ფაილები იყოს შეყვანილი /var იყო ჩასაწერი და გარდა ამისა, ბევრი პოპულარული აპლიკაცია, რომელიც მუშაობს ჩაშენებულ სისტემებზე, შეეცდება შექმნას კონფიგურაცია dot-files в $HOME. მთავარი დირექტორიაში არსებული კონფიგურაციის ფაილების ერთ-ერთი გამოსავალი არის მათი წინასწარ გენერირება და ჩაშენება rootfs. იყიდება /var ერთ-ერთი შესაძლო მიდგომაა მისი დამონტაჟება ცალკე დასაწერ დანაყოფზე, ხოლო / დამონტაჟებულია მხოლოდ წასაკითხად. კიდევ ერთი პოპულარული ალტერნატივა არის შეკვრის ან გადაფარვის სამაგრების გამოყენება.

დამაკავშირებელი და დასაწყობი სამაგრები, მათი გამოყენება კონტეინერებით

ბრძანების შესრულება man mount ეს არის საუკეთესო გზა შევისწავლოთ შესაკრავი და გადაფარვადი სამონტაჟოები, რომლებიც დეველოპერებს და სისტემის ადმინისტრატორებს აძლევს შესაძლებლობას შექმნან ფაილური სისტემა ერთ გზაზე და შემდეგ გამოავლინონ იგი სხვა აპლიკაციებში. ჩაშენებული სისტემებისთვის, ეს ნიშნავს ფაილების შენახვის შესაძლებლობას /var მხოლოდ წაკითხვადი ფლეშ დრაივზე, მაგრამ გადაფარვის ან დასამაგრებელი ბილიკი საიდანაც tmpfs в /var ჩატვირთვისას ის აპლიკაციებს საშუალებას მისცემს დაწერონ იქ ჩანაწერები (სკრალი). შემდეგ ჯერზე, როცა ჩართავთ ცვლილებებს /var დაიკარგება. გადახურვის სამაგრი ქმნის კავშირს შორის tmpfs და ფუძემდებლური ფაილური სისტემა და საშუალებას გაძლევთ შეასრულოთ აშკარა ცვლილებები არსებულ ფაილებში ro-tootf მაშინ როცა შესაკრავი სამონტაჟო შეუძლია ახლის დაცლას tmpfs საქაღალდეები ჩანს როგორც ჩასაწერი ro-rootfs გზები. ხოლო overlayfs ეს არის სწორი (proper) ფაილური სისტემის ტიპი, შეკვრადი სამონტაჟო დანერგილია VFS სახელთა სივრცე.

გადაფარვისა და დამაკავშირებელი სამაგრის აღწერილობიდან გამომდინარე, ეს არავის უკვირს Linux კონტეინერები ისინი აქტიურად გამოიყენება. ვნახოთ, რა მოხდება, როდესაც ვიყენებთ systemd-nspawn კონტეინერის გასაშვებად ხელსაწყოს გამოყენებით mountsnoop საწყისი bcc.

გამოწვევა system-nspawn იწყებს კონტეინერს გაშვებისას mountsnoop.py.

ვნახოთ რა მოხდა:

Запуск mountsnoop კონტეინერის "ჩატვირთვისას" გვიჩვენებს, რომ კონტეინერის მუშაობის დრო დიდად არის დამოკიდებული დაკავშირებულ სამაგრზე (გამოსახულია მხოლოდ გრძელი გამომავალი დასაწყისი).

აქ systemd-nspawn უზრუნველყოფს შერჩეულ ფაილებს procfs и sysfs მასპინძელი კონტეინერი, როგორც ბილიკები მისკენ rootfs... გარდა MS_BIND დროშა, რომელიც ადგენს სავალდებულო სამაგრს, ზოგიერთი სხვა დროშები მთაზე განსაზღვრავს ურთიერთობას ჰოსტისა და კონტეინერის სახელების სივრცეში ცვლილებებს შორის. მაგალითად, დაკავშირებულ სამაგრს შეუძლია ან გამოტოვოს ცვლილებები /proc и /sys კონტეინერში, ან დამალეთ ისინი ზარის მიხედვით.

დასკვნა

Linux-ის შიდა ფუნქციონირების გაგება შეიძლება შეუძლებელი ჩანდეს, რადგან ბირთვი შეიცავს უზარმაზარ რაოდენობას კოდს, გვერდით ტოვებს Linux-ის მომხმარებლის სივრცის აპლიკაციებს და სისტემური ზარის ინტერფეისებს C ბიბლიოთეკებში, როგორიცაა glibc. პროგრესის მიღწევის ერთ-ერთი გზაა ერთი ბირთვის ქვესისტემის საწყისი კოდის წაკითხვა, სისტემური ზარების და მომხმარებლის სივრცის სათაურების გაგებაზე, ისევე როგორც ბირთვის ძირითადი შიდა ინტერფეისების, როგორიცაა ცხრილი. file_operations. ფაილური ოპერაციები ითვალისწინებს "ყველაფერი ფაილია" პრინციპს, რაც მათ მართვას განსაკუთრებით სასიამოვნოს ხდის. C ბირთვის წყაროს ფაილები ზედა დონის დირექტორიაში fs/ წარმოგიდგენთ ვირტუალური ფაილური სისტემების იმპლემენტაციას, რომლებიც წარმოადგენენ შეფუთვის ფენას, რომელიც უზრუნველყოფს ფართო და შედარებით მარტივ თავსებადობას პოპულარულ ფაილურ სისტემებსა და შესანახ მოწყობილობებს შორის. ლინუქსის სახელების სივრცის საშუალებით დაკავშირება და გადაფარვა არის VFS-ის ჯადოსნური თვისებები, რაც შესაძლებელს ხდის მხოლოდ წაკითხვადი კონტეინერების და root ფაილური სისტემების შექმნას. წყაროს კოდის, eBPF ძირითადი ხელსაწყოს და მისი ინტერფეისის შესწავლასთან ერთად bcc
აადვილებს ბირთვის შესწავლას, ვიდრე ოდესმე.

მეგობრებო, დაწერეთ, ეს სტატია თქვენთვის სასარგებლო იყო? იქნებ გაქვთ რაიმე კომენტარი ან შენიშვნა? ლინუქსის ადმინისტრატორის კურსით დაინტერესებულები მოწვეულნი არიან ღია დღე, რომელიც 18 აპრილს გაიმართება.

Პირველი ნაწილი.

წყარო: www.habr.com