ჩაძირვა SDCardFS-ში: როგორ შეამცირებს Google-ის FUSE ჩანაცვლება I/O ზედნადებს

SDCardFS-ის სიღრმისეული გამოკვლევა, Google-ის შემცვლელი FUSE-ისთვის და როგორ შეამცირებს მისი განხორციელება I/O ზედნადებს.

რამდენიმე თვის წინ Google-მა დაამატა რაღაც სახელწოდებით „SDCardFS” Linux-ის ბირთვის AOSP-ის ოფიციალურ ფილიალებში. იმ დროს ეს ნაბიჯი მხოლოდ შეამჩნია ზოგიერთი ბირთვის დეველოპერი, მაგრამ სხვაგვარად გაფრინდა მომხმარებლების უმეტესობის რადარის ქვეშ. გასაკვირი არ არის, თუ გავითვალისწინებთ იმ ფაქტს, რომ მომხმარებელთა უმეტესობამ, მათ შორის მეც, ნამდვილად არ იცის რა ხდება Android OS და მისი ბირთვის ქვეშ.

თუმცა, უახლესი ეპიზოდი Android დეველოპერები Backstage პოდკასტმა განაახლა ინტერესი ამ თემის მიმართ. პოდკასტი, რომელსაც უძღვებოდა Chet Haase (Google-ის უფროსი პროგრამული ინჟინერი), შეისწავლა ბირთვში განხორციელებული ბოლო და მომავალი ცვლილებები. შოუში იყო Linux kernel-ის დეველოპერი, რომელიც მუშაობდა Android-ის გუნდზე - Rom Lemarchand. დუეტმა ძირითადად განიხილა რა ცვლილებები განხორციელდა A/B განახლებების შესასრულებლად, მაგრამ ეპიზოდის ბოლო 5 წუთში ბატონმა ლემარჩანდმა ისაუბრა „შემდეგ დიდ საკითხზე“, რომელზეც მისი გუნდი მუშაობდა - SDCardFS.

უნდა ვაღიარო, რომ SDCardFS-ის არსებობის შესახებ ამ პოდკასტის მოსმენის შემდეგ გავიგე. რა თქმა უნდა, მე არ ვიყავი ერთადერთი ვინც დაინტერესდა ამ თემით, როგორც ა Reddit-ის ბოლო თემა აჩვენა. თუმცა, მე არ ვიყავი კმაყოფილი ძირითადი ახსნა-განმარტებით, რომელიც იყო შემოთავაზებული პოდკასტში და ზოგიერთის გაფანტვის მცდელობაში გავრცელებული დეზინფორმაცია, მე ჩავატარე საკუთარი გამოკვლევა და ვესაუბრე რამდენიმე ექსპერტს შესაბამისი ცოდნის შესახებ. მატერია.

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

"გარე" ნამდვილად შინაგანია

უპირველეს ყოვლისა, არსებობს გარკვეული მცდარი წარმოდგენები, რომლებიც უნდა გავარკვიოთ - წინააღმდეგ შემთხვევაში, სტატიის დანარჩენი ნაწილი ძალიან დამაბნეველი იქნება. სასარგებლოა SD ბარათების და Android ტელეფონების ისტორიის განხილვა.

Android ტელეფონების ადრეულ დღეებში, თითქმის ყველა მოწყობილობა ეყრდნობოდა მათი microSD ბარათების გამოყენებას შესანახად. ეს გამოწვეული იყო იმით, რომ ტელეფონები იმ დროს იგზავნებოდა მცირე შიდა მეხსიერებით. თუმცა, SD ბარათები, რომლებიც გამოიყენება აპლიკაციების შესანახად, ხშირად არ იძლევა მომხმარებლის ვარსკვლავურ გამოცდილებას, ყოველ შემთხვევაში იმ სიჩქარესთან შედარებით, რომლითაც შიდა ფლეშ მეხსიერებას შეუძლია მონაცემების წაკითხვა/ჩაწერა. აქედან გამომდინარე, SD ბარათების მზარდი გამოყენება გარე მონაცემების შესანახად გახდა მომხმარებლის გამოცდილების შეშფოთება Google-ისთვის.

