Bisakah sistem file menjadi tidak konsisten jika terganggu ketika memindahkan file?


13

Saya memiliki dua folder pada partisi yang sama (EXT2) Jika saya mv folder1/file folder2dan beberapa gangguan terjadi (misalnya, kegagalan daya) dapatkah sistem file menjadi tidak konsisten?

Bukankah mvatom operasi?

Pembaruan: Sejauh ini di IRC saya mendapatkan perspektif berikut:

  1. itu atomik sehingga inkonsistensi tidak bisa terjadi
  2. pertama Anda menyalin entri dir di dir baru dan kemudian menghapus entri pada dir sebelumnya, sehingga Anda mungkin memiliki inkonsistensi memiliki file yang direferensikan dua kali, tetapi jumlah ref adalah 1
  3. pertama-tama menghapus pointer dan kemudian menyalin pointer sehingga ketidakkonsistenan adalah bahwa file tersebut memiliki referensi 0

Bisakah seseorang mengklarifikasi?

Jawaban:


11

Pertama, mari kita singkirkan beberapa mitos.

itu atomik sehingga inkonsistensi tidak bisa terjadi

Memindahkan file di dalam filesystem yang sama (yaitu rename) system call adalah atom terhadap lingkungan perangkat lunak. Atomicity berarti bahwa setiap proses yang mencari file akan melihatnya di lokasi yang lama atau di lokasi yang baru; tidak ada proses yang dapat mengamati bahwa file memiliki jumlah tautan yang berbeda, atau bahwa file tersebut ada di direktori sumber setelah ada di direktori tujuan, atau bahwa file tersebut tidak ada di direktori target setelah tidak ada di sumber direktori.

Namun, jika sistem macet karena bug, kesalahan disk atau kehilangan daya, tidak ada jaminan bahwa sistem file dibiarkan dalam keadaan konsisten, apalagi bahwa langkah tersebut tidak dibiarkan setengah jadi. Linux secara umum tidak menawarkan jaminan atomicity sehubungan dengan peristiwa perangkat keras.

pertama Anda menyalin entri dir di dir baru dan kemudian menghapus entri pada dir sebelumnya, sehingga Anda mungkin memiliki inkonsistensi memiliki file yang direferensikan dua kali, tetapi jumlah ref adalah 1

Ini mengacu pada teknik implementasi spesifik. Ada yang lain.

Kebetulan ext2 di Linux (pada kernel 3.16) menggunakan teknik khusus ini. Namun, ini tidak menyiratkan bahwa konten disk melewati urutan [lokasi lama] → [kedua lokasi] → [lokasi baru], karena dua operasi (menambah entri baru, menghapus entri lama) tidak atom pada tingkat perangkat keras baik : ada kemungkinan salah satu dari mereka terganggu, meninggalkan sistem file dalam keadaan tidak konsisten. (Semoga fsck akan memperbaikinya.) Selanjutnya lapisan blok dapat menyusun ulang penulisan, sehingga babak pertama dapat dilakukan ke disk tepat sebelum crash dan babak kedua tidak akan dilakukan.

Jumlah referensi tidak akan pernah diamati berbeda dari 1 selama sistem tidak crash (lihat di atas) tetapi jaminan itu tidak meluas ke crash sistem.

pertama-tama menghapus pointer dan kemudian menyalin pointer sehingga ketidakkonsistenan adalah bahwa file tersebut memiliki referensi 0

Sekali lagi, ini mengacu pada teknik implementasi tertentu. File yang menggantung tidak dapat diamati jika sistem tidak macet, tetapi kemungkinan konsekuensi dari sistem macet, setidaknya dalam beberapa konfigurasi.


Menurut posting blog oleh Alexander Larsson , ext2 tidak memberikan jaminan konsistensi pada sistem crash, tetapi ext3 tidak dalam data=orderedmode. (Perhatikan bahwa posting blog ini bukan tentang renamedirinya sendiri, tetapi tentang kombinasi penulisan ke file dan memanggil renamefile itu.)

