Kedalaman I/O Windows (bagian 5) — interior NTFS: memahami sistem file lewat MFT

Dalam empat bagian sejauh ini, kita mengikuti bagaimana permintaan I/O mengalir (bagian 1–3) dan bagaimana Cache Manager menerimanya (bagian 4). Pada akhirnya, permintaan tiba di sistem file. Kali ini giliran contoh utamanya, NTFS.

Sudut pandang berubah. Sampai sekarang ini cerita dinamis «aliran permintaan». Kali ini cerita struktur statis «bagaimana data diletakkan di atas disk». Identitas «Zone.Identifier» tak terlihat yang menempel pada file yang diunduh. Alasan menyalin 10.000 file kecil jauh lebih lambat daripada satu file dengan jumlah ukuran yang sama. Sejauh mana «NTFS berjurnal jadi aman» benar — semuanya dapat dijelaskan dari struktur ini.

Ini bagian 5 seri «Kedalaman I/O Windows».

Prasyarat membaca bagian ini: menguasai dasar IRP dan device stack bagian 1 membuatnya lebih mudah dibaca. Meski begitu, agar tidak kesulitan dibaca sendiri, istilah dari bagian sebelumnya yang muncul di teks didefinisikan dulu.

Tabel 1: Istilah dari bagian sebelumnya yang menjadi prasyarat bagian ini.

Satu lagi, dua tahap cleanup (ketika handle terakhir ditutup) dan close (ketika semua rujukan di dalam kernel hilang) yang dibahas di bagian 1 juga dipakai di penjelasan penghapusan file bab 4.

1. Intinya dulu

• Pusat NTFS adalah MFT (Master File Table). Semua file dikelola sebagai rekaman di dalam MFT, dan semua informasi tentang file ada «di dalam entri MFT» atau «di area di luar MFT yang ditunjuk entri» (bab 2).¹
• Identitas file adalah «kumpulan atribut». File kecil muat seluruhnya, data dan semua, di dalam rekaman MFT (resident); file besar hanya memegang rujukan ke rangkaian cluster (non-resident). Kelambatan pemrosesan massal file kecil dapat dijelaskan dari sini (bab 2).¹
• Data dapat punya beberapa (beberapa data stream). Data sehari-hari adalah «stream tanpa nama», dan Anda dapat punya stream tambahan dengan file.txt:nama. Identitas Zone.Identifier (Mark of the Web) (bab 3).²
• Nama juga atribut. Yang menambahkan beberapa nama ke rekaman yang sama adalah hard link. Nama pendek 8.3 juga tinggal bersama sebagai «satu nama lagi» (bab 4).³⁴
• Reparse point adalah mekanisme resmi «buka, lalu ke tempat lain». Symbolic link, junction, dan Files On-Demand OneDrive semuanya penerapan data bertag ini (bab 5).⁵⁶
• Ada dua jurnal. $LogFile untuk pemulihan konsistensi metadata (log di muka agar tidak rusak), jurnal USN untuk pencatatan riwayat perubahan (buku besar apa yang berubah). Perannya sama sekali berbeda (bab 6).⁷⁸
• «Ukuran» dan «ukuran di disk» adalah hal yang berbeda. File sparse dan kompresi yang menghasilkan kesenjangan. Latar belakang «file terkompresi tidak menjadi asinkron» yang kita lihat di bagian 2 juga ada di sini (bab 7).⁹¹⁰

Peta pengetahuan artikel ini

Pusat NTFS adalah MFT (Master File Table), dan semua file dikelola sebagai rekaman di dalam MFT. Data kecil resident di dalam rekaman, data besar menjadi non-resident yang hanya memegang rujukan ke rangkaian cluster (data run), dan inilah identitas kelambatan pemrosesan massal file kecil serta fragmentasi. Beberapa data stream, hard link, dan nama pendek 8.3 semuanya penerapan mekanisme yang sama «kumpulan atribut», dan reparse point adalah hook resmi ke «membuka» yang menopang dari symbolic link sampai Files On-Demand OneDrive. Yang dijaga $LogFile adalah konsistensi struktur; ketahanan isi data perlu dibangun secara terpisah dengan alat pengendalian cache bagian 4.

flowchart LR
    accTitle: Peta pengetahuan interior NTFS dan MFT
    accDescr: Diagram yang menunjukkan hubungan NTFS, MFT, rekaman file, atribut resident dan non-resident, data run, fragmentasi, beberapa data stream, Zone.Identifier, hard link, nama pendek 8.3, reparse point (symbolic link, junction, Files On-Demand OneDrive), $LogFile dan jurnal USN, serta file sparse dan kompresi NTFS
    ntfs["NTFS"]
    mft["MFT (Master File Table)"]
    mft_record["rekaman file MFT"]
    mft_zone["zona MFT"]
    fragmentation["fragmentasi (NTFS)"]
    resident_attribute["atribut resident"]
    non_resident_attribute["atribut non-resident"]
    data_run["data run"]
    fsutil["fsutil"]
    alternate_data_stream["alternate data stream (ADS)"]
    zone_identifier["Zone.Identifier (Mark of the Web)"]
    streams_tool["streams (Sysinternals)"]
    size_disk_usage_mismatch["kesenjangan antara ukuran logis dan pemakaian disk"]
    hard_link["hard link"]
    eight_dot_three_name["nama pendek 8.3"]
    reparse_point["reparse point"]
    symbolic_link["symbolic link"]
    junction["junction (mount point)"]
    onedrive_files_on_demand["Files On-Demand OneDrive"]
    ntfs_logfile["$LogFile (log transaksi NTFS)"]
    volume_corruption["kerusakan volume"]
    cache_manager["Cache Manager"]
    usn_journal["jurnal USN (jurnal perubahan)"]
    sparse_file["sparse file"]
    ntfs_compression["kompresi NTFS"]
    asynchronous_io["I/O asinkron"]
    procmon["Process Monitor (procmon.exe)"]
    ntfs -->|"menggunakan"| mft
    mft -->|"menggunakan"| mft_record
    mft -->|"mensyaratkan"| mft_zone
    mft_zone -.->|"mengurangi"| fragmentation
    mft_record -->|"menggunakan"| resident_attribute
    mft_record -->|"menggunakan"| non_resident_attribute
    resident_attribute -->|"tidak kompatibel"| non_resident_attribute
    non_resident_attribute -->|"menggunakan"| data_run
    data_run -.->|"dapat menyebabkan"| fragmentation
    fragmentation -->|"diverifikasi dengan"| fsutil
    ntfs -->|"menggunakan"| alternate_data_stream
    zone_identifier -->|"disimpan di"| alternate_data_stream
    zone_identifier -->|"diverifikasi dengan"| streams_tool
    alternate_data_stream -->|"diverifikasi dengan"| streams_tool
    alternate_data_stream -.->|"dapat menyebabkan"| size_disk_usage_mismatch
    ntfs -->|"menggunakan"| hard_link
    hard_link -->|"mensyaratkan"| mft_record
    ntfs -.->|"menggunakan"| eight_dot_three_name
    eight_dot_three_name -->|"dikonfigurasi dengan"| fsutil
    ntfs -->|"menggunakan"| reparse_point
    reparse_point -->|"diverifikasi dengan"| fsutil
    symbolic_link -->|"mengimplementasikan"| reparse_point
    junction -->|"mengimplementasikan"| reparse_point
    onedrive_files_on_demand -->|"mengimplementasikan"| reparse_point
    ntfs -->|"menggunakan"| ntfs_logfile
    ntfs_logfile -->|"mengurangi"| volume_corruption
    ntfs -->|"menggunakan"| cache_manager
    ntfs -->|"menggunakan"| usn_journal
    usn_journal -->|"diverifikasi dengan"| fsutil
    ntfs -->|"menggunakan"| sparse_file
    sparse_file -->|"dapat menyebabkan"| size_disk_usage_mismatch
    ntfs -->|"menggunakan"| ntfs_compression
    ntfs_compression -->|"dapat menyebabkan"| size_disk_usage_mismatch
    ntfs_compression -->|"tidak kompatibel"| asynchronous_io
    ntfs -->|"diverifikasi dengan"| procmon

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 35, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Semuanya adalah rekaman MFT

2.1. Buku besar volume

Ketika volume NTFS diformat, MFT (master file table) dan serangkaian file metadata yang dimulai dengan $ dibuat. MFT punya setidaknya satu entri untuk setiap file di volume, dan entri MFT itu sendiri juga termasuk.¹

flowchart TB
    subgraph VOL["Volume NTFS"]
        MFT["$MFT ── Master File Table<br/>buku besar rekaman semua file (dirinya sendiri juga tercantum)"]
        LOG["$LogFile ── log transaksi<br/>operasi metadata (bab 6)"]
        BITMAP["$Bitmap ── status pemakaian cluster"]
        OTH["$Boot / $Secure / $UpCase dll.<br/>file metadata lain"]
        DATA["Area data pengguna<br/>(tempat data non-resident)"]
    end
    MFT -->|"Rekaman menunjuk posisi"| DATA

Gambar 1: Struktur volume NTFS. Desain NTFS adalah «informasi pengelolaan sistem file sendiri juga dipegang sebagai file».

