Mengapa tabel inode biasanya tidak resizable?

Sistem file Unix biasanya memiliki tabel inode, dan jumlah entri dalam tabel ini biasanya diperbaiki pada saat sistem file dibuat. Ini kadang-kadang menyebabkan orang-orang dengan banyak ruang disk mendapatkan pesan kesalahan yang membingungkan tentang tidak ada ruang kosong, dan bahkan setelah mereka mengetahui apa masalahnya, tidak ada solusi mudah untuk apa yang harus dilakukan.

Tetapi tampaknya (bagi saya) bahwa akan sangat diinginkan untuk menghindari seluruh kekacauan ini dengan mengalokasikan inode on demand, sepenuhnya transparan kepada pengguna dan administrator sistem. Jika Anda suka peretasan yang lucu, Anda bahkan bisa membuat tabel inode itu sendiri menjadi file, dan dengan demikian menggunakan kembali kode yang sudah Anda miliki yang menemukan ruang kosong pada disk. Jika Anda beruntung, Anda mungkin berakhir dengan inode di dekat file itu sendiri, tanpa secara eksplisit mencoba mencapai hasil ini.

Tapi tak seorang pun (yang saya tahu) benar-benar melakukan ini, jadi mungkin ada tangkapan yang saya lewatkan. Adakah yang tahu apa itu?

Katakanlah Anda memang membuat tabel inode menjadi file; maka pertanyaan selanjutnya adalah ... di mana Anda menyimpan informasi tentang file itu? Dengan demikian Anda membutuhkan inode "asli" dan inode "extended", seperti tabel partisi MS-DOS. Mengingat, Anda hanya perlu satu (atau mungkin beberapa - misalnya, agar jurnal Anda menjadi file). Tetapi Anda sebenarnya memiliki kasing khusus, kode berbeda. Setiap kerusakan pada file itu akan menjadi bencana juga. Dan pertimbangkan bahwa, sebelum penjurnalan, adalah umum untuk file yang sedang ditulis misalnya, ketika listrik padam menjadi sangat rusak. Operasi file Anda harus jauh lebih kuat vs kegagalan daya / crash / dll. daripada mereka, misalnya, ext2.

Filesystem Unix tradisional menemukan solusi yang lebih sederhana (dan lebih kuat): letakkan blok inode (atau kelompok blok) setiap blok X. Kemudian Anda menemukannya dengan aritmatika sederhana. Tentu saja, maka tidak mungkin untuk menambahkan lebih banyak (tanpa merestrukturisasi seluruh sistem file). Dan bahkan jika Anda kehilangan / merusak blok inode yang Anda tulis ketika daya gagal, itu hanya kehilangan beberapa inode - jauh lebih baik daripada sebagian besar dari sistem file.

Lebih banyak desain modern menggunakan hal-hal seperti varian B-tree . Sistem file modern seperti btrfs, XFS, dan ZFS tidak mengalami batasan inode.

Banyak filesystem memiliki tabel inode yang dapat dialokasikan secara dinamis (atau setara dengan moralnya) (XFS, BTRFS, ZFS, VxFS ...)

Meskipun Unix UFS asli memiliki inode yang diperbaiki pada waktu pembuatan filesystem dan filesystem yang berasal darinya (Linux EXT, Solaris UFS) sering melanjutkan skema. Ini kuat dan sederhana untuk diterapkan. Begitu banyak kasus penggunaan yang cocok, yang merancang sistem file baru hanya untuk menghindari satu masalah tidak mudah dibenarkan.

Ada filesystem yang mengalokasikan inode secara dinamis: dari atas kepala saya, setidaknya Veritas VxFS (= sistem file default HP-UX, dan salah satu pilihan yang tersedia di Solaris) dan XFS (tipe sistem file standar pada RHEL 7) berfungsi seperti itu. Btrfs dan IBM's JFS juga.