უკან დაბრუნება
NetBSD: disklabel-ების აგებულება ბაიტიდან ბაიტამდე
SiTech AI Team2 წთ. საკითხავი

NetBSD: disklabel-ების აგებულება ბაიტიდან ბაიტამდე

movq.de-ის ბლოგზე გამოქვეყნებული პრაქტიკული პოსტი BSD disklabel-ის აგებულებას NetBSD 11-ზე ხსნის: სად ინახება ლეიბლი დისკზე, რას ნიშნავს ჰედერის ველები, როგორ ითვლება XOR საკონტროლო ჯამი და როგორ იქმნება დანაყოფი ჰექს-რედაქტორში.

movq.de-ის ბლოგზე გამოქვეყნებული პოსტი BSD disklabel-ის აგებულებას NetBSD 11-ზე, x86_64-ზე ხსნის. ავტორი წერს, რომ DOS-იდან და Linux-იდან მოდის და საკუთარ OpenBSD სისტემებზე disklabel-ებს თითქმის არ აქცევდა ყურადღებას. მან გაარკვია, რას ნიშნავს ცალკეული ბაიტები და რამდენის შეცვლა შეიძლება ხელით.

სად ინახება disklabel

დოკუმენტაცია man disklabel-ით იწყება, რადგან მის SEE ALSO განყოფილებაში disklabel(5) არის მითითებული; თუმცა ავტორი უმეტესად პირდაპირ /usr/include/sys/disklabel.h-ს კითხულობდა. MBR სისტემებთან კონფლიქტის თავიდან ასაცილებლად disklabel ჩვეულებრივი MBR არესგან მოშორებით ინახება: libutil-ზე დაბმული პატარა C პროგრამა 1-ს აბრუნებს getlabelsector()-ისთვის და 0-ს getlabeloffset()-ისთვის, ანუ ლეიბლი მეორე სექტორში, 512-ე ბაიტზე ზის.

ჰედერის ველები

ლეიბლი დისკის მეტამონაცემებით იწყება და დანაყოფების მასივით მთავრდება. little-endian სიტყვებად წაკითხვისას ჯერ ორი magic-რიცხვი ჩანს (d_magic და d_magic2), დისკის ტიპი 0x0f, ანუ logical disk, და დრაივერის სახელი ld1, შემდეგ კი გეომეტრია მოდის: 512 ბაიტი სექტორზე, 63 სექტორი ტრეკზე, 16 ტრეკი ცილინდრზე, 260 ცილინდრი და სულ 262144 სექტორი, ანუ 128 MiB. ძველი აპარატურის პარამეტრები, მაგალითად 3600 rpm და ძებნის დრო, თანამედროვე x86_64-ზე ძირითადად ნულს უდრის და MBR-იც თავისი CHS-ის ნარჩენებით ბევრად უკეთესი არ არის; ჰექს-დემპიდან წაკითხული მნიშვნელობები disklabel ld1-ის გამონაბეჭდს ემთხვევა.

disklabel-ის ჰედერის ჰექს-დემპი

დანაყოფების ცხრილი და საკონტროლო ჯამი

ჰედერი d_npartitions-ს აცხადებს, შემდეგ კი a-დან d-მდე დანაყოფებისთვის 16-ბაიტიანი ჩანაწერები მოდის. რეალურად მხოლოდ სამი ველია მნიშვნელოვანი: დასაწყისი, ზომა და ფაილური სისტემის ტიპი. a დანაყოფს 262144 სექტორი აქვს ნულოვანი წანაცვლებიდან და ტიპი 0x07, ანუ 4.2BSD (FFS). d დანაყოფი x86_64-ზე ყოველთვის არსებობს და მთელ დისკს აღწერს, როგორც NetBSD-ის დეველოპერმა Martin Husemann-მა ახსნა; c კი იმიტომ არ ჩანს, რომ მისი ზომა, წანაცვლება და ტიპი ნულის ტოლია.

ჰედერში d_checksum მონაცემების xor-ად არის აღწერილი, დანაყოფების ჩათვლით. ლეიბლის ყველა 16-ბიტიანი ნაწილის XOR-ით ნული მიიღება, რაც შენახული მნიშვნელობის შეთანხმებულობას ადასტურებს, ვინაიდან საკონტროლო ჯამი თავად ერთ-ერთი ნაწილია. მისი გამორიცხვით 1dc6 გამოდის, რაც დემპში ნანახ c61d-ს ემთხვევა; NetBSD-ის კოდი ამისთვის, სავარაუდოდ, sys/lib/libkern-ში მდებარე dkcksum.c-ია.

დანაყოფი ჰექს-რედაქტორში

შემდეგ ავტორმა საპირისპირო სცადა: ხელით განსაზღვრა i დანაყოფი 1234 სექტორის სიგრძით, 5678-ე სექტორიდან დაწყებული და ZFS ტიპით. მეცხრე ჩანაწერი 788-ე ბაიტზე იწყება, რაც ასე გამოითვლება: 512 + 0x94 + (9-1) * 16. მან ჩაწერა p_size, p_offset და p_fstype 0x21, d_npartitions 9-მდე გაზარდა და საკონტროლო ჯამი ხელახლა დაითვალა, რის შედეგადაც 160f მიიღო.

ჩატვირთვის შემდეგ disklabel ld1-მა ახალი დანაყოფი ზუსტად ისე აჩვენა, როგორც იყო ჩაფიქრებული და გააფრთხილა, რომ a და i ერთმანეთს გადაფარავს; ეს მოსალოდნელია, ვინაიდან a მთელ დისკს მოიცავს. ავტორი აღნიშნავს, რომ MBR-ისა და GPT-ის თავზე დამატებული ეს ფენა ადვილად შეუმჩნეველი რჩება და რომ ფორმატს მხოლოდ პრაქტიკული მუშაობა აჩვევს.

SSiTech

SiTech — AI-გაძლიერებული ვებ დეველოპმენტი

ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.