Theodore Ts'o, penulis utama sistem file ext2, ext3 dan ext4, menulis posting blog tentang masalah yang sama . Posting blog ini membahas atomicity (hanya berkenaan dengan lingkungan perangkat lunak) dan daya tahan (yang merupakan atomicity sehubungan dengan crash plus jaminan komitmen, yaitu mengetahui bahwa operasi telah dilakukan). Sayangnya saya tidak dapat menemukan informasi tentang atomicity sehubungan dengan crash saja. Namun, jaminan daya tahan yang diberikan untuk ext4 mengharuskannya renamebersifat atomik. Dokumentasi kernel untuk ext4 menyatakan bahwa ext4 dengan auto_da_allocopsi (yang merupakan default di kernel modern), serta ext4, memberikan jaminan daya tahan untuk writediikuti olehrename, Yang menyiratkan bahwa itu renameadalah atom sehubungan dengan crash perangkat keras.

Untuk Btrfs, sebuah renameyang menimpa file yang sudah ada dijamin akan atom sehubungan dengan crash, tapi sebuah renameyang tidak menimpa file dapat mengakibatkan tidak file atau kedua file yang ada.


Singkatnya, jawaban atas pertanyaan Anda adalah bahwa tidak hanya memindahkan file bukan atom sehubungan dengan crash pada ext2, tetapi bahkan tidak dijamin untuk meninggalkan file dalam keadaan konsisten (meskipun kegagalan yang fscktidak dapat memperbaiki jarang terjadi) - tidak ada apa-apa, itulah sebabnya sistem file yang lebih baik telah ditemukan. Ext3, ext4 dan btrf memang memberikan jaminan terbatas.


13

Operasi penggantian nama sangat cepat pada sistem file apa pun, sehingga tidak mungkin terganggu, tetapi pada sistem file klasik tentu saja dapat terganggu - jika ia menciptakan tautan tujuan terlebih dahulu, ia dapat meninggalkan dua tautan pada suatu file - yang legal, tetapi file tersebut berpikir hanya memiliki satu, yang dapat menyebabkan masalah jika dihapus kemudian. Di sisi lain, jika menghapus tautan sumber terlebih dahulu, file bisa hilang. Menjalankan fsck biasanya akan mendeteksi dan memperbaiki kondisi mana pun, meskipun jika file hilang, ia akan ditempatkan di direktori "lost + found" dengan nama arbitrer daripada di lokasi yang diinginkan - dan jika memiliki dua tautan, jumlah tautan akan dengan mudah diperbarui, sehingga file akan ada di dua lokasi jika sistem file mendukung ini.

Jika Anda membutuhkan sistem file yang tangguh dalam menghadapi kegagalan daya, Anda harus menggunakan sistem file penjurnalan , seperti NTFS, EXT3, atau XFS. Sebagian besar sistem modern akan menggunakan sistem file penjurnalan secara default, meskipun Anda harus menyadari bahwa FAT bukan sistem berkas penjurnalan jika Anda menggunakannya untuk drive eksternal.

Sistem file penjurnalan menggunakan sistem "entri ganda" - menulis ke file jurnal fakta bahwa ia bermaksud untuk memindahkannya, kemudian melakukan langkah tersebut. Ketika filesystem diperiksa pada saat startup, jika terganggu, ia akan melihat bahwa langkah itu tidak selesai dan mengulanginya kemudian.

Ada dua jenis sistem file penjurnalan - penjurnalan metadata dan penjurnalan penuh. Penjurnalan metadata berarti tidak melacak perubahan pada isi file dalam sistem jurnal (jadi, Anda bisa kehilangan konten jika Anda menulis ke file), tetapi itu tetap akan melacak informasi sistem file penting seperti isi direktori , properti file, dll.


Ketika orang-orang berbicara tentang operasi penggantian nama menjadi atom, mereka berarti bahwa operasi itu tidak dapat diamati pada pertengahan transisi oleh proses lain pada sistem, dan itu tidak dapat dibiarkan setengah selesai dengan misalnya mengganggu mvperintah itu sendiri ^C. Proses fisik penulisan ke setiap direktori, yang ruang penyimpanannya mungkin di lokasi yang sangat berbeda pada disk, tidak mungkin menjadi operasi atom pada tingkat perangkat keras.


