Apakah file berumur pendek dibuang ke disk?


9

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.


> Program saya membuat banyak file kecil berumur pendek berapa 'banyak'? Apakah Anda menghapus file-file ini atau menulis ulang file? > Saya juga ingin tahu apakah metadata atau data ditulis ke disk. Saya percaya mode metadata default dipesan yang berarti metadata dilakukan sebelum data ditulis ke disk. Tentu saja ada opsi mount yang dapat Anda tambahkan untuk mengubah ini. > Pertanyaan saya adalah, apakah program saya menyebabkan banyak disk menulis? ini sulit untuk menanggapi mengingat informasi yang Anda berikan. Sudahkah Anda mempertimbangkan untuk menggunakan alat seperti iotop dan sysstat untuk memonitor IO disk?
AngryWombat

ReiserFS lebih baik untuk file kecil jika Anda benar-benar ingin mereka menekan disk tmpfs baik-baik saja jika Anda tidak peduli
xenoterracide

Beberapa klarifikasi: (1). sistem file ext4 tidak dipasang dengan syncopsi. Anda dapat mempertimbangkan fedora, debian, atau ubuntu yang diinstal secara default. Anda pilih satu. (2) Setiap file sekitar 60KB. (3) Sekitar 1000 file dibuat dan dihapus per detik, tetapi tidak lebih dari 10 file setiap saat. Dengan kata lain, throughput I / O besar tetapi ruang yang ditempati kecil.
Wu Yongzheng

Jawaban:


5

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.


Usaha yang bagus. Sekarang saya yakin. Saya juga mencoba ext2, dan mendapat hasil yang sama seperti Anda. Saya mengubah beban kerja I / O paralel Anda menjadi berurutan dan mendapatkan satu file berumur pendek-999 dan 8 konten berumur pendek- *. Adakah yang punya penjelasan?
Wu Yongzheng

@ msw: diedit kalau-kalau tidak jelas. Kalau tidak, tolong jelaskan.
frostschutz

Itu konyol. File ada secara bersamaan, tidak ada yang ditimpa, dan sistem file tidak menimpa konten file yang dihapus karena hal itu akan merusak kinerja. Tetapi dengan segala cara, gunakan nbddan catat lalu lintas (atau metode serupa untuk melacak semua penulisan).
frostschutz

7

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 ,


2
tmpfs memang cocok untuk kasus ini, tetapi saya masih ingin tahu, sebagai pertanyaan sistem operasi umum, apakah data ditulis ke disk (tidak perlu)?
Wu Yongzheng

Pertanyaan Anda harus jauh lebih spesifik daripada yang mungkin dapat Anda rumuskan untuk menerima jawaban yang pasti. Cache penyangga memediasi pertukaran rumit antara kinerja dan kegigihan yang tidak bisa dijawab secara abstrak. Dengan menggunakan alat @AngryWombat yang tercantum, Anda dapat mengukur penulisan aktual di bawah dari aplikasi spesifik Anda, tetapi ada begitu banyak faktor yang dapat membuatnya berbeda dari menjalankan ke menjalankan.
msw

Nah, jika pdflush muncul setelah file dihapus. Menulis itu tidak perlu.
Wu Yongzheng

1

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.


0

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) .


Terima kasih atas jawaban anda. Tampaknya ext4 juga mengalami keterlambatan alokasi. Apakah itu berarti jawaban saya adalah TIDAK? (tidak diberikan opsi konfigurasi lucu di tempat lain). Apakah itu juga berarti jawaban saya YA jika ext2 digunakan?
Wu Yongzheng

Saya akan berpikir bahwa bahkan dengan ext2 pada kernel modern jawabannya adalah TIDAK. Masalah khusus ini banyak dibahas dan pandangan sekilas pada sumber kernel menunjukkan bahwa driver ext2 sebagian besar bergantung pada operasi kernel "default" untuk melakukan tugasnya (dengan demikian, semuanya tertunda oleh cache blok). Saya kira, saya harus memperbarui jawaban saya, untuk memasukkan beberapa info tambahan.
oakad

Ext4 saya jelas tidak di-mount dengan syncopsi. Aku tidak akan melakukan itu.
Wu Yongzheng

Ketika menandai inode kotor, saya menganggap sistem file bertanggung jawab untuk menandai kotor halaman yang sesuai. Kemudian ketika inode dihapus, apakah sistem file membersihkan halaman yang kotor? Jika tidak, data akan dibuang ke disk jika tidak perlu.
Wu Yongzheng

2
Blok data yang tidak digunakan "dirilis", sehingga berhenti kotor. Jika Anda menulis beberapa hal untuk diarsipkan, dan kemudian memotongnya sebelum dibilas, sampah yang melewati EOF hilang begitu saja (semacam). Dengan metadata mungkin tidak sesederhana itu karena mungkin ada berbagai trade off mengenai integritas struktur data sistem file. Ngomong-ngomong, tidak jelas dari pertanyaan Anda bahwa Anda selalu berharap untuk memegang kendali penuh atas platform Anda - sebagian besar aplikasi biasanya berakhir pada mesin dengan konfigurasi yang tidak diketahui, jauh dari pengembang.
oakad
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.