Pada EXT2FS setiap berkas, direktori, dan berbagai data lainnya direpresentasikan dalam inode seperti pada gambar mengenai struktur inode EXT2FS.
Gambar 21.9. Struktur Directory Sistem Berkas EXT2FS
Directory dalam EXT2FS diimplementasikan sebagai suatu berkas yang berisi beberapa entry, setiap entry berisi inode number yang menunjuk ke tabel inode, record length, name length, file
type, dan entry name. Tipe berkas file type menyatakan jenis berkas tersebut, yaitu:
Tabel 21.1.
178
Tipe Berkas Keterangan
unknown 1
regular file 2
directory 3
character device 4
block device 5
named pipe 6
socket 7
symbolic link
Optimasi dan Performa EXT2FS
Pada EXT2FS beberapa optimasi dilakukan untuk mempercepat penulisan dan pembacaan data atau berkas. Pada operasi pembacaan, EXT2FS memanfaatkan suatu buffer. Ketika suatu block akan
dibaca oleh sistem, sistem akan meminta beberapa block pada sektor selanjutnya untuk dibaca juga dan dimasukkan ke dalam suatu buffer, sehingga jika selanjutnya sistem ingin membaca data pada
sektor selanjutnya dari block tersebut, data yang diinginkan telah ada di- buffer. Tentu ini akan menghemat waktu dalam transfer data, karena data pada buffer akan lebih cepat diakses
dibandingkan dengan data yang ada di disk, yang mungkin akan membutuhkan waktu tambahan untuk mencari sektor yang tepat.
Untuk pengalokasian data atau berkas juga dilakukan optimasi seperti penggunaan block group untuk mengelompokkan inode dan berkas yang berkaitan. Hal ini akan mengurangi waktu pencarian
disk head ketika sistem menginginkan pembacaan suatu inode beserta data yang bersesuaian dengan inode tersebut.
Optimasi lain yang dilakukan yaitu untuk penulisan berkas, ketika sistem ingin menulis data maka EXT2FS mengalokasikan 8 block berurutan. Pengalokasian ini dapat meningkatkan performa dalam
penulisan suatu berkas ketika berkas yang ditulis berukuran berkas. Selain itu, cara tersebut juga memungkinkan penulisan berkas dalam block yang terurut, sehingga meningkatkan kecepatan
pembacaan karena pembacaan dilakukan secara sekuensial.
Interaksi EXTFS dengan VFS
Gambar 21.10. Ilustrasi interaksi EXTFS dengan VFS
Kernel Linux berinteraksi dengan objek-objek yang terdapat di EXTFS melalui VFS. Setiap objek VFS terhubung dengan sistem berkas yang sesungguhnya, dalam hal ini EXTFS. Dalam
179
pengaksesan data yang terdapat dalam sistem berkas, kernel akan memanfaatkan keberadaan objek di VFS yang terdapat di memori utama. Jika objek belum ditemukan, maka VFS akan melihatnya ke
sistem berkas EXTFS, lalu disalin ke memori. Biasanya objek disimpan dalam chace yang diimplementasikan oleh VFS, seperti dchace untuk menyimpan dentry, sehingga proses pencarian
dapat dilakukan dengan lebih cepat. Lalu objek akan dihapus dari memori pada saat tertentu.
21.4. Jurnal
Gambar 21.11. Struktur Logical Jurnal
Transaksi adalah sekumpulan operasi yang melakukan tugas tertentu. Salah satu sifat dari transaksi adalah atomik, yang menyatakan bahwa suatu transaksi harus selesai dengan sempurna atau tidak
sama sekali. Pada saat tertentu, bisa saja ketika suatu transaksi sedang melakukan perubahan data yang terdapat dalam disk, tiba-tiba terjadi sistem crash. Hal ini tentu akan menyebabkan data yang
terdapat dalam disk menjadi tidak konsisten. Berikut akan ditunjukkan bagaimana data dalam suatu sistem berkas menjadi tidak konsisten.
Contoh 21.1. Pembuatan Berkas Baru
Suatu transaksi yang membuat sebuah berkas, dan melalui langkah-langkah berikut: 1. Mengurangi jumlah inode yang dapat digunakan free inode,
2. Menginisialisasi inode pada disk, 3. Menambah entri pada parent direktori dimana berkas baru tersebut dibuat.
Jika pada langkah pertama sistem crash, maka sistem berkas menjadi tidak konsisten, karena jumlah inode yang dapat digunakan free inode telah berkurang, tetapi data yang sebenarnya belum ditulis
ke disk. Salah satu cara untuk mendeteksi masalah ini adalah dengan mengecek seluruh isi dari sistem berkas dengan menggunakan perintah
fsck file system consistency check. Proses
pengecekan tersebut tentu akan memakan waktu yang sangat lama, jika data yang terdapat pada sistem berkas tersebut sangat banyak. Kemudian, muncul suatu ide untuk menggunakan jurnal
sebagai media pencatat semua perubahan yang terjadi di dalam disk. Dengan menggunakan jurnal, konsistensi data tetap terjaga, tanpa perlu pengecekan pada keseluruhan data yang terdapat dalam
suatu sistem berkas, sehingga sistem dapat dipulihkan dalam waktu yang lebih cepat.
Sistem berkas berjurnal atau journaling filesystem menggunakan jurnal hanya sebagai tempat untuk mencatat semua informasi mengenai transaksi yang dilakukan, sedangkan disk digunakan untuk
menyimpan data yang sebenarnya. Jurnal dapat saja berada pada disk yang sama dengan disk yang digunakan untuk penyimpanan data, ataupun berada pada disk yang berbeda. Beberapa sistem
berkas dapat memiliki jurnalnya sendiri, tetapi dimungkinkan juga penggunaan satu jurnal bersama sharing journal untuk beberapa sistem berkas.
180
Journaling Block Device
Linux Journaling Block Device JBD menggunakan suatu catatan log untuk mencatat semua operasi yang mengubah konsistensi data seperti update, write, dan sebagainya dalam disk.
Implementasi struktur data dari jurnal berbentuk seperti circular linked list, jadi jurnal dapat menggunakan ruang tersebut berulang-ulang jika jurnal telah penuh.
Penulisan tiap atomic update ke jurnal akan menyebabkan ketidakefisienan. Untuk menghasilkan performa yang lebih baik, JBD menyatukan sekumpulan atomic update tersebut ke dalam satu
transaksi dan menulisnya ke dalam jurnal. JBD memastikan setiap transaksi adalah transaksi yang atomik. Ketika suatu transaksi diproses oleh sistem, transaksi tersebut akan melalui lima state.
Gambar 21.12. Transaction State
Keterangan: 1. Running. Transaksi sedang berjalan di sistem dan dapat menerima operasi atomic update lain.
Hanya ada satu transaksi yang dapat berstatus running dalam sistem.
2. Locked. Transaksi tidak lagi menerima operasi atomic update, dan belum semua atomic update
selesai dilakukan.
3. Flush. Semua atomic update yang terdapat dalam suatu transaksi telah selesai, sehingga
transaksi dapat ditulis ke jurnal.
4. Commit. Sistem akan menulis commit record yang menandakan penulisan ke jurnal telah
selesai.
5. Finished. Transaksi dan commit record telah selesai ditulis ke jurnal.
Contoh 21.2. Transaction state
Jika ada suatu transaksi seperti tabel berikut ini:
Tabel 21.2.
No. Atomic Update
1 Write A = 2
2 Write A = 3
3 Write A = 4
4 Write A = 5
181