Untuk kelengkapan, saya akan perhatikan bahwa ada juga beberapa operasi I / O yang tidak disengaja yang terkait dengan penggantian nama selain membuat tautan baru di direktori tujuan dan menghapusnya di yang lama - memutakhirkan mtime dari kedua direktori, mungkin memperluas ukuran alokasi direktori tujuan, mengubah ..tautan dan jumlah tautan dari direktori induk jika file tersebut adalah direktori. Juga, saya tidak yakin apakah atime file itu sendiri terpengaruh.


Jurnal tidak menjamin kegagalan daya atomisitas. Saya pikir ext3 dan ext4 memang menjamin itu renameatom, tetapi btrfs tidak sesuai dengan wiki (lihat jawaban saya). Mungkin juga untuk menjamin keaslian tanpa jurnal (saya tidak tahu contoh di Linux tetapi mungkin ada beberapa). Apakah Anda memiliki informasi tepercaya tentang ext2?
Gilles 'SANGAT berhenti menjadi jahat'

@Gilles, apakah Anda memiliki informasi tentang bagaimana hal itu dapat dijamin secara teoritis tanpa jurnal? Maksud saya, pada level dasar, kita berbicara tentang menyinkronkan penulisan ke dua file berbeda untuk menjamin bahwa Anda tidak pernah mendapatkan hasil bahwa hanya satu saja yang dilakukan.
Random832

Sistem file log-terstruktur menjaga konsistensi dengan tidak menimpa blok yang sedang digunakan. Ini sangat cocok untuk media flash di mana menimpa data yang ada mahal. Log tidak benar-benar seperti jurnal karena tidak ada yang diputar ulang saat pemasangan - meskipun Anda dapat mengatakan bahwa keseluruhan sistem file adalah jurnal (kecuali pemasangan yang tidak pernah melibatkan memutar ulang seluruh hal dalam memori karena akan terlalu lambat). Deskripsi LogFS di Wikipedia adalah gambaran umum yang bagus.
Gilles 'SANGAT berhenti menjadi jahat'

1

Pertanyaan ini ditanyakan dengan sedikit berbeda pada Super User. Halaman Wikipedia pada mvperintah juga menjelaskannya dengan cukup baik:

Memindahkan file dalam sistem file yang sama umumnya diimplementasikan secara berbeda dari menyalin file dan kemudian menghapus aslinya. Pada platform yang tidak mendukung rename syscall, tautan baru ditambahkan ke direktori baru dan yang asli dihapus. Data file tidak diakses.

Linux memiliki nama syscall dan karenanya akan mengubah nama file sebagai operasi atom, yaitu tidak terputus. Jadi tidak, sistem file tidak dapat menjadi tidak konsisten dalam situasi yang Anda jelaskan.


2
apakah rename sys itu disebut abstraksi os? Karena perangkat keras, saya selalu dapat mengganggu serangkaian operasi karena mengubah nama harus menjadi serangkaian operasi
graphtheory92

Tidak, ini bukan abstraksi OS, tapi saya pikir menyatakan "oleh karena itu sangat tidak mungkin sistem file akan menjadi tidak konsisten ..." akan membuat segalanya terlalu rumit. Saya setuju dengan Anda.
Benjamin B.

2
Daun jawaban ini saya bertanya-tanya mengapa para renamesystem call tidak dapat menghasilkan filesystem menjadi dalam keadaan tidak konsisten bahkan jika ada kegagalan daya. Saya merasa ini adalah inti dari pertanyaan @ graphtheory92.
Tanner Swett

1
@ graphtheory92: Jika panggilan sistem adalah atom, itu tidak berarti sama sekali bahwa operasi disk yang dihasilkan (atau serangkaian operasi disk!) akan menjadi atom juga. ------ Saya dapat membayangkan bahwa dengan memindahkan file (hard link count 1) dan memotong daya, koneksi hard disk atau menabrak kernel pada waktu yang tepat Anda dapat berakhir dengan dua hard link (yang asli dan yang baru ) ke file dengan jumlah hard link masih 1. ------ Saya pikir ada dua solusi dasar untuk masalah: a) perangkat lunak - penjurnalan FS yang secara otomatis dapat pulih dari keadaan tidak konsisten. b) transaksi yang didukung HW.
pabouk

2
Jaminan atomisitas yang Anda maksudkan adalah sehubungan dengan pengamatan oleh proses lain. Itu tidak berlaku jika sistem crash.
Gilles 'SO- stop being evil'
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.