SD ბარათების, როგორც გარე შენახვის მოწყობილობების ადრეული გავრცელების გამო, Android-ის მეხსიერების დასახელების კონვენციები ეფუძნებოდა იმ ფაქტს, რომ ყველა მოწყობილობას ჰქონდა რეალური, ფიზიკური microSD ბარათის სლოტი. მაგრამ იმ მოწყობილობებზეც კი, რომლებიც არ შეიცავდნენ SD ბარათის სლოტს, ეტიკეტი /sdcard მაინც გამოიყენებოდა რეალური შიდა მეხსიერების ჩიპზე მითითებისთვის. უფრო დამაბნეველია ის ფაქტი, რომ მოწყობილობები, რომლებიც იყენებდნენ როგორც ფიზიკურ SD ბარათს, ასევე შენახვისთვის მაღალი ტევადობის ჩიპს, ხშირად ასახელებდნენ თავიანთ დანაყოფებს SD ბარათის გარშემო. მაგალითად, ამ მოწყობილობებში /sdcard სამონტაჟო წერტილი მიუთითებს რეალურ შიდა მეხსიერების ჩიპზე, ხოლო რაღაც მსგავსი /storage/sdcard1 ეხება ფიზიკურ გარე ბარათს.

ამრიგად, მიუხედავად იმისა, რომ microSD ბარათი პრაქტიკულად განიხილება გარე საცავად, დასახელების კონვენციამ გამოიწვია ის, რომ „SDCard“ დიდი ხნის განმავლობაში ჩერდებოდა ფიზიკური ბარათის რეალურ გამოყენებად. შენახვასთან დაბნეულობამ ასევე გარკვეული თავის ტკივილი გამოიწვია აპლიკაციის დეველოპერებს იმის გამო, რომ აპლიკაციის მონაცემები და მისი მედია იყო გამოყოფილი ორ დანაყოფს შორის.

ადრეული შიდა მეხსიერების ჩიპების დაბალი საცავი გამოიწვია იმედგაცრუებულმა მომხმარებლებმა გაარკვიეს, რომ აღარ შეეძლოთ აპლიკაციების ინსტალაცია (/data დანაყოფი სავსეა). იმავდროულად, მათი უფრო დიდი ტევადობის microSD ბარათები დაქვემდებარებული იყო მხოლოდ მედიის შესანახად (როგორიცაა ფოტოები, მუსიკა და ფილმები). მომხმარებლებს, რომლებიც ათვალიერებდნენ ჩვენს ფორუმებს იმ დღეს შეიძლება დაიმახსოვრონ ეს სახელები: Link2SD და Apps2SD. ეს იყო (root) გადაწყვეტილებები, რომლებიც მომხმარებლებს საშუალებას აძლევდა დაეყენებინათ თავიანთი აპლიკაციები და მონაცემები ფიზიკურ SD ბარათზე. მაგრამ ეს შორს იყო სრულყოფილი გადაწყვეტილებებისგან, ამიტომ Google-მა უნდა ჩაერთო.

ცნობილია, რომ Google-მა SD ბარათებს ძალიან ადრე გამოართვა. Nexus One რჩება ერთადერთ Nexus მოწყობილობად, რომელსაც აქვს microSD ბარათის სლოტი (და ეს სამუდამოდ იქნება, რადგან Nexus ბრენდი ფაქტობრივად მკვდარია). Nexus S-თან ერთად, ახლა მხოლოდ ერთი, ერთიანი დანაყოფი იყო აპლიკაციის ყველა მონაცემისა და მედიის შესანახად - /data დანაყოფი. ის, რაც ოდესღაც ცნობილი იყო როგორც /sdcard mount point, ახლა უბრალოდ გულისხმობდა ვირტუალურ ფაილურ სისტემას (დანერგილი ქვეშ დაუკრავენ პროტოკოლი, როგორც ქვემოთ არის განხილული) განთავსებული მონაცემთა დანაყოფში - /data/media/0.

