Menyelam mendalam ke dalam sistem fail jurnal ext3 dalam CentOS-LINUX-php.cn

Kerangka

1. Sistem fail jurnal

2. Kelebihan ext3

3, tiga mod log ext3

4. Pilih mod log

1. Sistem fail jurnal

Biasanya apabila kandungan fail ditulis semasa sistem sedang berjalan, metadata fail (seperti kebenaran, pemilik, penciptaan dan masa capaian) tidak ditulis jika perbezaan masa antara menulis kandungan fail dan sebelum menulis metadata fail adalah Jika sistem ditutup secara tidak normal, sistem fail dalam proses penulisan akan dipunggah secara tidak normal, dan sistem fail akan berada dalam keadaan tidak konsisten. Apabila but semula, Linux akan menjalankan program fsck, mengimbas keseluruhan sistem fail untuk memastikan semua blok fail diperuntukkan atau digunakan dengan betul, mencari entri direktori yang rosak dan cuba membaikinya. Walau bagaimanapun, fsck tidak menjamin bahawa kerosakan akan dibaiki. Apabila ini berlaku, metadata yang tidak konsisten dalam fail akan mengisi ruang fail yang hilang, dan entri fail dalam entri direktori mungkin hilang, mengakibatkan kehilangan fail.

Untuk meminimumkan ketidakkonsistenan sistem fail dan memendekkan masa permulaan sistem pengendalian, sistem fail perlu menjejaki rekod yang menyebabkan perubahan sistem Rekod ini disimpan di tempat yang berasingan daripada sistem fail, yang biasanya dipanggil sebuah "log". Setelah rekod log ini ditulis dengan selamat, sistem fail log boleh menggunakannya untuk membersihkan rekod yang menyebabkan perubahan sistem, dan menyusunnya ke dalam satu set yang menyebabkan perubahan sistem fail, meletakkannya dalam transaksi pangkalan data dan menyimpannya dalam keadaan. Operasi normal data yang sah tidak bercanggah dengan prestasi keseluruhan sistem. Sekiranya berlaku sebarang ranap sistem atau perlu dimulakan semula, data dipulihkan mengikut maklumat yang direkodkan dalam fail log. Memandangkan terdapat pusat pemeriksaan biasa dalam fail log, ia biasanya sangat kemas. Reka bentuk sistem fail terutamanya mempertimbangkan isu kecekapan dan prestasi.

Linux boleh menyokong banyak sistem fail log, termasuk FAT, VFAT, HPFS (OS/2), NTFS (Windows NT), UFS, XFS, JFS, ReiserFS, ext2, ext3, dll.

2. Kelebihan ext3

Kenapa anda perlu berhijrah dari ext2 ke ext3? Berikut ialah empat sebab utama: ketersediaan, integriti data, kelajuan, kemudahan pemindahan.

Ketersediaan

Selepas ranap yang tidak normal (kuasa terputus, sistem ranap), sistem fail ext2 hanya boleh dipasang dan digunakan selepas pengesahan konsisten melalui e2fsck. Masa untuk menjalankan e2fsck terutamanya bergantung pada saiz sistem fail ext2. Mengesahkan sistem fail yang lebih besar sedikit (berpuluh-puluh gigabait) mengambil masa yang lama. Jika terdapat banyak fail pada sistem fail, pengesahan akan mengambil masa yang lebih lama. Mengesahkan sistem fail beberapa ratus gigabait boleh mengambil masa sejam atau lebih. Ini sangat mengehadkan kebolehgunaan. Sebaliknya, melainkan jika kegagalan perkakasan berlaku, ext3 tidak memerlukan pengesahan sistem fail walaupun ia ditutup secara tidak normal. Ini kerana data ditulis pada cakera dengan cara yang konsisten merentasi sistem fail. Selepas penutupan yang tidak normal, masa untuk memulihkan sistem fail ext3 tidak bergantung pada saiz sistem fail atau bilangan fail, tetapi pada saiz "log" yang diperlukan untuk mengekalkan konsistensi. Dengan tetapan log lalai, masa pemulihan hanya satu saat (bergantung pada kelajuan perkakasan).

Integriti Data

Menggunakan sistem fail ext3, prestasi integriti data dijamin dengan pasti semasa penutupan tidak normal. Anda boleh memilih jenis dan tahap perlindungan data. Anda boleh memilih untuk memastikan sistem fail konsisten, tetapi membenarkan data pada sistem fail rosak semasa penutupan tidak normal ini boleh memberikan beberapa peningkatan kelajuan dalam beberapa situasi (tetapi bukan semua situasi). Anda juga boleh memilih untuk memastikan kebolehpercayaan data konsisten dengan sistem fail ini bermakna selepas ranap sistem, anda tidak akan melihat sebarang sampah data dalam fail yang baru ditulis. Pilihan selamat ini, yang mengekalkan integriti data yang konsisten dengan sistem fail, ialah tetapan lalai.