Informasi tentang file — ukuran, cap waktu, izin akses, bahkan isi data — disimpan di dalam entri MFT, atau di area di luar MFT yang posisinya dijelaskan entri MFT.¹ Ketika file dihapus, entri ditandai sebagai «kosong» dan dipakai ulang, tetapi MFT itu sendiri tidak menyusut. Selain itu, untuk menjaga MFT tetap berkesinambungan, area bernama zona MFT dicadangkan, dan ketika volume mulai penuh fragmentasi MFT dimulai — cerita umur ini pun tertulis di dokumentasi resmi.¹

2.2. File = kumpulan atribut, resident dan non-resident

Isi rekaman file adalah daftar atribut. Informasi standar (cap waktu dll.), nama file, keamanan, dan data. Di sini ada percabangan penting.

flowchart TB
    subgraph REC["Rekaman file MFT (buku besar untuk satu file)"]
        STD["Atribut informasi standar<br/>cap waktu, bendera atribut"]
        FN["Atribut nama file<br/>(dapat punya beberapa ── bab 4)"]
        DATA["Atribut data"]
    end
    Q{"Apakah data kecil"}
    RES["Resident<br/>isi data muat di dalam rekaman<br/>pembacaan selesai hanya dengan akses MFT"]
    NONRES["Non-resident<br/>rekaman hanya memegang «rujukan ke rangkaian cluster»<br/>data nyata ada di area data pengguna"]
    DATA --> Q
    Q -->|"Sampai ratusan byte"| RES
    Q -->|"Lebih dari itu"| NONRES

Gambar 2: Rekaman file adalah kumpulan atribut. Jika data kecil, ia «resident» di dalam rekaman.

Membandingkan bagaimana isi rekaman yang sama berubah antara resident dan non-resident membuatnya lebih mudah dipahami.

flowchart LR
    subgraph RES2["Resident ── file kecil"]
        RA["Rekaman file MFT (panjang tetap)<br/>informasi standar / nama file / keamanan<br/>─────────────<br/>atribut data = isinya sendiri<br/>«nilai pengaturan=1» masuk langsung di sini"]
        RB["Tidak ada tempat terpisah di disk<br/>pembacaan selesai hanya dengan akses ke MFT"]
        RA --> RB
    end
    subgraph NON2["Non-resident ── file besar"]
        NA["Rekaman file MFT (panjang tetap)<br/>informasi standar / nama file / keamanan<br/>─────────────<br/>atribut data = tabel data run<br/>rangkaian «dari mana, berapa cluster»"]
        NB["Area data pengguna<br/>run 1: cluster berkesinambungan"]
        NC["Area data pengguna<br/>run 2: cluster berkesinambungan di tempat lain"]
        NA -->|"Menunjuk posisi"| NB
        NA -->|"Menunjuk posisi"| NC
    end

Gambar 3: Perbandingan resident vs non-resident. Pada non-resident, yang dipegang rekaman hanyalah tabel (data run) «di mana data nyata ada dan berapa banyak».

Semakin banyak jumlah data run, semakin Anda harus menyeberangi area yang tersebar untuk membaca satu file. Inilah identitas fragmentasi yang disebut berikutnya.

Dari struktur ini, beberapa fenomena yang dijumpai di lapangan dapat dijelaskan.

• Alasan menyalin 10.000 file kecil lambat. Per file, operasi metadata pembuatan rekaman MFT, pendaftaran nama, dan pengaturan keamanan terjadi. Pekerjaan buku besar menjadi dominan dibanding transfer data itu sendiri (dan setiap satunya juga menjadi sasaran pemeriksaan filter yang kita lihat di bagian 6).
• Identitas fragmentasi. Data non-resident dicatat sebagai «kolom rentang berkesinambungan cluster (run)». Jika area berkesinambungan tidak dapat diambil, jumlah run bertambah, dan seek yang diperlukan untuk pembacaan bertambah — inilah fragmentasi. Rangkaian run yang sebenarnya dapat dilihat dengan fsutil file layout.
• «Folder» pun tidak istimewa. Direktori adalah «file yang punya indeks dari nama file ke nomor rekaman MFT». Di atas buku besar, semuanya duduk di atas mekanisme yang sama.

3. Data hanyalah salah satu «stream»

3.1. Satu file, beberapa rangkaian byte

Di NTFS, satu file dapat punya beberapa data stream. Yang biasa dibaca dan ditulis dengan ReadFile/WriteFile adalah stream default tanpa nama, dan dengan sintaks namafile:namastream Anda dapat membuat alternate data stream (ADS).²

flowchart LR
    subgraph F["File bernama report.docx (satu rekaman MFT)"]
        D0["Stream default (tanpa nama)<br/>= isi yang biasa dilihat"]
        D1[":Zone.Identifier<br/>informasi asal (Mark of the Web)"]
        D2[":Nama sembarang<br/>informasi tambahan khusus aplikasi"]
    end