თავსებადობის შესანარჩუნებლად და დაბნეულობის შესამცირებლად, Google კვლავ იყენებდა ამ ახლა ვირტუალურ „sdcard“ დანაყოფს მედიის შესანახად. მაგრამ ახლა, როდესაც ეს "sdcard" ვირტუალური დანაყოფი რეალურად მდებარეობდა /data-ში, მასში შენახული ყველაფერი ჩაითვლება შიდა მეხსიერების ჩიპის შენახვის სივრცეში. ამრიგად, OEM-ებს ევალებოდათ განეხილათ, თუ რამდენი ადგილი უნდა გამოეყოთ აპლიკაციებს (/მონაცემები) მედიის (/data/media) წინააღმდეგ.

ორი ძალიან განსხვავებული "SD ბარათი"

Google იმედოვნებდა, რომ მწარმოებლები მიჰყვებოდნენ მათ მაგალითს და მოიშორებდნენ SD ბარათებს. საბედნიეროდ, დროთა განმავლობაში ტელეფონების მწარმოებლებმა შეძლეს ამ კომპონენტების უფრო მაღალი სიმძლავრის მიწოდება, ხოლო ხარჯების ეფექტურობა რჩებოდა, ასე რომ, SD ბარათების საჭიროება იწყებოდა დაქვეითებული. მაგრამ დასახელების კონვენციები კვლავ შემცირდა იმ ძალისხმევის შესამცირებლად, რომელიც დეველოპერებს და OEM-ებს უნდა მოერგოთ. ამჟამად, როდესაც ვგულისხმობთ „გარე საცავს“, ვგულისხმობთ ორიდან ერთი რამ: რეალურად მოსახსნელი microSD ბარათი ან ვირტუალური "SDCard" დანაყოფი, რომელიც მდებარეობს /data/media-ში. ამ უკანასკნელთაგან, პრაქტიკულად რომ ვთქვათ, სინამდვილეში არის შიდა მეხსიერება, მაგრამ Google-ის დასახელების კონვენცია განასხვავებს მას იმის გამო, რომ ეს მონაცემები ხელმისაწვდომია მომხმარებლისთვის (როგორიცაა კომპიუტერში ჩართვისას).

ამჟამად, როდესაც ვგულისხმობთ „გარე საცავს“, ვგულისხმობთ ორიდან ერთი რამ: რეალურად მოსახსნელი microSD ბარათი ან ვირტუალური "SDCard" დანაყოფი, რომელიც მდებარეობს /data/media-ში.

Android-ის ვირტუალური ფაილური სისტემების ისტორია

ახლა, როდესაც "sdcard" განიხილება, როგორც ვირტუალური ფაილური სისტემა, ეს ნიშნავს, რომ ის შეიძლება იყოს ფორმატირებული, როგორც ნებისმიერი ფაილური სისტემა, რომელიც Google-ს სურდა. დაწყებული Nexus S-ით და Android 2.3-ით, Google-მა აირჩია „sdcard“-ის ფორმატირება, როგორც VFAT (ვირტუალური FAT). ამ ნაბიჯს იმ დროს აზრი ჰქონდა, რადგან VFAT-ის დამონტაჟება თითქმის ნებისმიერ კომპიუტერს საშუალებას მისცემს თქვენს ტელეფონში შენახულ მონაცემებზე წვდომას. თუმცა, იყო ორი ძირითადი პრობლემა ამ თავდაპირველ განხორციელებასთან დაკავშირებით.

პირველი, პირველ რიგში, ეხება საბოლოო მომხმარებელს (თქვენ). თქვენი მოწყობილობის კომპიუტერთან დასაკავშირებლად, მონაცემთა გადასატანად იყენებთ USB Mass Storage Mode-ს. ამასთან, ამან მოითხოვა Android მოწყობილობას ვირტუალური დანაყოფის მოხსნა, სანამ კომპიუტერი შეძლებდა მონაცემებზე წვდომას. თუ მომხმარებელს სურდა გამოეყენებინა თავისი მოწყობილობა ჩართულის დროს, ბევრი რამ გამოჩნდება, როგორც მიუწვდომელი.