Kelajuan

Walaupun ext3 menulis data lebih banyak kali daripada ext2, ext3 selalunya lebih pantas daripada ext2 (aliran data tinggi). Ini kerana fungsi pengelogan ext3 mengoptimumkan putaran kepala cakera keras. Anda boleh memilih daripada 1 daripada 3 mod pengelogan untuk mengoptimumkan kelajuan, secara selektif mengorbankan beberapa integriti data. Mod pertama, data=writeback, menyediakan integriti data terhad dan membenarkan data lama wujud dalam fail selepas ranap sistem. Mod ini boleh meningkatkan kelajuan dalam situasi tertentu. (Dalam kebanyakan sistem fail jurnal, mod ini ialah tetapan lalai. Mod ini menyediakan integriti data terhad untuk sistem fail ext2, dan lebih kepada mengelakkan pengesahan sistem fail yang panjang apabila sistem bermula) Kedua Mod ini, data = orderd (lalai ), memastikan kebolehpercayaan data konsisten dengan sistem fail; ini bermakna selepas ranap sistem, anda tidak akan melihat sebarang data sampah dalam fail yang baru ditulis. Mod ketiga, data=jurnal, memerlukan jurnal yang lebih besar untuk memastikan kelajuan sederhana dalam kebanyakan kes. Ia juga mengambil masa yang lebih lama untuk pulih selepas kemalangan. Tetapi ia akan menjadi lebih pantas dalam beberapa operasi pangkalan data. Dalam keadaan biasa, adalah disyorkan untuk menggunakan mod lalai. Jika anda perlu menukar mod, sila tambahkan pilihan data=mod pada sistem fail yang sepadan dalam fail /etc/fstab. Untuk butiran, sila rujuk manual dalam talian halaman manual arahan mount (laksanakan man mount).

Mudah berhijrah

Anda boleh berhijrah dari ext2 ke ext3 dengan mudah tanpa memformat semula cakera keras dan menikmati faedah sistem fail jurnal yang boleh dipercayai. Ya, anda boleh mengalami kelebihan ext3 tanpa melakukan operasi "backup-reformat-restore" yang panjang, membosankan dan berpotensi ralat. Terdapat dua kaedah hijrah:

Jika anda menaik taraf sistem anda, pemasang Red Hat Linux akan membantu dengan pemindahan. Apa yang anda perlu lakukan ialah klik butang Pilih untuk setiap sistem fail.

Gunakan program tune2fs untuk menambah fungsi pengelogan pada sistem fail ext2 sedia ada. Jika sistem fail telah dipasang semasa proses penukaran, fail ".journal" akan muncul dalam direktori akar jika sistem fail belum dipasang, fail tidak akan muncul dalam sistem fail. Untuk menukar sistem fail, hanya jalankan tune2fs -j /dev/hda1 (atau mana-mana nama peranti di mana sistem fail yang anda ingin tukar terletak), dan tukar ext2 dalam fail /etc/fstab kepada ext3. Jika anda ingin menukar sistem fail akar anda sendiri, anda mesti menggunakan initrd untuk boot. Jalankan program mengikut penerangan manual mkinitrd, dan sahkan bahawa initrd dimuatkan dalam konfigurasi LILO atau GRUB anda (jika tidak berjaya, sistem masih boleh dimulakan, tetapi sistem fail akar akan dimuatkan sebagai ext2 dan bukannya ext3. Anda boleh menggunakan arahan cat / proc/mounts untuk mengesahkan ini.) Untuk butiran, sila rujuk manual dalam talian halaman manual untuk arahan tune2fs (execute man tune2fs).

3, tiga mod log ext3

Ext3 menyediakan berbilang mod log, iaitu, sama ada menukar metadata sistem fail atau menukar data sistem fail (termasuk perubahan pada fail itu sendiri), sistem fail ext3 boleh menyokongnya apabila /. dll/fail fstab dibut Tiga mod log berbeza:

data=mod log jurnal

