Kepatuhan POSIX

Berikut adalah pengecualian terhadap kepatuhan POSIX Managed Lustre Google Cloud:

  • Pembaruan atime: Secara default, atime diaktifkan di Lustre, tetapi karena alasan performa, pembaruannya mungkin ditangguhkan. Artinya, waktu akses file mungkin tidak langsung diperbarui setelah setiap operasi baca.

  • flock/lockf: Ini mengacu pada dua API penguncian file utama: flock(2) dan fcntl(2).

    • flock: Ini adalah kunci saran seluruh file bergaya BSD yang tidak ditentukan oleh POSIX. Lustre sepenuhnya mendukung semantik flock bergaya BSD di seluruh cluster secara default.
    • fcntl: Ini adalah API penguncian yang ditentukan POSIX, yang mendukung kunci rentang byte. Implementasi kunci fcntl Lustre hampir sesuai dengan POSIX dan berfungsi seperti yang diharapkan untuk sebagian besar aplikasi. Namun, karena fcntl awalnya dirancang untuk sistem file lokal, tidak ada sistem file terdistribusi yang dapat 100% memenuhi semua persyaratan fcntl POSIX, termasuk Lustre. Misalnya, fcntl() menentukan bahwa kunci harus segera dilepas saat proses kepemilikan keluar, tetapi pelepasan kunci Lustre mungkin tertunda jika klien mengalami error.

Lihat FAQ Lustre untuk mengetahui detailnya.

Perubahan nomor inode karena migrasi metadata

Nomor inode file dalam sistem file Lustre bukanlah ID yang tidak dapat diubah.

Operasi penyeimbangan ulang metadata, seperti yang dimulai oleh lfs migrate, melibatkan migrasi metadata beberapa file dari satu MDT ke MDT lainnya. Sebagai konsekuensi langsung dari migrasi ke MDT baru ini, file tersebut akan diberi nomor inode baru.

Meskipun perilaku ini sesuai dengan standar POSIX, perilaku ini dapat melanggar asumsi banyak aplikasi dan layanan Unix/Linux umum yang dibuat untuk mengharapkan nomor inode persisten selama masa aktif file. Hal ini mencakup, tetapi tidak terbatas pada:

  • Frontend NFS dan SMB: Layanan ini sering kali mendapatkan handle file dari nomor inode. Perubahan dapat menyebabkan error Stale file handle untuk klien.

  • Utilitas pengarsipan dan pencadangan: Alat seperti tar yang melacak file berdasarkan perangkat + nomor inode-nya dapat memperlakukan file yang dimigrasikan sebagai file baru, sehingga menyebabkan pencadangan inkremental yang tidak efisien.

  • Agregator log, sistem deteksi penyusupan, dan aplikasi kustom yang menggunakan stat() dan menyimpan st_ino juga dapat terpengaruh.

Administrator harus mengetahui perilaku ini dan potensi dampaknya terhadap aplikasi sebelum memulai penyeimbangan ulang metadata manual.

Strategi mitigasi

Penyeimbangan ulang metadata harus diperlakukan sebagai peristiwa pemeliharaan terencana yang mengganggu.

  1. Jadwalkan masa pemeliharaan. Komunikasikan pemadaman terencana kepada semua pengguna dan pemilik aplikasi. Jika memungkinkan, jangan lakukan operasi lfs migrate skala besar pada sistem produksi aktif.

  2. Jika diperlukan, unmount dan pasang kembali sistem file setelah migrasi.

  3. Beberapa aplikasi mungkin perlu di-flush atau dimulai ulang setelah migrasi.