The მედია გადაცემის პროტოკოლის დანერგვა (MTP) გადაჭრა ეს პირველი საკითხი. როდესაც ჩართულია, თქვენი კომპიუტერი ხედავს თქვენს მოწყობილობას, როგორც „მედია შენახვის“ მოწყობილობას. ის ითხოვს ფაილების სიას თქვენი ტელეფონიდან და MTP აბრუნებს ფაილების სიას, რომელთა ჩამოტვირთვაც კომპიუტერს შეუძლია მოწყობილობიდან. როდესაც ფაილის წაშლას ითხოვენ, MTP აგზავნის ბრძანებას მოთხოვნილი ფაილის საცავიდან ამოსაღებად. USB მასობრივი შენახვის რეჟიმისგან განსხვავებით, რომელიც რეალურად ამაგრებს „SDcard“-ს, MTP მომხმარებელს საშუალებას აძლევს განაგრძოს თავისი მოწყობილობის გამოყენება, როდესაც ის ჩართულია. გარდა ამისა, Android ტელეფონში არსებულ ფაილურ სისტემას აღარ აქვს მნიშვნელობა კომპიუტერისთვის, რომ ამოიცნოს ფაილები მოწყობილობაზე.

მეორეც, იყო ის ფაქტი, რომ VFAT არ უზრუნველყოფდა ისეთი ძლიერი ნებართვების მართვას, როგორიც Google-ს სჭირდებოდა. ადრეულ პერიოდში, ბევრი აპლიკაციის დეველოპერი „SDcard“-ს განიხილავდა, როგორც მათი აპლიკაციის მონაცემების ნაგავსაყრელ ადგილს, არ ჰქონდა ერთიანი გაგება იმის შესახებ, თუ სად შეინახონ თავიანთი ფაილები. ბევრი აპლიკაცია უბრალოდ შექმნის საქაღალდეს თავისი აპლიკაციის სახელით და იქ ინახავს მის ფაილებს.

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

Google აშკარად ხედავდა ამ პრობლემას. ნებართვების მენეჯმენტის მთელი იდეა არის განცალკევება, რაზე შეიძლება და რა არ შეიძლება ჰქონდეს აპებს. თუ თითქმის ყველა აპს ენიჭება წაკითხული წვდომა მომხმარებლის პოტენციურად მგრძნობიარე მონაცემებზე, მაშინ ნებართვა უაზროა. ამრიგად, Google-მა გადაწყვიტა, რომ მათ ახალი მიდგომა სჭირდებოდათ. სწორედ აქ შემოდის FUSE.

ფაილური სისტემა მომხმარებლის სივრცეში (FUSE)

Android 4.4-ით დაწყებული, Google-მა გადაწყვიტა აღარ დაემონტაჟებინა ვირტუალური "sdcard" დანაყოფი VFAT-ად. ამის ნაცვლად, Google-მა დაიწყო FUSE-ის გამოყენება FAT32-ის ემულაციისთვის "sdcard" ვირტუალურ დანაყოფზე. sdcard პროგრამის დარეკვით FUSE FAT-on-sdcard სტილის დირექტორიაში ნებართვების ემულაცია, აპლიკაციებმა შეიძლება დაიწყონ გარე მეხსიერებაში შენახულ მის მონაცემებზე წვდომა ყოველგვარი ნებართვის მოთხოვნის გარეშე. მართლაც, API 19-დან დაწყებული, READ_EXTERNAL_STORAGE აღარ იყო საჭირო მდებარე ფაილებზე წვდომისთვის გარე მეხსიერებაზე - იმ პირობით, რომ FUSE დემონის მიერ შექმნილი მონაცემთა საქაღალდე ემთხვევა აპის პაკეტის სახელს. FUSE დამუშავებდა გარე მეხსიერებაზე ფაილების მფლობელის, ჯგუფის და რეჟიმების სინთეზირება როდესაც აპლიკაცია დაინსტალირებულია.

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

იმის გამო, რომ FUSE არის ლამაზი სტაბილური API, ბირთვის ვერსიებს შორის გადაადგილებისას არსებითად არ არის საჭირო ტექნიკური სამუშაოები. თუ ჩვენ გადავიტანდით ბირთვის გადაწყვეტას, ჩვენ დავრეგისტრირდით პატჩების ნაკრების შესანარჩუნებლად თითოეული სტაბილური ბირთვის ვერსიისთვის." - ჯეფ შარკი, პროგრამული უზრუნველყოფის ინჟინერი Google-ში.

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

პრობლემა FUSE-თან დაკავშირებით