Rekod log termasuk semua data dan metadata yang mengubah sistem fail. Ia adalah yang paling perlahan daripada tiga mod penjurnalan ext3, tetapi ia meminimumkan kemungkinan ralat. Menggunakan mod "data=jurnal" memerlukan ext3 untuk menulis setiap perubahan pada sistem fail dua kali dan jurnal sekali, yang akan mengurangkan prestasi keseluruhan sistem fail. Semua data baharu ditulis pada log terlebih dahulu dan kemudian ditempatkan. Selepas kemalangan berlaku, log boleh dimainkan semula untuk mengembalikan data dan metadata kepada keadaan yang konsisten. Memandangkan metadata dan kemas kini data dalam ext3 direkodkan, log ini akan berkuat kuasa apabila sistem dimulakan semula.

data=mod log tertib (lalai)

Hanya metadata sistem fail yang diubah direkodkan, dan data fail limpahan mesti ditambahkan pada cakera. Ini ialah mod pengelogan ext3 lalai. Mod ini mengurangkan redundansi antara menulis ke sistem fail dan menulis ke log, jadi ia lebih pantas Walaupun perubahan dalam data fail tidak direkodkan dalam log, ia mesti dilakukan dan dikawal oleh program daemon ext3 perubahan metadata sistem fail yang berkaitan, iaitu, data sistem fail mesti diubah suai sebelum merekodkan metadata Ini akan mengurangkan sedikit prestasi (kelajuan) sistem, tetapi ia boleh memastikan data fail dalam sistem fail adalah konsisten dengan. sistem fail yang sepadan.

data=mod log tulis balik

Hanya merekodkan metadata perubahan pada sistem fail, tetapi mengikut sistem fail standard, program penulisan masih perlu merekodkan perubahan dalam data fail pada cakera untuk mengekalkan konsistensi sistem fail. Ini ialah mod penjurnalan ext3 terpantas. Kerana ia hanya merekodkan perubahan metadata tanpa menunggu kemas kini yang berkaitan dengan data fail seperti saiz fail, maklumat direktori, dll., kemas kini data fail dan rakaman perubahan metadata boleh menjadi tak segerak, iaitu ext3 menyokong log tak segerak. Kelemahannya ialah apabila sistem ditutup, data yang dikemas kini tidak konsisten kerana ia tidak boleh ditulis pada cakera Masalah ini tidak dapat diselesaikan dengan baik pada masa ini.

Terdapat perbezaan antara mod log yang berbeza, tetapi kaedah tetapan adalah sama dan mudah. Mod log boleh ditentukan menggunakan sistem fail ext3, yang dilakukan pada permulaan oleh /etc/fstab. Contohnya, jika anda memilih data=mod log tulis balik, anda boleh membuat tetapan berikut:

/dev/hda5 /opt ext3 data=writeback 1 0

Dalam keadaan biasa, mod log data=ordered log ialah mod lalai sistem fail ext3.

Untuk menentukan kaedah pengelogan, anda boleh menggunakan kaedah berikut:

1 Tambahkan rentetan yang sesuai pada medan pilihan /etc/fstab seperti data=journal

# /dev/sda3 /var ext3 lalai,data=writeback 1 2

2 Nyatakan terus pilihan baris arahan -o data=journal apabila memanggil mount.

# mount -o data=journal /dev/sdb1 /mnt

Jika kita ingin menyemak mod log sistem fail tertentu, bagaimana kita boleh menanyakannya melalui arahan dmesg:

# dmesg |. grep -B 1 "sistem fail terpasang"

kjournald bermula

EXT3-fs: sistem fail dipasang dengan mod data tertib.

EXT3 FS pada sda1, jurnal dalaman

EXT3-fs: sistem fail dipasang dengan mod data tertib.

EXT3 FS pada sdb1, jurnal dalaman

EXT3-fs: sistem fail dipasang dengan mod data jurnal.

EXT3 FS pada sdb1, jurnal dalaman

EXT3-fs: sistem fail dipasang dengan mod data tulis balik.

4. Pilih mod log

Kelajuan