Gambar 4: Beberapa data stream. Yang muncul di tampilan ukuran Explorer hanyalah stream default.

ADS yang paling akrab adalah Zone.Identifier. Pada file yang diunduh lewat browser, asal (berasal dari internet dll.) dicatat di stream ini, dan menjadi bahan penilaian «PC Anda dilindungi oleh Windows» SmartScreen serta Protected View Office. Sisi tampak mekanisme ini dibahas di «Alasan «PC Anda dilindungi oleh Windows» muncul di Windows» — identitas sisi belakangnya hanyalah stream NTFS.

3.2. Jebakan yang diinjak pengembang

• Tidak terlihat. Tidak muncul di ukuran Explorer maupun daftar dir. Dapat diperiksa dengan dir /r atau streams Sysinternals.¹¹
• Tidak dapat dibawa. ADS adalah fitur NTFS, jadi sering hilang pada salinan lewat USB FAT atau penyimpanan cloud. «Peringatan unduhan hilang setelah disalin» adalah ini.
• Aplikasi sendiri juga dapat membukanya. Cukup sertakan titik dua di jalur seperti CreateFile("data.txt:meta", ...) untuk membaca dan menulis.² Nyaman, tetapi Anda juga menerima sifat «tidak dapat dibawa» di atas, jadi bukan tempat untuk menaruh isi data bisnis.

4. Nama pun atribut — hard link dan nama 8.3

4.1. Hard link — beberapa nama ke rekaman yang sama

Di Gambar 2 kita menulis «atribut nama file dapat punya beberapa». Di dalam volume yang sama, beberapa jalur merujuk satu file — inilah hard link (CreateHardLink / mklink /H).³

flowchart TB
    subgraph DIR1["Indeks C:\\app\\"]
        E1["config.json → rekaman #1234"]
    end
    subgraph DIR2["Indeks C:\\backup\\"]
        E2["config-link.json → rekaman #1234"]
    end
    REC["Rekaman MFT #1234<br/>isi data (atau rujukan ke run)<br/>jumlah tautan: 2"]
    E1 --> REC
    E2 --> REC

Gambar 5: Hard link. Indeks direktori hanya menunjuk rekaman MFT yang sama, dan keduanya «yang asli».

Perubahan dari nama mana pun adalah file yang sama, jadi isinya segera cocok.³ Dan arti «penghapusan» berubah — DeleteFile adalah «melepas satu nama», dan entitas baru hilang ketika nama terakhir dilepas, handle yang terbuka ditutup, dan rujukan di dalam kernel seperti bagian memory-map juga semuanya hilang. Dua tahap cleanup (handle terakhir) dan close (rujukan terakhir) yang kita lihat di bagian 1 berlaku apa adanya pada umur penghapusan. Selain itu tampilan atribut punya keanehan; secara resmi dicatat bahwa mengubah atribut lewat satu tautan dapat membiarkan tampilan tautan lain tampak usang.³

4.2. Nama 8.3 — satu nama tersembunyi lagi

Demi kompatibilitas historis, NTFS dapat secara otomatis menghasilkan nama pendek format 8.3 seperti REPORT~1.DOC untuk nama file panjang. Ini juga tinggal bersama di rekaman sebagai «satu nama lagi». Di folder dengan banyak file, pembuatan nama pendek dan penghindaran tabrakan menjadi biaya, jadi fsutil 8dot3name dapat menonaktifkan pembuatan atau menghapus nama pendek yang sudah ada (jika ada aplikasi lama yang mencatat jalur registri dengan nama pendek, ia rusak, jadi adanya fungsi pemeriksaan sebelum strip juga poin praktis).⁴

Yang perlu diperhatikan di sini adalah bahwa ada atau tidaknya nama pendek bergantung pada lingkungan. Perilaku default ditentukan nilai registri NtfsDisable8dot3NameCreation, dengan empat cara: 0 (hasilkan di semua volume), 1 (jangan hasilkan di semua volume), 2 (atur per volume), 3 (jangan hasilkan kecuali di volume sistem).⁴ Jika memilih 2, dapat dialihkan per volume, jadi «di Windows nama pendek seperti PROGRA~1 pasti ada» tidak selalu benar. Sebelum menulis kode atau prosedur yang bergantung pada nama pendek, konfirmasikan keadaan saat ini dengan fsutil 8dot3name query C: (jika volume dihilangkan, pengaturan default bersama semua volume).

Jebakan seputar jalur dan nama (MAX_PATH, nama cadangan, titik di akhir) dibahas secara rinci di «MAX_PATH dan jebakan jalur serta nama file Windows». Menggabungkan resolusi nama bagian 1 (Object Manager) dengan bab ini (nama di dalam sistem file) memberi gambaran keseluruhan «nama» Windows.