Android-ში, "sdcard" userspace daemon იყენებს FUSE-ს, რათა დაამონტაჟოს /dev/fuse ემულირებული გარე მეხსიერების დირექტორიაში ჩატვირთვისას. ამის შემდეგ, sdcard-ის დემონი გამოკითხავს FUSE მოწყობილობას ბირთვიდან ნებისმიერი მომლოდინე შეტყობინებისთვის. თუ თქვენ მოუსმინეთ პოდკასტს, შესაძლოა გსმენიათ, რომ ბატონი ლემარჩანდი საუბრობს FUSE-ზე, რომელიც შემოღებულ იქნა ზედნადები I/O ოპერაციების დროს - არსებითად აი, რა ხდება.

რეალურ სამყაროში ეს სპექტაკლის ჰიტი გავლენას ახდენს ნებისმიერი ფაილი ინახება გარე მეხსიერებაში.

პრობლემა #1 - I/O ოვერჰედი

ვთქვათ, რომ ჩვენ ვქმნით მარტივ ტექსტურ ფაილს, სახელწოდებით "test.txt" და ვინახავთ მას /sdcard/test.txt-ში (რომელიც შეგახსენებთ, რომ რეალურად არის /data/media/0/test.txt, თუ ვივარაუდებთ, რომ მიმდინარე მომხმარებელი არის მთავარი მომხმარებელი. მოწყობილობა). თუ გვინდოდა ამ ფაილის წაკითხვა (command cat), ჩვენ მოველით, რომ სისტემა გამოსცემს 3 ბრძანებას: გახსნა, წაკითხვა, შემდეგ დახურვა. მართლაც, როგორც ბატონი კოვალჩიკი აჩვენებს გამოყენებით ზოლი, ასე ხდება:

მაგრამ იმის გამო, რომ ფაილი მდებარეობს გარე საცავზე, რომელსაც მართავს sdcard daemon, არსებობს მრავალი დამატებითი ოპერაცია, რომელიც უნდა შესრულდეს. ბატონი კოვალჩიკის თქმით, ამისთვის არსებითად საჭიროა 8 დამატებითი ნაბიჯი თითოეული ამ 3 ინდივიდუალური ბრძანებიდან:

მომხმარებლის სივრცის აპლიკაციის გაცემის სისტემური ზარი, რომელსაც ამუშავებს FUSE დრაივერი ბირთვში (ჩვენ ვხედავთ მას პირველ ზოლში)
FUSE დრაივერი ბირთვში აცნობებს მომხმარებლის სივრცის დემონს (sdcard) ახალი მოთხოვნის შესახებ
მომხმარებლის სივრცის დემონი კითხულობს /dev/fuse
მომხმარებლის სივრცის დემონი აანალიზებს ბრძანებას და ამოიცნობს ფაილის ოპერაციას (მაგ. გახსნა)
მომხმარებლის სივრცის დემონის გამოძახება რეალურ ფაილურ სისტემაში (EXT4)
ბირთვი მართავს ფიზიკურ მონაცემებს და აგზავნის მონაცემებს მომხმარებლის სივრცეში
მომხმარებლის სივრცე ცვლის (ან არა) მონაცემებს და ისევ გადასცემს /dev/fuse-ს მეშვეობით ბირთვს
ბირთვი ასრულებს თავდაპირველ სისტემურ ზარს და გადააქვს მონაცემები მომხმარებლის სივრცის რეალურ აპლიკაციაში (ჩვენს მაგალითში კატა)

ეს თითქოს ბევრი ოვერჰედის მხოლოდ ერთი I/O ბრძანების გასაშვებად. და მართალი იქნებოდი. ამის საჩვენებლად, ბ-ნმა კოვალჩიკმა სცადა ორი განსხვავებული I/O ტესტირება: ერთი დიდი ფაილის კოპირებით, მეორე კი უამრავი პატარა ფაილის კოპირებით. მან შეადარა FUSE-ის (FAT32-ად დამონტაჟებულ ვირტუალურ დანაყოფზე) სიჩქარე ამ ოპერაციებთან ბირთვი (მონაცემთა დანაყოფზე დაფორმატებულია როგორც EXT4) და მან აღმოაჩინა, რომ FUSE მართლაც მნიშვნელოვანი წვლილი შეიტანა ზედნადები.