Dalam beberapa kes biasa, menggunakan data pilihan=tulis balik boleh meningkatkan kelajuan dengan ketara, tetapi pada masa yang sama ia akan mengurangkan perlindungan ketekalan data. Dalam kes ini, perlindungan ketekalan data pada asasnya adalah sama seperti sistem fail ext2, kecuali semasa operasi biasa, sistem secara berterusan mengekalkan integriti sistem fail (ini ialah mod penjurnalan yang digunakan oleh sistem fail penjurnalan lain). Ini termasuk operasi penulisan yang dikongsi secara kerap, tetapi juga penciptaan dan pemadaman sejumlah besar fail kecil, seperti menghantar sejumlah besar mesej e-mel kecil. Jika anda bertukar daripada ext2 ke ext3 dan mendapati prestasi aplikasi menurun dengan ketara, pilihan data=writeback boleh membantu anda meningkatkan prestasi. Walaupun anda tidak mendapat langkah perlindungan ketekalan data yang mahal, anda masih boleh menikmati faedah ext3 (sistem fail sentiasa konsisten). Red Hat masih melakukan kerja untuk meningkatkan beberapa aspek prestasi ext3, jadi beberapa aspek prestasi ext3 boleh dipertingkatkan pada masa hadapan. Ini juga bermakna walaupun anda memilih data=writeback sekarang, anda perlu menguji semula versi masa hadapan dengan nilai lalai data=jurnal untuk menentukan sama ada perubahan dalam versi baharu berkaitan dengan kerja anda.

Integriti Data

Dalam kebanyakan kes, pengguna menulis data pada penghujung fail. Hanya dalam beberapa kes (seperti pangkalan data) pengguna menulis data di tengah-tengah fail sedia ada. Malah menimpa fail sedia ada dicapai dengan memotong fail dahulu dan kemudian menulis data dari hujung fail. Dalam mod data=tertib, jika sistem ranap semasa menulis fail, blok data mungkin ditimpa sebahagiannya, tetapi proses penulisan tidak selesai, jadi sistem mempunyai blok data yang tidak lengkap yang bukan milik mana-mana fail. Dalam mod data=tertib, satu-satunya keadaan di mana blok data tidak tersusun kekal selepas ranap sistem adalah jika program menulis semula fail semasa ranap sistem. Dalam kes ini, tiada jaminan mutlak bagi perintah tulis melainkan atur cara menggunakan fsync() dan O_SYNC untuk memaksa penulisan berlaku dalam susunan tertentu.

Sistem fail ext3 juga melibatkan cara mengepam data dalam cache ke cakera keras. Ia melaksanakan pembilasan biasa melalui proses kupdate Secara lalai, ia menyemak setiap 5 saat dan mengepam data kotor yang melebihi 30 saat ke cakera keras.

Dalam sebagai 3.0, tujuan boleh dicapai dengan mengubah suai /proc/sys/vm/bdflush. Dalam sebagai 4.0, tujuan boleh dicapai dengan mengubah suai /proc/sys/vm/dirty_writeback_centisecs dan /proc/sys/vm/dirty_expire_centisecs.

Memandangkan mod tertib lalai, dalam mod ini, jika IO menulis fail data dahulu dan kemudian menulis fail log. Jika sistem ranap selepas menulis fail data tetapi sebelum menulis fail log, bahagian data ini akan hilang sama sekali Ini tidak dibenarkan dalam pangkalan data, sama ada Oracle atau MySQL. Jadi Untuk penulisan pangkalan data, setiap operasi tulis akan ditulis terlebih dahulu ke pagecache, dan kemudian kernelthread akan dimaklumkan untuk membuang penimbal ke cakera keras, dan kemudian metadata akan ditulis ke log, dan akhirnya operasi tulis yang berjaya akan dikembalikan. Dengan cara ini, operasi menulis ke pangkalan data jelas tidak sepantas menulis ke peranti kosong.

Jadi apabila menggunakan Ext3 untuk menjalankan pangkalan data, tetapkan mod log ke mod jurnal, prestasi harus dipertingkatkan (belum diuji, analisis teori sepatutnya seperti ini). Kerana dalam mod jurnal, untuk operasi tulis dalam pangkalan data, perubahan data dan sistem fail mula-mula ditulis terus ke log (penulisan langsung memintas cache, yang mempunyai prestasi yang lebih baik), kemudian data ditulis ke cache, dan kemudian proses kupdate menyegarkan data ke cakera keras. Sebaliknya, untuk DB, prestasinya sepatutnya lebih pantas daripada yang sebelumnya.

Selain itu, berikut ialah parameter sync_binlog dalam MySQL. Jika parameter ini ditetapkan kepada 1, ini bermakna setiap kali fail binlog ditulis, ia akan dibuang ke cakera keras pada masa yang sama, sama seperti penulisan Oracle IO. Jika parameter ini dimatikan, ia akan diuruskan oleh OS, iaitu, ia akan diperiksa setiap 5 saat Jika data lama dari 30 saat yang lalu ditemui, ia akan dibuang ke cakera keras. Parameter innodb_flush_log_at_trx_commit juga melibatkan isu mengepam cakera keras.