5. Reparse point — mekanisme «buka, lalu ke tempat lain»

File atau direktori dapat diberi reparse point. Identitasnya adalah atribut «tag + data yang didefinisikan pengguna». Ketika sistem file membuka file dengan reparse point, pemrosesan diserobot menurut tag — driver filter yang memahami tag mengambil alih pemrosesan, atau untuk tag jenis penggantian nama, resolusi diulang dengan jalur tujuan tautan.⁵

sequenceDiagram
    participant App as Aplikasi
    participant IOM as I/O Manager
    participant FS as NTFS

    App->>IOM: CreateFile("C:\\data\\link.txt")
    IOM->>FS: IRP_MJ_CREATE (dunia bagian 1)
    Note over FS: Reparse point ditemukan pada sasaran<br/>mengembalikan tag dan data
    alt Symbolic link / junction (penggantian nama)
        FS-->>IOM: «Tempat yang sebenarnya adalah sini»
        IOM->>FS: Mengulang resolusi dengan jalur tujuan tautan
    else Tag yang dikelola filter (file cloud dll.)
        Note over FS: Filter yang memahami tag<br/>mengambil alih pemrosesan (bagian 6)
    end

Gambar 6: Resolusi reparse point. Ini hook resmi yang menyela operasi «membuka».

Di atas satu mekanisme ini, fitur yang akrab berbaris.

• Symbolic link (mklink) — rambu yang memegang jalur tujuan. Dapat menunjuk ke volume lain atau jalur UNC.⁶
• Junction / mount point — mekanisme senior yang menghubungkan direktori ke posisi di volume lokal lain.³
• Files On-Demand OneDrive — mengekspresikan file yang data nyatanya tidak di tangan sebagai reparse point, dan pada saat dibuka filter mengunduh dan menyerahkan isinya. Identitas «terlihat di Explorer, tetapi komunikasi berjalan saat dibuka» (mekanisme filter itu sendiri di bagian 6).

Satu perhatian praktis. «Ujung jalur belum tentu lokasi lokal itu sendiri». Alat yang menelusuri pohon secara rekursif berputar di junction, agregasi ukuran menjadi ganda, cadangan memicu materialisasi cloud secara massal — kode yang tidak tahu keberadaan reparse point menginjak ini. Konfirmasi atribut FILE_ATTRIBUTE_REPARSE_POINT keluarga FindFirstFile adalah pintu masuk penanggulangan.⁵

6. Dua jurnal — $LogFile dan USN

Sering dikatakan «NTFS adalah sistem file berjurnal», tetapi NTFS punya dua jurnal dengan peran berbeda. Mencampuradukkannya membuat jaminan terbaca salah.

flowchart TB
    subgraph J1["$LogFile ── log di muka (agar tidak rusak)"]
        A1["Mencatat operasi metadata (pembaruan rekaman, ganti nama dll.)<br/>ke log sebelum dieksekusi"]
        A2["Pada mulai berikutnya setelah kegagalan sistem,<br/>memutar ulang log untuk memulihkan konsistensi struktur"]
        A1 --> A2
    end
    subgraph J2["Jurnal USN ── riwayat perubahan (untuk mengetahui apa yang berubah)"]
        B1["Setiap perubahan pada file / direktori,<br/>mencatat isi perubahan dan nama"]
        B2["Alat cadangan, indeks pencarian, sinkronisasi<br/>mengetahui «apa yang berubah sejak terakhir» tanpa pemindaian penuh"]
        B1 --> B2
    end

Gambar 7: Dua jurnal. $LogFile agar «tidak rusak», USN agar «mengetahui perubahan».

Perbedaannya dalam tabel adalah sebagai berikut.

Tabel 2: Perbandingan dua jurnal.

• $LogFile (log transaksi) adalah log di muka operasi metadata. Bahkan jika kegagalan sistem terjadi, NTFS secara otomatis memulihkan konsistensi sistem file dari log ini dan informasi checkpoint pada mulai berikutnya.⁷ Yang dilindungi di sini adalah struktur. Seperti yang kita lihat di bagian 4, isi data dirty di cache dapat hilang saat pemutusan daya — pembacaan yang benar adalah «volume tidak rusak. Namun penulisan terakhir dapat hilang».
• Jurnal USN (jurnal perubahan) adalah buku besar yang, setiap kali file atau direktori di volume berubah, mencatat isi perubahan dan nama sasaran.⁸ Mekanisme agar cadangan atau pengindeks mengambil «hanya yang berubah sejak terakhir» tanpa pemindaian penuh, dan juga dipakai untuk menghindari pembangunan ulang indeks setelah kegagalan.⁸ Dalam praktik, berguna diingat bahwa fsutil usn readjournal dapat dipakai sebagai buku besar pencocokan untuk menutupi ketinggalan FileSystemWatcher («Panduan praktis FileSystemWatcher»).