პირველ ტესტში მან დააკოპირა 725MB ფაილი ორივე ტესტის პირობებში. მან აღმოაჩინა, რომ FUSE იმპლემენტაციამ გადაიტანა დიდი ფაილები 17%-ით უფრო ნელა.

მეორე ტესტში მან დააკოპირა 10000 ფაილი - თითოეული მათგანი 5KB ზომით. ამ სცენარში FUSE-ის განხორციელება დასრულდა 40 წამით ნელა ძირითადად 50 მბ ღირებულების მონაცემების კოპირება.

რეალურ სამყაროში ეს სპექტაკლის ჰიტი გავლენას ახდენს ნებისმიერი ფაილი ინახება გარე მეხსიერებაში. ეს ნიშნავს აპებს, როგორიცაა Maps, რომლებიც ინახავს დიდ ფაილებს / sdcard-ზე, მუსიკალური აპები, რომლებიც ინახავს ტონა მუსიკალურ ფაილს, კამერის აპებსა და ფოტოებს და ა.შ. ნებისმიერი I/O ოპერაცია, რომელიც განხორციელდება, რომელიც მოიცავს გარე მეხსიერებას, გავლენას ახდენს FUSE-ის ზედნადებზე. მაგრამ I/O ზედნადები არ არის ერთადერთი პრობლემა FUSE-თან დაკავშირებით.

პრობლემა #2 - ორმაგი ქეშირება

მონაცემთა ქეშირება მნიშვნელოვანია მონაცემთა წვდომის მუშაობის გასაუმჯობესებლად. მონაცემთა არსებითი ნაწილის მეხსიერებაში შენახვით, Linux-ის ბირთვს შეუძლია სწრაფად გაიხსენოს ეს მონაცემები საჭიროების შემთხვევაში. მაგრამ FUSE-ის დანერგვის მეთოდის გამო, Android ინახავს ორჯერ საჭირო ქეშის რაოდენობას.

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

შექმენით ფაილი ცნობილი ზომით (სატესტოდ, 10 მბ)
დააკოპირეთ იგი / sdcard-ზე
ჩამოაგდეთ გვერდის ქეში
გადაიღეთ გვერდის ქეშის გამოყენების სნეპშოტი
წაიკითხეთ ტესტის ფაილი
გადაიღეთ გვერდის ქეშის გამოყენების კიდევ ერთი სურათი

მან აღმოაჩინა, რომ ტესტირებამდე ბირთვი იყენებდა 241 მბ-ს გვერდის ქეშისთვის. მას შემდეგ რაც წაიკითხა თავისი სატესტო ფაილი, მოელოდა, რომ დაინახავდა 251 მბ-ს, რომელიც გამოიყენებოდა გვერდის ქეშისთვის. ამის ნაცვლად, მან აღმოაჩინა, რომ ეს ბირთვი იყენებდა 263 მბ გვერდის ქეშისთვის - დაახლოებით ორჯერ ვიდრე მოსალოდნელი იყო. ამის მიზეზი არის ის, რომ მონაცემები ჯერ ქეშირებულია მომხმარებლის აპლიკაციის მიერ, რომელმაც თავდაპირველად გამოსცა I/O ზარი (FUSE) და მეორე sdcard daemon-ით (EXT4 FS).

პრობლემა #3 - FAT32-ის არასრული დანერგვა

FUSE-ის ემულაციური FAT32-ის გამოყენებასთან დაკავშირებული კიდევ ორი პრობლემაა, რომლებიც ნაკლებად ცნობილია Android საზოგადოებაში.

პირველი მოიცავს არასწორი დროის შტამპები. თუ ოდესმე გადაიტანეთ ფაილი (როგორიცაა ფოტო) და შენიშნეთ, რომ დროის ანაბეჭდი არასწორია, ეს გამოწვეულია Android-ის მიერ FUSE-ის დანერგვით. ამ საკითხს აქვს არსებობდა წლები. უფრო კონკრეტულად რომ ვთქვათ, საკითხი მოიცავს utime () სისტემური ზარი, რომელიც საშუალებას გაძლევთ შეცვალოთ ფაილზე წვდომის და მოდიფიცირების დრო. სამწუხაროდ, sdcard daemon-ზე განხორციელებულ ზარებს, როგორც სტანდარტულ მომხმარებელს, არ აქვთ შესაბამისი ნებართვა ამ სისტემური ზარის შესასრულებლად. არსებობს გამოსავალი ამისთვის, მაგრამ ისინი თქვენგან მოითხოვენ აქვს root წვდომა.

