Algoritma alokasi blok apa yang digunakan NTFS?

Pada Windows XP 64, saya mengunduh file 1,2 GB dan akhirnya terfragmentasi, seperti yang ditunjukkan gambar. Sayangnya, sebelum mengambil snapshot dari Piriform Defraggler, saya mendefrag file lain, sehingga Anda tidak dapat melihat kondisi yang tepat pada saat file tersebut ditulis. Namun, disk sepanjang waktu kosong seperti sekarang (25% digunakan) dan hampir tidak terfragmentasi.

Algoritma alokasi blok apa yang digunakan NTFS? Sepertinya acak atau mungkin meletakkannya di tempat kepala disk sebenarnya.

MEMPERBARUI:

Inilah yang terjadi hari ini setelah menulis 67 MiB file baru. Ia dipecah menjadi 731 fragmen, ukuran rata-rata hanya 95 KiB. File ini digunakan untuk mengisi beberapa celah, tetapi tidak semuanya, tidak menggunakan ruang bebas yang besar secara terus menerus. Aneh bukan?

PEMBARUAN 2:

Tidak seperti PC Guru , saya benar-benar tidak berpikir Opera adalah penyebabnya. Saya pikir itu (tidak seperti Google Chrome) tidak memberi tahu Windows ukuran yang diharapkan, namun, ada banyak kasus ketika itu tidak mungkin dan merupakan tanggung jawab OS untuk menanganinya dengan cara yang waras. Gambar berikut menunjukkan apa yang terjadi setelah beberapa hari dengan saya hampir tidak melakukan apa-apa pada partisi ini - direktori TEMP dan semua data saya (kecuali yang dikelola oleh Windows) keduanya terletak di tempat lain. Windows sendiri tampaknya tidak menggunakan SetEndOfFiledan mem-fragmen file-nya sendiri dengan cara yang mengerikan (600 fragmen untuk beberapa file kecil sekitar 40 MB). NTFS tampaknya tidak menggunakan sektor pertama yang tersedia, karena ada lagi file di tengah dan juga di dekat akhir disk yang cukup kosong (penggunaan 23%),

IIRC, sistem file NTFS mencoba untuk mengalokasikan file dalam penyimpanan yang berdekatan. Namun itu hanya bisa melakukan itu jika sistem file mengetahui ukuran file. Jika Anda membuka file dan mulai menulis untuk itu, itu akan menulis ke tempat "terbaik" agar sesuai dengan file (biasanya menuju bagian luar piring). Tapi tempat "terbaik" itu mungkin tidak cukup besar untuk muat file.

Jika aplikasi memberi tahu NTFS ukuran sebenarnya dari file (dengan SetEndOfFile ()), NTFS dapat melakukan pekerjaan yang lebih baik untuk menemukan ruang yang berdekatan untuk file tersebut (API SetEndOfFile menyebabkan NTFS mengalokasikan penyimpanan untuk seluruh file).

Masalah Anda pasti dengan Opera. Saya baru saja melihat banyak file pada drive yang sangat penuh dan terfragmentasi. Semua file besar yang diunduh menggunakan Chrome bersebelahan.

Ini menunjukkan bahwa Chrome mengetahui ukuran file pada awal pengunduhan, sehingga memberi tahu NTFS ukuran file yang diharapkan. Jika Anda melakukannya, NTFS akan mencoba menempatkan file dalam satu fragmen, atau ketika tidak ada fragmen yang cukup besar, ke dalam fragmen terbesar yang tersedia. Menariknya selalu menggunakan fragmen-fragmen ini dalam urutan ukuran, sehingga file-file besar yang disalin oleh Explorer ke drive yang terfragmentasi, dapat melompat-lompat di seluruh drive.

Di mana program tidak mengetahui ukuran file, atau tidak repot-repot memberi tahu NTFS, tetapi alih-alih hanya membuka file dan mulai menulis data berurutan, tampaknya NTFS bertindak sangat mirip dengan FAT32, yang hanya dimulai pada kluster pertama yang tersedia (atau yang pertama tersedia setelah dialokasikan terakhir di sesi itu) kemudian menggunakan apa pun yang tersedia dari sana maju. Sebagai contoh, pada waktu yang hampir bersamaan saya meminta CCleaner untuk memindai registri, menyebabkannya untuk kembali ke file ".Reg" txt besar. File ini dimulai di dekat awal drive dan kemudian tersebar di 127 fragmen yang berbeda. Tidak seperti file yang disalin dengan Explorer, atau diunduh dengan Chrome, di setiap file yang saya lihat, cluster dialokasikan dalam urutan menaik.

Untuk penelitian ini saya menggunakan Winhex (versi uji coba gratis tersedia dari Winhex.com). Saat melihat entri direktori. klik kanan pada nama file dan pilih Posisi, Daftar Cluster, untuk melihat daftar cluster yang digunakan oleh file itu.