7. Sparse dan kompresi — cerita ada dua «ukuran»

Di NTFS, panjang logis file dan area yang benar-benar dialokasikan dikelola secara terpisah. «Ukuran» dan «ukuran di disk» di layar properti. Dua yang representatif menghasilkan kesenjangan.

File sparse mengelola rentang yang berlanjut sebagai nol sebagai «lubang» tanpa mengalokasikan area nyata.⁹ File disk virtual berukuran logis 42 GB yang di disk hanya memakai 500 MB — terjadi secara biasa. Membaca lubang mengembalikan nol, dan menulis mengalokasikan sebesar itu.

flowchart LR
    subgraph L["File logis (ukuran: 1 GB)"]
        R1["Data 10 MB"]
        H1["Lubang (nol) 500 MB"]
        R2["Data 5 MB"]
        H2["Lubang (nol) sisanya"]
    end
    subgraph P["Alokasi di disk (15 MB + informasi pengelolaan)"]
        A1["Run: entitas R1"]
        A2["Run: entitas R2"]
    end
    R1 --> A1
    R2 --> A2

Gambar 8: File sparse. «Lubang» tidak punya alokasi, sehingga ukuran logis dan ukuran di disk menyimpang.

Kompresi NTFS mengompresi dan menyimpan data per unit kompresi.¹⁰ Transparan dan nyaman, tetapi biayanya juga tidak transparan — setiap baca tulis menjalankan ekspansi dan kompresi ulang, dan fragmentasi juga lebih mudah maju. Dan seperti yang kita lihat di bab 5 bagian 2, akses ke file terkompresi tidak menjadi asinkron (sistem file mengubahnya menjadi sinkron). Salah satu tempat yang dicurigai ketika «sudah dijadikan I/O asinkron tetapi ada file yang tidak menjadi cepat».

Ukuran nyata berbasis alokasi dapat diambil dengan GetCompressedFileSize. Dalam investigasi «jumlah ukuran file» dan «pemakaian disk» tidak cocok, praktik standar adalah mencurigai sparse, kompresi, ADS (bab 3), dan pembulatan cluster secara berurutan.

8. Konfirmasikan dengan mata sendiri

Kali ini pun, semuanya dapat diamati di Windows di tangan (sebagian memerlukan hak administrator). Agar Anda sendiri dapat menilai apakah hasil eksekusi benar, setiap perintah dilengkapi apa yang dilihat di mana.

:: Lihat stream alternatif
dir /r C:\Users\%USERNAME%\Downloads

Lihat di sini: di bawah baris file biasa, baris berbentuk namafile:Zone.Identifier:$DATA yang diinden berbaris dengan panjang. Jika baris ini ada, file itu dalam keadaan punya Mark of the Web (bab 3). File yang diunduh lewat browser memilikinya, file yang Anda buat sendiri tidak. Menjalankan di kedua tempat dan membandingkan membuat ada-tidaknya ADS jelas.

:: Lihat tata letak (run) dan atribut file di MFT
fsutil file layout C:\path\to\file.dat

:: Lihat extent saja (subperintah yang tercantum di dokumentasi resmi)
fsutil file queryextents C:\path\to\file.dat

Lihat di sini: layout menyusun, per stream, ukuran, ukuran alokasi, dan jika non-resident, daftar extent (pasangan VCN, LCN, jumlah cluster). File sangat kecil yang tidak mengeluarkan baris extent adalah resident (bab 2.2); jika terpecah ke beberapa baris, ia terfragmentasi. Menjalankan pada file teks beberapa byte dan file ratusan MB lalu membandingkan adalah cara tercepat merasakan resident/non-resident.

:: Pengaturan pembuatan nama pendek 8.3, dan nama pendek yang sudah ada
fsutil 8dot3name query C:
dir /x

Lihat di sini: query mengembalikan apakah pembuatan nama pendek di volume itu aktif atau nonaktif (jika volume dihilangkan, pengaturan default bersama semua volume).⁴ dir /x menampilkan kolom nama pendek di samping nama panjang, jadi jika kolom kosong, nama pendek tidak dibuat. «Nama pendek tidak selalu ada» di bab 4.2 dapat dikonfirmasi di lingkungan sendiri.

:: Status jurnal USN
fsutil usn queryjournal C:

Lihat di sini: ID jurnal, rentang USN yang valid (First USN / Next USN), ukuran target maksimum (MaximumSize), dan satuan alokasi (AllocationDelta) ditampilkan.¹² Setelah membuat suatu file lalu menjalankan lagi, Next USN seharusnya maju; ini konfirmasi bahwa «perubahan sedang dicatat». MaximumSize adalah petunjuk «sejauh mana dapat ditelusuri» yang disinggung di bab 6. Di volume dengan jurnal nonaktif, terjadi error.