თუ ოდესმე გადაიტანეთ ფაილი (როგორიცაა ფოტო) და შენიშნეთ, რომ დროის ანაბეჭდი არასწორია, ეს გამოწვეულია Android-ის მიერ FUSE-ის დანერგვით.

შემდეგი პრობლემა უფრო მეტად ეხება ბიზნესს, რომელიც იყენებს ა smartSD ბარათი. FUSE-მდე აპლიკაციის შემქმნელებს შეეძლოთ მონიტორინგი O_DIRECT დროშა ბარათში ჩაშენებულ მიკროკონტროლერთან კომუნიკაციის მიზნით. FUSE-ით დეველოპერებს შეუძლიათ მხოლოდ ფაილის ქეშ ვერსიაზე წვდომა და ვერ ხედავენ მიკროკონტროლერის მიერ გაგზავნილ ბრძანებებს. ეს პრობლემურია ზოგიერთი საწარმოს/სახელმწიფო/საბანკო აპისთვის, რომელიც დაუკავშირდება დამატებითი ღირებულების microSD ბარათებს.

გადაყრის დაუკრავენ SDCardFS-სთვის

ზოგიერთმა OEMS-მა ეს პრობლემები ადრევე გააცნობიერა და FUSE-ის ჩანაცვლებისთვის ბირთვში გადაწყვეტის ძიება დაიწყო. Samsung, მაგალითად, განვითარდა SDCardFS რომელიც დაფუძნებულია WrapFS-ზე. ეს ბირთვის შიდა გადაწყვეტა ასახავს FAT32-ს ისევე, როგორც FUSE-ს, მაგრამ უარს ამბობს I/O ზედნადებზე, ორმაგ ქეშირებაზე და სხვა საკითხებზე, რომლებიც ზემოთ ვახსენე. (დიახ, ნება მომეცით გავიმეორო ეს წერტილი, ეს გადაწყვეტა, რომელსაც Google ახლა ახორციელებს, ეფუძნება Samsung-ის მუშაობას).

თავად Google-მა საბოლოოდ აღიარა FUSE-თან დაკავშირებული ნაკლოვანებები, რის გამოც დაიწყო Samsung-ის მიერ შემუშავებული FAT32 ემულაციის ფენისკენ მოძრაობა. კომპანია, როგორც აღნიშნულია Android დეველოპერები Backstage პოდკასტი, მუშაობდა SDCardFS-ის ყველა მოწყობილობისთვის ხელმისაწვდომი გახდეს ბირთვის მომავალ ვერსიაში. ამჟამად შეგიძლიათ ნახოთ მათი პროგრესი მუშაობა AOSP-ში.

Როგორც Google-ის დეველოპერმა განმარტა ადრე, ბირთვში არსებული გადაწყვეტის დანერგვის ყველაზე დიდი გამოწვევა არის პაკეტის სახელის რუკაზე დაფიქსირება აპლიკაციის ID, რომელიც აუცილებელია იმისთვის, რომ პაკეტს ჰქონდეს წვდომა საკუთარ მონაცემებზე გარე საცავში რაიმეს საჭიროების გარეშე ნებართვები. მაგრამ ეს განცხადება გაკეთდა ერთი წლის წინ და ჩვენ მივედით იქამდე, როდესაც გუნდი SDCardFS-ს უწოდებს მათ „შემდეგ დიდ საქმეს“. მათ უკვე დაადასტურეს, რომ დროის ანაბეჭდის საშინელი შეცდომა დაფიქსირდა FUSE-დან დაშორების წყალობით, ასე რომ, ჩვენ შეგვიძლია ველით FUSE-ის მიტოვებით განხორციელებულ ყველა ცვლილებას.

ფაქტების გადამოწმების მცდარი წარმოდგენები

