Apakah file berumur pendek dibuang ke disk?

Program saya membuat banyak file kecil berumur pendek. Biasanya dihapus dalam satu detik setelah pembuatan. File-file tersebut berada dalam sistem file ext4 yang didukung oleh hard disk nyata. Saya tahu bahwa Linux secara berkala membersihkan ( pdflush) halaman-halaman kotor ke disk. Karena file saya berumur pendek, kemungkinan besar file tersebut tidak di-cache oleh pdflush. Pertanyaan saya adalah, apakah program saya menyebabkan banyak disk menulis? Kekhawatiran saya adalah kehidupan hard disk saya.

Karena file kecil, mari kita asumsikan jumlah ukurannya lebih kecil dari dirty_bytesdan dirty_background_bytes.

Ext4 memiliki jurnal default dihidupkan, yaitu jurnal metadata. Saya juga ingin tahu apakah metadata atau data ditulis ke disk.

Eksperimen sederhana menggunakan ext4:

Buat gambar 100MB ...

# dd if=/dev/zero of=image bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0533049 s, 2.0 GB/s

Jadikan itu perangkat loop ...

# losetup -f --show image
/dev/loop0

Buat filesystem dan mount ...

# mkfs.ext4 /dev/loop0
# mount /dev/loop0 /mnt/tmp

Buat semacam dijalankan dengan file berumur pendek. (Ubah ini ke metode apa pun yang Anda inginkan.)

for ((x=0; x<1000; x++))
do
    (echo short-lived-content-$x > /mnt/tmp/short-lived-file-$x
     sleep 1
     rm /mnt/tmp/short-lived-file-$x ) &
done

Umount, sinkronkan, lepaskan.

# umount /mnt/tmp
# sync
# losetup -d /dev/loop0

Periksa isi gambar.

# strings image | grep short-lived-file | tail -n 3
short-lived-file-266
short-lived-file-895
short-lived-file-909
# strings image | grep short-lived-content | tail -n 3

Dalam kasus saya, daftar semua nama file, tetapi tidak ada konten file. Jadi hanya isinya yang tidak tertulis.

Kecuali Anda berbicara tentang solid-state drive, sejumlah besar penulisan disk tidak akan menjadi faktor dominan dalam umur drive.

Jika Anda benar-benar ingin menghindari penulisan disk, lihatlah ke tmpfs ,

Sebagai aturan umum, tidak, mereka tidak akan ditulis. Ini karena cache membersihkan halaman kotor ketika salah satu dari dua kondisi terpenuhi:

1. Data sudah kadaluwarsa /proc/sys/vm/dirty_writeback_centisecs, yang defaultnya adalah 5 detik.

2. Ada terlalu sedikit memori untuk cache untuk menyimpan data, lebih dari dirty_ratiohalaman kotor dalam cache (default ke 20%).

Jadi pada sistem dengan banyak memori bebas dan sedikit lalu lintas tulis selain dari file kecil Anda yang dihapus dalam waktu kurang dari 5 detik, data tidak akan memerah.

Apakah file berumur pendek dapat ditulis ke disk atau tidak tergantung tidak hanya pada perilaku default dari cache file kernel, tetapi juga pada detail implementasi driver sistem file dan opsi mount dari sistem file tersebut. Dimungkinkan untuk mengkonfigurasi sistem sedemikian rupa sehingga semuanya akan selalu segera dituliskan ke disk (pada dasarnya, perilaku seperti DOS).

Satu sistem file, yang secara jelas menampilkan perilaku yang Anda minati (disebut "alokasi tertunda") adalah XFS. Dengannya Anda bisa lebih atau kurang yakin (tidak diberi opsi konfigurasi lucu di tempat lain) bahwa blok-blok milik hanya file yang dihapus akan digunakan kembali dalam memori, tanpa akses disk menengah. XFS mungkin masih ingin memperbarui jurnal metadata-nya (yang akan ditulis ke disk agak sering; namun, mengingat jurnal XFS adalah metadata saja, itu cukup kecil untuk diatur pada beberapa perangkat lain yang cepat, seperti RAM yang didukung baterai ditemukan pada banyak pengontrol RAID).

Karena perilaku ini, tidak jarang ditemukan benar-benar nol, tetapi sebaliknya mencari file yang sah (ukuran dan metadata lainnya utuh) pada sistem file XFS setelah gangguan daya tiba-tiba. Tersebut adalah biaya untuk mendukung operasi file "semi-sementara" cepat.

Beberapa teori

Secara umum, panggilan sistem yang mengakses sistem file berakhir, agak cepat, dalam metode yang ditentukan driver sistem file (terlampir pada "struct inode_operations" dan "struct file_operations" ketika driver VFS terdaftar). Apa yang terjadi setelah itu hanya menjadi kebijaksanaan implementasi sistem file. Biasanya, sesuatu yang menyerupai pendekatan berikut digunakan (contoh sederhana ini adalah dari driver FAT linux):

if (IS_DIRSYNC(dir))
    (void)fat_sync_inode(dir);
else
    mark_inode_dirty(dir);

Jika sistem file dipasang dalam mode "sinkronisasi", semua perubahan langsung menuju disk (melalui fat_sync_inode () dalam kasus ini). Jika tidak, blok tersebut ditandai sebagai "kotor" dan tetap berada dalam cache memori sampai memerah pada kesempatan yang masuk akal.

Dengan demikian, tidak mungkin untuk memprediksi perilaku sistem sehubungan dengan file sementara tanpa mempertimbangkan opsi pemasangan sistem file dan memeriksa kode sumber implementasinya (ini, tentu saja, sebagian besar berlaku untuk semua jenis sistem file eksotis yang sebagian besar ditemukan di ruang tertanam) .