:: Konfirmasi reparse point (tujuan tautan dan tag)
dir /aL C:\Users\%USERNAME%
fsutil reparsepoint query "C:\Users\%USERNAME%\OneDrive"

Lihat di sini: yang muncul di dir /aL adalah reparse point (yang FILE_ATTRIBUTE_REPARSE_POINT-nya berdiri). Symbolic link dan junction ditampilkan dengan jenis seperti <SYMLINKD> <JUNCTION>. fsutil reparsepoint query menampilkan nilai reparse tag, dan untuk jenis penggantian nama, jalur tujuan tautan. Menetapkan sasaran yang bukan reparse point menghasilkan error, jadi error itu sendiri adalah konfirmasi «ini folder biasa».

Mengikuti operasi file di Procmon, tokoh kali ini mengalir dengan nama aslinya (penulisan ke $LogFile, jalur dengan nama stream, pemrosesan reparse). Cara pemakaiannya lihat «Panduan praktis Process Monitor (ProcMon)».

9. Ringkasan

• Pusat NTFS adalah MFT. Semua file adalah rekaman buku besar, dan informasi ada «di dalam rekaman» atau «di area eksternal yang ditunjuk rekaman». Data kecil resident, data besar rujukan run, dan kelambatan pemrosesan massal file kecil serta fragmentasi adalah konsekuensi struktur ini.¹
• Data stream dapat punya beberapa. Zone.Identifier (Mark of the Web) hanyalah ADS, terlihat dengan dir /r, dan tidak dibawa ke luar NTFS.²¹¹
• Nama adalah atribut, dan dapat punya beberapa. Hard link adalah nama setara ke rekaman yang sama, nama 8.3 adalah satu nama lagi untuk kompatibilitas. «Penghapusan = melepas nama», dan hilangnya entitas adalah ketika nama terakhir, handle, dan rujukan di dalam kernel (bagian yang dipetakan dll.) semuanya hilang.³⁴
• Reparse point adalah hook resmi ke «membuka», dan symbolic link, junction, maupun Files On-Demand semuanya penerapannya. Kode yang menelusuri pohon perlu menyadari FILE_ATTRIBUTE_REPARSE_POINT.⁵⁶
• Ada dua jurnal. $LogFile adalah pemulihan konsistensi struktur (agar tidak rusak), USN adalah riwayat perubahan (apa yang berubah). Bukan «berjurnal jadi data juga aman» — ketahanan data dibuat dengan alat bagian 4.⁷⁸
• Ukuran logis dan alokasi adalah hal yang berbeda. Sparse, kompresi, ADS, dan pembulatan cluster adalah empat penyebab utama «ukuran tidak cocok». Termasuk soal file terkompresi yang tidak menjadi I/O asinkron, ini menjadi laci investigasi kinerja.⁹¹⁰

Lanjutannya adalah bagian terakhir, bagian 6 «Driver filter dan minifilter — alasan Procmon dan pemindaian virus dapat menyela I/O». Bagaimana «mereka yang menyelip di tengah» yang muncul dari bagian 1 — antivirus, Procmon, OneDrive, enkripsi — menyela I/O. Sebagai penutup seri, identitas penghuni yang berdiri di celah device stack diungkapkan.

Artikel terkait

• Kedalaman I/O Windows (bagian 1) — setiap baca tulis menjadi IRP: gambaran keseluruhan sistem I/O
• Kedalaman I/O Windows (bagian 2) — I/O sinkron dan asinkron: arti sesungguhnya OVERLAPPED
• Kedalaman I/O Windows (bagian 4) — Cache Manager: kapan WriteFile Anda benar-benar sampai ke disk
• Alasan «PC Anda dilindungi oleh Windows» muncul di Windows
• MAX_PATH dan jebakan jalur serta nama file Windows — batas 260 karakter, nama cadangan, titik di akhir, huruf besar-kecil
• Panduan praktis FileSystemWatcher — penanggulangan ketinggalan dan duplikasi
• Jebakan network drive dan jalur UNC — praktik menangani file server (folder berbagi) di aplikasi bisnis
• Panduan praktis Process Monitor (ProcMon) — mengidentifikasi «pengaturan tidak terbaca» / «ACCESS DENIED» dalam 10 menit

Area konsultasi terkait

KomuraSoft LLC menangani desain dan investigasi aplikasi bisnis Windows yang berakar pada mekanisme NTFS, seperti perilaku tidak masuk akal ukuran file atau kinerja salinan, serta bug yang melibatkan tautan dan stream.

