როგორ მუშაობს filesystem-ები: inode-ები, journaling და page cache?

Question

IT Interview Practice · Accepted Answer

**Filesystem** დისკის block-ების ბრტყელ მასივს ფაილებისა და დირექტორიების იერარქიად აქცევს, მართავს metadata-სა და თავისუფალ სივრცეს, რომ ეს იყოს საიმედო და სწრაფი.

## Inode-ები: ფაილი არის metadata + block pointer-ები

UNIX filesystem-ებში ყოველი ფაილი არის **inode** (index node) — სტრუქტურა, რომელიც ინახავს ფაილის **metadata-ს** (ზომა, მფლობელი, ნებართვები, timestamp-ები, link count) და **მისი data block-ების pointer-ებს**. შენიშნეთ, რას *არ* ინახავს inode: **filename-ს**. სახელები **დირექტორიებში** ცხოვრობს, რომლებიც უბრალოდ ფაილებია, რომლებიც ასახავს name → inode number:

```text
directory "docs"                  inode 1042              data blocks
┌───────────────────┐            ┌──────────────┐         ┌────────┐
│ "report.txt" →1042│───────────▶│ mode, uid    │──ptr───▶│ block  │
│ "notes.txt"  →1050│            │ size, times  │──ptr───▶│ block  │
└───────────────────┘            │ link count=2 │         └────────┘
                                 │ block ptrs   │──(indirect)──▶ ...
                                 └──────────────┘
```

სწორედ ამიტომ არის **hard link** უბრალოდ მეორე დირექტორიის entry, რომელიც იმავე inode-ზე მიუთითებს (link count 2), და რატომ არის `rm` სინამდვილეში `unlink` — ის ხსნის სახელს და inode-ს მხოლოდ მაშინ ათავისუფლებს, როცა link count ნულს ხვდება.

## Journaling: crash-ის გადატანა

ერთი ლოგიკური ოპერაცია (მაგ. append) რამდენიმე block-ს ეხება — inode-ს, free-space bitmap-ს, მონაცემებს. crash შუა გზაზე filesystem-ს არათანმიმდევრულს ტოვებს. **Journal** ჯერ ჩაწერს განზრახულ ცვლილებებს log-ში, შემდეგ იყენებს მათ; crash-ის შემდეგ FS ხელახლა უშვებს (replay) ან აუქმებს (discard) journal-ს ნელი სრული სკანირების (`fsck`) ნაცვლად. რეჟიმები უსაფრთხოებას სისწრაფეზე ცვლიან: journal **მხოლოდ metadata** (სწრაფი, გავრცელებული) vs metadata **და მონაცემები**.

## Page cache და I/O გზები

kernel-ი ფაილის მონაცემებს RAM-ში **page cache-ში** ინახავს, ასე რომ ხელახალი წაკითხვები მეხსიერებას ხვდება და ჩაწერები **ბუფერიზდება** და მოგვიანებით იფლaშება (write-back):

```text
buffered I/O (default): app ↔ page cache ↔ disk   → cached, async writeback, fast re-reads
direct I/O (O_DIRECT):  app ↔ disk                → bypass the cache; DBs manage their own
fsync():                force buffered data to durable storage (required for real durability)
```

Buffered I/O სწრაფია, მაგრამ „ჩაწერილი" მონაცემი არ არის მდგრადი `fsync`-მდე; database-ები ხშირად იყენებენ **direct I/O**-ს პლუს საკუთარ buffer pool-ს, რომ ზუსტად აკონტროლონ caching და durability.

## რატომ არის ეს მნიშვნელოვანი

Filesystem-ის შიდა ლოგიკა ხსნის ყოველდღიურ ქცევას: რატომ მუშაობს hard link-ები, რატომ არ ათავისუფლებს ფაილის წაშლა, რომელსაც process ჯერ კიდევ გახსნილი აქვს, ადგილს დახურვამდე, რატომ არის `fsync` აუცილებელი durability-სთვის (და კლასიკური მონაცემდაკარგვის ბაგი გამოტოვებისას), და რატომ არის ფაილის მეორე წაკითხვა მყისიერი (page cache). Senior ინჟინრები ამაზე მსჯელობენ, როცა ირჩევენ buffered vs direct I/O-ს database-ისთვის, ზომავენ RAM-ს cache-ისთვის ან debug-ს უკეთებენ crash-consistency პრობლემას.

Inode-ები: ფაილი არის metadata + block pointer-ები

Journaling: crash-ის გადატანა

Page cache და I/O გზები

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები