Operasi metadata filesystem apa yang sebenarnya dijurnal di ext4 & xfs?

9

Saya tidak dapat menemukan jawaban sederhana dan langsung tentang operasi metadata filesystem mana yang benar-benar bertahan pada jurnal filesystem ext4 & xfs. Perhatikan bahwa saya tidak menanyakan tentang apa yang POSIX nyatakan sebagai "atomik". Saya lebih khawatir tentang apa bagian dari operasi sistem file atom yang secara efektif tahan lama berdasarkan berjalan dengan jurnal diaktifkan tanpa harus membungkuk ke belakang dan fsync(2)sepanjang waktu.

Operasi Saya menghitung cukup pasti:

creat(2)
link(2)
unlink(2)
rename(2)
mkdir(2)
rmdir(2)

Operasi Saya tidak sepenuhnya yakin tentang:

symlink(2)

The symlink(2)kasus yang paling meresahkan, karena ada tampaknya tidak akan ada cara mudah untuk fsync(2)atau fdatasync(2)yang datablocks mendasari yang menyimpan isi dari sebuah symlink. Mengetahui bahwa jurnal mengurus ini untuk saya akan melegakan.

— rboyer
sumber

1

Untuk alasan kinerja, ext4 secara default hanya menulis metadata sistem file melalui jurnal.

Saya percaya XFS juga mencatat semua transaksi metadata, kecuali Anda telah men-tweak sistem file.

— John Westlund
sumber

Ya tapi apa itu "metadata" secara khusus? Blok direktori: pasti. Inode sendiri: ya. Symlink dengan target yang cukup kecil untuk masuk ke inode itu sendiri: mungkin? Simbol di mana target tumpah ke blok bantu: ??????

tautan akan membantu

— asdmin

1

Saya lebih khawatir tentang apa bagian dari operasi sistem file atom yang secara efektif tahan lama berdasarkan berjalan dengan jurnal diaktifkan tanpa harus membungkuk ke belakang dan fsync (2) sepanjang waktu.

Tidak ada Jika Anda ingin memastikan bahwa perubahan tetap ada setelah crash, Anda harus fsync, titik. Penjurnalan hanya menjamin bahwa jika terjadi kerusakan, tidak satu pun dari operasi yang Anda daftarkan akan setengah selesai.

— psusi
sumber

Saya tahu bahwa jika saya peduli, saya harus mencari file dan direktori fsync untuk mengetahui secara pasti apakah blok-bloknya telah mencapai pemintalan karat, tetapi tidak ada metode yang dapat saya temukan yang memungkinkan saya menemukan blok-blok yang mendukung symlink jika tumpah dari inode. Pada saat itu satu-satunya jalan saya adalah mengandalkan jurnal atau tidak pernah menggunakan symlink lagi untuk apa pun yang penting.

— rboyer

@naelyn, fsync () akan mem-flush semua blok yang terkait dengan file, termasuk symlink yang tidak cepat.

— psusi

1

bagaimana cara membuka deskriptor file yang sesuai untuk digunakan dalam fsync yang akan mem-flush blok symlink yang tidak cepat?

— rboyer

@naelyn, oh ya ... bagus ... mungkin perlu bertanya tentang yang di milis linux-fsdevel ... dengan tautan keras Saya yakin Anda membuka dan menyinkronkan direktori yang berisi itu, mungkin symlinks bekerja sama?

— psusi

0

Anda tahu bahwa jurnal ext4 beroperasi dengan nomor blok dan bukan operasi, benar? "Metadata" akan menjadi apa pun selain blok data aktual untuk inode yang diberikan, terlepas dari operasi apa yang Anda gunakan untuk memodifikasi blok yang dimaksud.

— Bratchley
sumber

0

xfstests tampaknya mengklaim bahwa fsync () pada direktori harus tetap menggunakan symlink yang ada di dalamnya.

Saya belum memverifikasi ini. Mungkin saja saya melewatkan sesuatu.

xfstests digunakan oleh banyak pengembang sistem file Linux. Tes ini ada di direktori "generik". Ini berarti harus berlaku untuk semua sistem file Linux. (Atau setidaknya, semua sistem file blok perangkat. Tes ini bekerja dengan menggunakan perangkat blok virtual khusus).

https://github.com/kdave/xfstests/blob/master/tests/generic/348

# Test creating a symlink, fsync its parent directory, power fail and mount
# again the filesystem. After these steps the symlink should exist and its
# content must match what we specified when we created it (must not be empty
# or point to something else).

— sourcejedi
sumber