• Pengembangan aplikasi Windows
• Investigasi bug dan akar masalah
• Pemanfaatan aset yang ada dan dukungan migrasi
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Apa itu MFT (Master File Table)?

Struktur data di jantung volume NTFS — buku besar yang memegang setidaknya satu entri (rekaman file) untuk setiap file di volume, termasuk entri untuk MFT itu sendiri. Segala sesuatu tentang file, dari ukurannya, cap waktu, dan izin akses sampai isi data itu sendiri, disimpan baik di dalam entri MFT atau di area di luar MFT yang ditunjuk entri. File kecil muat seluruhnya, data dan semua, di dalam entri MFT-nya (resident); file besar hanya punya rujukan ke tata letak datanya (rangkaian cluster) yang dicatat di entri (non-resident). Menghapus file menandai entri sebagai bebas untuk dipakai ulang, tetapi ukuran MFT itu sendiri tidak pernah menyusut.

Apa data tak terlihat «Zone.Identifier» yang menempel pada file?

Ini salah satu dari beberapa data stream NTFS (alternate data stream). Di NTFS, satu file dapat memegang beberapa rangkaian byte (stream); yang biasa Anda baca dan tulis adalah stream default tanpa nama. Windows mencatat dari mana file berasal — bahwa ia diunduh dari internet, misalnya — di stream tambahan yang Anda tetapkan dengan titik dua, seperti «file.txt:Zone.Identifier». Ini yang disebut «Mark of the Web», dan menjadi bahan penilaian SmartScreen serta Protected View Office. Stream alternatif tidak muncul di tampilan ukuran Explorer; Anda dapat memeriksanya dengan perintah dir /r atau alat streams Sysinternals. Juga perlu diperhatikan bahwa mereka tidak dipertahankan ketika disalin ke sistem file non-NTFS seperti FAT.

Apa perbedaan hard link dan symbolic link?

Hard link adalah «satu nama lagi dengan status setara yang ditambahkan, menunjuk ke entitas file yang sama — rekaman MFT yang sama». Ia hanya dapat dibuat di dalam volume yang sama; mengakses file lewat nama mana pun memberi file yang sama; dan menghapus satu nama tidak menghapus file selama nama lain masih tersisa. Symbolic link adalah «rambu yang mengarahkan ke jalur berbeda», diimplementasikan sebagai reparse point. Karena hanya memegang jalur tujuan sebagai string, ia dapat menunjuk ke volume lain atau bahkan lokasi remote, tetapi menjadi jalan buntu jika tujuan hilang. Dalam praktik, aturan praktisnya: pakai hard link untuk berbagi entitas di bawahnya (yang mengubah arti penghapusan), dan pakai symbolic link untuk mengalihkan jalur (untuk pemindahan atau pengalihan).

NTFS adalah sistem file berjurnal, jadi apakah data selamat dari pemutusan daya?

Anda perlu memahami persis apa yang dilindungi. Yang dilindungi log transaksi NTFS ($LogFile) adalah konsistensi struktur sistem file (metadatanya). Bahkan jika kegagalan sistem terjadi, NTFS secara otomatis memulihkan konsistensi memakai log pada mulai berikutnya, mencegah situasi volume rusak dan tidak dapat dibaca. Tetapi itu tidak berarti isi aktual file yang sedang ditulis dipulihkan. Seperti yang kita lihat di bagian 4 seri ini, data dirty yang duduk di cache hilang saat pemutusan daya. Jadi pemahaman yang benar adalah «volume tidak akan rusak, tetapi isi penulisan terakhir masih dapat hilang» — jika Anda memerlukan ketahanan untuk data itu sendiri, Anda harus membangunnya sendiri, dengan FlushFileBuffers, WRITE_THROUGH, atau desain penulisan tingkat aplikasi seperti tulis-ke-file-sementara-lalu-ganti-nama.

Mengapa «ukuran» file berbeda dari «ukuran di disk»?

Karena NTFS mengelola panjang logis file dan ruang disk yang benar-benar dialokasikan secara terpisah. Bahkan file biasa menunjukkan selisih karena alokasi dibulatkan ke cluster utuh (default 4 KB), tetapi file sparse dan file terkompresi adalah tempat kesenjangan menjadi besar. File sparse tidak mengalokasikan penyimpanan nyata ke rentang yang berlanjut sebagai nol — ia mengelolanya sebagai «lubang» — jadi sepenuhnya mungkin file dengan ukuran logis beberapa gigabyte hanya memakai beberapa megabyte di disk. File terkompresi hanya punya ukuran pasca-kompresi yang dialokasikan. Sebaliknya, jika «ukuran di disk» tampak lebih besar, pembulatan cluster atau alternate data stream sering menjadi penyebabnya.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.