Kepatuhan POSIX

Berikut adalah pengecualian terhadap kepatuhan POSIX Managed Lustre di Google Cloud:

  • Update atime: Secara default, atime diaktifkan di Lustre, tetapi untuk alasan performa, update-nya mungkin ditunda. Artinya, waktu akses file mungkin tidak langsung diperbarui setelah setiap operasi baca.

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

    • flock: Ini adalah kunci saran seluruh file gaya BSD yang tidak ditentukan oleh POSIX. Lustre sepenuhnya mendukung semantik flock gaya BSD di seluruh cluster secara default.
    • fcntl: Ini adalah API penguncian yang ditentukan POSIX, yang mendukung penguncian rentang byte. Penerapan kunci fcntl di Lustre hampir kompatibel dengan POSIX dan berfungsi seperti yang diharapkan untuk sebagian besar aplikasi. Namun, karena fcntl awalnya didesain 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 dilepaskan segera saat proses pemilik keluar, tetapi pelepasan kunci Lustre dapat tertunda jika klien mengalami error.

Lihat FAQ Lustre untuk mengetahui detailnya.

Nomor inode berubah 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 ini ke MDT baru, file tersebut 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 yang 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 Stale file handle error bagi 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.

  • Pengumpul 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 pada aplikasi sebelum memulai penyeimbangan ulang metadata manual.

Strategi mitigasi

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

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

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

  3. Beberapa aplikasi mungkin perlu dibersihkan atau dimulai ulang setelah migrasi.