თუ აქამდე მიაღწიეთ სტატიას, მაშინ დიდება იმისთვის, რომ აქამდე ადევნეთ თვალი ყველაფერს! მსურდა განვმარტო რამდენიმე კითხვა, რომელიც გამიჩნდა ამ სტატიის წერისას:

SDCardFS აქვს არაფერი აქვს საერთო რეალურ SD ბარათებთან. მას უბრალოდ ასე უწოდებენ, რადგან ის ამუშავებს I/O წვდომას /sdcard-ისთვის. და როგორც გახსოვთ, /sdcard არის მოძველებული ეტიკეტი, რომელიც მიუთითებს თქვენი მოწყობილობის „გარე“ საცავზე (სადაც აპები ინახავს მათ მედიას).
SDCardFS არის არა ტრადიციული ფაილური სისტემა როგორიცაა FAT32, EXT4 ან F2FS. ეს არის დაწყობადი wrapper ფაილური სისტემა, რომელიც გადასცემს ბრძანებებს ქვედა, ემულირებული ფაილურ სისტემებზე (ამ შემთხვევაში, ეს იქნება FAT32 / sdcard-ზე).
MTP-თან მიმართებაში არაფერი შეიცვლება. თქვენ გააგრძელებთ MTP-ის გამოყენებას ფაილების კომპიუტერში/კომპიუტერიდან გადასატანად (სანამ Google არ დაადგენს უკეთეს პროტოკოლს). მაგრამ დროის ანაბეჭდის შეცდომა მაინც გამოსწორდება!
როგორც უკვე აღვნიშნეთ, როდესაც Google მოიხსენიებს "გარე მეხსიერებას", ისინი ან საუბრობენ (ყველა მიზნისთვის და მიზნებისთვის) შიდა / sdcard ვირტუალური FAT32 დანაყოფი ან ისინი საუბრობენ რეალურ, ფიზიკურ, მოსახსნელ microSD-ზე ბარათი. ტერმინოლოგია დამაბნეველია, მაგრამ ეს არის ის, რაც ჩვენ გაოცებული ვართ.

დასკვნა

FUSE-დან დაშორებით და ბირთვში FAT32 ემულაციის შრის (SDCardFS) დანერგვით, Google შეამცირებს მნიშვნელოვანი I/O ზედნადები, ორმაგი ქეშირების აღმოფხვრა და მისი FUSE-ის ემულაციასთან დაკავშირებული ზოგიერთი ბუნდოვანი საკითხის გადაჭრა. FAT32.

ვინაიდან ეს ცვლილებები განხორციელდება ბირთვში, მათი გავრცელება შესაძლებელია Android-ის ძირითადი ახალი ვერსიის გარეშე. ზოგიერთი მომხმარებელი ელოდება ამ ცვლილებების ოფიციალურად დანერგვას Android 8-ში, მაგრამ ეს შესაძლებელია ნებისმიერი მომავალი OTA-სთვის Pixel მოწყობილობაზე, რათა მოიტანოს Linux ბირთვის ვერსია 4.1, რომელზეც Google მუშაობდა on.

ზოგიერთი თქვენგანისთვის SDCardFS არ არის ახალი კონცეფცია. სინამდვილეში, სამსუნგის მოწყობილობები მას წლების განმავლობაში იყენებდნენ (მათ საბოლოოდ განავითარეს იგი). მას შემდეგ, რაც SDCardFS დაინერგა AOSP-ში გასულ წელს, ზოგიერთმა მორგებული ROM-ის და ბირთვის დეველოპერებმა აირჩიეს მისი დანერგვა თავიანთ საქმიანობაში. CyanogenMOD-მა ერთ მომენტში განიხილა მისი განხორციელება, მაგრამ უკან დააბრუნა, როდესაც მომხმარებლებს შეექმნათ პრობლემები თავიანთ ფოტოებთან დაკავშირებით. მაგრამ ვიმედოვნებთ, რომ Google-ის მმართველობით ამ პროექტში, Android-ის მომხმარებლებს ყველა მომავალ მოწყობილობაზე შეეძლებათ ისარგებლონ FUSE-ის მიტოვებით დანერგილი გაუმჯობესებებით.