Ext3, sebagai versi ext2 yang dipertingkatkan, hampir sama dengan superblock, inod, deskriptor kumpulan dan struktur data lain yang digunakan oleh ext2, jadi ext3 serasi ke hadapan dengan ext2. Tanpa membuat sandaran data sistem fail ext2, anda boleh menggunakan:

# tune2fs –j/dev/sd1

Tukar sistem fail ext2 terus kepada sistem fail ext3 tanpa menyahlekap partition.

Andaikan, apabila kita sedang mengedit fail, berlaku gangguan bekalan elektrik secara tiba-tiba, atau sistem dikunci dan terpaksa dimulakan semula, apakah akibatnya? Paling teruk, sebahagian daripada kandungan fail hilang, paling teruk, keseluruhan kandungan fail kucar-kacir, dan lebih teruk lagi, sistem fail ranap secara langsung. Perkara yang dahsyat ini akan berlaku. Apabila Linux dimatikan secara normal, kita akan melihat mesej cetakan menyahpasang sistem fail yang tidak normal akan membawa kepada ketidakkonsistenan dalam sistem fail Ketidakkonsistenan ini akan ditemui apabila sistem fail dipasang semasa fasa mulakan semula sistem cuba membaikinya. Malangnya, apabila kapasiti peranti storan meningkat, masa yang diperlukan untuk pembaikan sedemikian menjadi semakin lama.

Ciri terbesar Ext3 ialah ia menambah fungsi log berdasarkan ext2, jadi sistem fail ext3 sering dipanggil sistem fail log, tetapi sistem fail log bukan sahaja ext3, tetapi juga JFS, reiserFS dan XFS. Serta NTFS, dan lain-lain yang sering kita lihat pada Windows.

Ciri pengelogan Ext3 terutamanya bergantung pada peranti perantaraan yang dipanggil "Lapisan Peranti Blok Jurnal" di bawahnya, dipanggil JBD (lapisan Peranti Blok Jurnal, singkatannya JBD). JBD bukan sebahagian daripada spesifikasi sistem fail Ia tiada kaitan dengan spesifikasi sistem fail ext3 adalah asas untuk pelaksanaan fungsi pemprosesan transaksi sistem. Ringkasnya, JBD direka untuk melaksanakan tujuan khas log masuk pada mana-mana peranti blok (semakin abstrak ia menjadi, apakah itu transaksi? ⊙﹏⊙…)

Mengenai urus niaga, pelajar yang berpengalaman dalam pembangunan pangkalan data atau operasi dan penyelenggaraan data pasti akan mengenalinya. Kami tidak akan berpegang kepada konsep di sini, dan tidak akan berpegang kepada definisi akademik selagi semua orang tahu bahawa fungsi utama urus niaga adalah untuk memastikan keatoman operasi. Bagaimana untuk memahami ayat ini? Sebagai contoh, dalam sistem kewangan, X yuan perlu dipindahkan dari akaun A ke akaun B. Perniagaan ini mesti memastikan bahawa X yuan berjaya dipindahkan dari akaun A, dan kemudian X yuan berjaya ditambahkan ke akaun B. Hanya jika kedua-dua operasi ini berjaya pada masa yang sama boleh pemindahan berjaya Jika salah satu operasi gagal, perniagaan mesti ditamatkan. Jika pemindahan X yuan daripada akaun A berjaya dan ralat berlaku semasa menulis ke akaun B, maka X yuan yang dipindahkan daripada akaun A mesti dikembalikan ke akaun A. Keadaan yang lebih ekstrem ialah data akaun A runtuh kerana pelbagai sebab Kemudian mekanisme transaksi pangkalan data mesti memastikan bahawa yuan X akaun A tidak akan hilang. Ini adalah atomicity operasi perniagaan pangkalan data. Dalam sistem fail log, keatoman operasi data fail dijamin oleh JBD Ext3 melaksanakan fungsi pengelogannya dengan "memasukkan" API JBD. Walaupun lapisan JBD itu sendiri tidak mempunyai banyak kod, ia adalah bahagian perisian yang sangat kompleks Kami tidak akan membincangkannya di sini dan akan bermain dengannya apabila kami mempunyai peluang. Sistem fail log sudah tentu mesti merekodkan log, dan log juga memerlukan ruang storan. Oleh itu, sistem fail log membuka kawasan khas pada medium storan khusus untuk menyimpan maklumat log:

Menyelam mendalam ke dalam sistem fail jurnal ext3 dalam CentOS Kami menggunakan gambar untuk menerangkan secara ringkas reka letak asas ext3:

Atas ialah kandungan terperinci Menyelam mendalam ke dalam sistem fail jurnal ext3 dalam CentOS. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!