ระบบไฟล์จะไม่สอดคล้องกันหากถูกขัดจังหวะเมื่อย้ายไฟล์หรือไม่?

ฉันมีสองโฟลเดอร์ในพาร์ติชันเดียวกัน (EXT2) ถ้าฉันmv folder1/file folder2และการขัดจังหวะบางอย่างเกิดขึ้น (เช่นความล้มเหลวของระบบ) ระบบไฟล์อาจจบลงด้วยการไม่สอดคล้องกันหรือไม่?

mvอะตอมทำงานไม่ใช่หรือ

ปรับปรุง: จนถึง IRC ฉันได้มุมมองต่อไปนี้:

1. มันเป็นอะตอมดังนั้นความไม่สอดคล้องจึงไม่สามารถเกิดขึ้นได้
2. ก่อนอื่นให้คุณคัดลอกรายการ dir ใน dir ใหม่จากนั้นลบรายการใน dir ก่อนหน้าดังนั้นคุณอาจมีความไม่สอดคล้องกันของการอ้างอิงไฟล์สองครั้ง แต่จำนวนอ้างอิงคือ 1
3. มันจะลบตัวชี้ก่อนแล้วจึงคัดลอกตัวชี้ดังนั้นความไม่สอดคล้องกันคือไฟล์นั้นมีการอ้างอิง 0

บางคนสามารถอธิบายได้หรือไม่

ก่อนอื่นมาปัดเป่าตำนานบางอย่าง

มันเป็นอะตอมดังนั้นความไม่สอดคล้องจึงไม่สามารถเกิดขึ้นได้

การย้ายไฟล์ภายในระบบไฟล์เดียวกัน (เช่นการrenameเรียกใช้ระบบ) นั้นเป็นแบบอะตอมมิกตามสภาพแวดล้อมของซอฟต์แวร์ Atomicity หมายความว่ากระบวนการใด ๆ ที่ค้นหาไฟล์จะเห็นที่ตำแหน่งเดิมหรือที่ตำแหน่งใหม่ ไม่มีกระบวนการใดที่จะสามารถสังเกตได้ว่าไฟล์นั้นมีจำนวนลิงค์ต่างกันหรือไฟล์นั้นมีอยู่ในไดเรกทอรีต้นทางหลังจากที่มีอยู่ในไดเรกทอรีปลายทางหรือไฟล์นั้นหายไปจากไดเรกทอรีเป้าหมายหลังจากขาดในแหล่งข้อมูล ไดเรกทอรี

อย่างไรก็ตามหากระบบล่มเนื่องจากข้อผิดพลาดข้อผิดพลาดของดิสก์หรือการสูญเสียพลังงานไม่มีการรับประกันว่าระบบไฟล์จะอยู่ในสถานะที่สอดคล้องกันนับประสาว่าการย้ายไม่เหลือครึ่งเสร็จ ลีนุกซ์ไม่ได้เสนอการรับประกันอะตอมมิกเกี่ยวกับเหตุการณ์ฮาร์ดแวร์

ก่อนอื่นให้คุณคัดลอกรายการ dir ใน dir ใหม่จากนั้นลบรายการใน dir ก่อนหน้าดังนั้นคุณอาจมีความไม่สอดคล้องกันของการอ้างอิงไฟล์สองครั้ง แต่จำนวนอ้างอิงคือ 1

นี่หมายถึงเทคนิคการใช้งานที่เฉพาะเจาะจง มีคนอื่น ๆ

มันเกิดขึ้นที่ext2 บน Linux (ณ เคอร์เนล 3.16) ใช้เทคนิคนี้โดยเฉพาะ อย่างไรก็ตามสิ่งนี้ไม่ได้หมายความว่าเนื้อหาของดิสก์จะผ่านไปตามลำดับ [ตำแหน่งเก่า] → [ทั้งสองตำแหน่ง] → [ตำแหน่งใหม่] เนื่องจากการดำเนินการสองรายการ (เพิ่มรายการใหม่ลบรายการเก่า) ไม่ใช่ระดับอะตอมที่ระดับฮาร์ดแวร์ : เป็นไปได้ที่หนึ่งในนั้นจะถูกขัดจังหวะโดยปล่อยให้ระบบไฟล์อยู่ในสถานะไม่สอดคล้องกัน (หวังว่า fsck จะซ่อมมัน) นอกจากนี้เลเยอร์บล็อกสามารถเรียงลำดับการเขียนใหม่ได้ดังนั้นครึ่งแรกสามารถส่งไปยังดิสก์ก่อนเกิดความผิดพลาดและครึ่งหลังจะไม่ถูกดำเนินการ

จำนวนการอ้างอิงจะไม่ถูกสังเกตว่าแตกต่างจาก 1 ตราบใดที่ระบบไม่ผิดพลาด (ดูด้านบน) แต่การรับประกันนั้นจะไม่ขยายไปสู่ความผิดพลาดของระบบ

มันจะลบตัวชี้ก่อนแล้วจึงคัดลอกตัวชี้ดังนั้นความไม่สอดคล้องกันคือไฟล์นั้นมีการอ้างอิง 0

อีกครั้งนี้หมายถึงเทคนิคการใช้งานเฉพาะ ไฟล์ dangling ไม่สามารถตรวจสอบได้หากระบบไม่พัง แต่เป็นไปได้ว่าอาจเกิดความผิดพลาดของระบบอย่างน้อยก็ในการกำหนดค่าบางอย่าง

จากการโพสต์บล็อกของ Alexander Larsson ext2 ไม่รับประกันความสอดคล้องในการล่มของระบบ แต่ ext3 ทำในdata=orderedโหมด (โปรดทราบว่าการโพสต์บล็อกนี้ไม่ได้เกี่ยวกับrenameตัวเอง แต่เกี่ยวกับการรวมกันของการเขียนไปยังไฟล์และการเรียกrenameไฟล์นั้น)

ทีโอดอร์ทสโิผู้เขียนหลักของ ext2, ext3 และ ext4 filesystems เขียนบล็อกโพสต์เกี่ยวกับปัญหาเดียวกัน โพสต์บล็อกนี้กล่าวถึงatomicity (เกี่ยวกับสภาพแวดล้อมของซอฟต์แวร์เท่านั้น) และความทนทาน (ซึ่งเป็น atomicity เมื่อเทียบกับข้อขัดข้องพร้อมรับประกันการผูกมัดคือรู้ว่ามีการดำเนินการแล้ว) น่าเสียดายที่ฉันไม่สามารถหาข้อมูลเกี่ยวกับอะตอมมิกเกี่ยวกับการล่มได้เพียงอย่างเดียว อย่างไรก็ตามการรับประกันความทนทานที่กำหนดสำหรับความต้องการ ext4 นั้นrenameก็คืออะตอม เอกสารเกี่ยวกับเคอร์เนลสำหรับ ext4ระบุว่า ext4 พร้อมauto_da_allocตัวเลือก (ซึ่งเป็นค่าเริ่มต้นในเมล็ดที่ทันสมัย) เช่นเดียวกับ ext4 ให้การรับประกันความทนทานสำหรับwriteตามด้วยrenameซึ่งหมายถึงว่าrenameเป็นอะตอมที่เกี่ยวกับฮาร์ดแวร์ล่ม

สำหรับ Btrfs การrenameเขียนทับไฟล์ที่มีอยู่จะรับประกันว่าเป็นปรมาณูเกี่ยวกับการขัดข้อง แต่ไฟล์renameที่ไม่เขียนทับไฟล์อาจส่งผลให้ไม่มีไฟล์หรือไฟล์ทั้งสองที่มีอยู่

โดยสรุปคำตอบสำหรับคำถามของคุณคือไม่เพียง แต่จะย้ายไฟล์ที่ไม่ใช่อะตอมมิกเกี่ยวกับการล่มใน ext2 แต่ไม่รับประกันว่าจะทำให้ไฟล์อยู่ในสถานะที่สอดคล้องกัน (แม้ว่าความล้มเหลวที่fsckไม่สามารถซ่อมแซมได้จะหายาก) - ไม่มีอะไรที่จะเป็นไปได้ซึ่งเป็นเหตุผลว่าทำไมระบบไฟล์ที่ดีขึ้นจึงถูกคิดค้นขึ้น Ext3, ext4 และ btrfs มีการรับประกันแบบ จำกัด

การดำเนินการเปลี่ยนชื่อนั้นรวดเร็วมากในระบบไฟล์ใด ๆ ดังนั้นจึงไม่น่าจะถูกขัดจังหวะ แต่ในระบบไฟล์แบบคลาสสิกมันสามารถถูกขัดจังหวะได้อย่างแน่นอน- ถ้ามันสร้างลิงค์ปลายทางก่อนมันอาจทิ้งสองลิงก์ไว้ในไฟล์ - ซึ่งถูกกฎหมาย แต่ไฟล์คิดว่ามันมีเพียงไฟล์เดียวซึ่งอาจทำให้เกิดปัญหาหากไฟล์ถูกลบในภายหลัง ในทางกลับกันถ้ามันลบลิงค์แหล่งที่มาก่อนไฟล์อาจจะหายไป การเรียกใช้ fsck มักจะตรวจจับและแก้ไขเงื่อนไขอย่างใดอย่างหนึ่งแม้ว่าไฟล์จะหายไปมันจะถูกวางไว้ในไดเรกทอรี "lost + found" ที่มีชื่อตามอำเภอใจมากกว่าในตำแหน่งที่ต้องการ - และถ้ามีสองลิงก์การนับลิงก์จะง่าย ได้รับการอัปเดตดังนั้นไฟล์จะมีอยู่ในสองตำแหน่งหากระบบไฟล์รองรับสิ่งนี้

หากคุณต้องการให้ระบบไฟล์มีความแข็งแกร่งเมื่อเผชิญกับความล้มเหลวของพลังงานคุณควรใช้ระบบไฟล์ที่ทำเจอร์นัลเช่น NTFS, EXT3 หรือ XFS ระบบที่ทันสมัยส่วนใหญ่จะใช้ระบบไฟล์ journaling เป็นค่าเริ่มต้นถึงแม้ว่าคุณควรทราบว่า FAT ไม่ใช่ระบบไฟล์ journaling หากคุณใช้มันสำหรับไดรฟ์ภายนอก

ระบบไฟล์ที่เจอร์นัลใช้ระบบ "รายการคู่" - มันเขียนลงในไฟล์เจอร์นัลว่ามีความตั้งใจที่จะย้ายมันจากนั้นทำการย้าย เมื่อระบบไฟล์ถูกตรวจสอบเมื่อเริ่มต้นถ้ามันถูกขัดจังหวะมันจะสังเกตเห็นว่าการย้ายไม่เสร็จสมบูรณ์และทำซ้ำมันแล้ว

การทำเจอร์นัลระบบไฟล์มีสองประเภทคือ - การทำเจอร์นัลเมทาดาทาและการทำเจอร์นัลแบบเต็ม การทำเจอร์นัลข้อมูลเมตาหมายถึงไม่ติดตามการเปลี่ยนแปลงเนื้อหาไฟล์ในระบบเจอร์นัล (ดังนั้นคุณอาจสูญเสียเนื้อหาหากคุณกำลังเขียนไฟล์) แต่มันจะยังคงติดตามข้อมูลระบบไฟล์ที่สำคัญเช่นเนื้อหาไดเรกทอรี คุณสมบัติไฟล์ ฯลฯ

เมื่อคนพูดเกี่ยวกับการดำเนินการเปลี่ยนชื่อเป็นอะตอมพวกเขาหมายถึงว่ามันไม่สามารถสังเกตเห็นกลางการเปลี่ยนแปลงโดยกระบวนการอื่นในระบบและจะไม่สามารถซ้ายครึ่งแล้วเสร็จภายในเช่นขัดจังหวะคำสั่งตัวเองด้วยmv ^Cกระบวนการทางกายภาพของการเขียนไปยังแต่ละไดเรกทอรีซึ่งพื้นที่เก็บข้อมูลอาจอยู่ในตำแหน่งที่ตั้งที่แตกต่างกันอย่างมากบนดิสก์ไม่สามารถเป็นการดำเนินการแบบอะตอมมิกอย่างแท้จริงที่ระดับฮาร์ดแวร์

เพื่อความสมบูรณ์ฉันจะทราบว่ายังมีการดำเนินการ I / O ที่เกี่ยวข้องเล็กน้อยที่เกี่ยวข้องกับการเปลี่ยนชื่อนอกเหนือจากการสร้างลิงก์ใหม่ในไดเรกทอรีปลายทางและลบออกในอันเก่า - อัปเดต mtime ของทั้งสองไดเรกทอรีอาจขยาย ขนาดการจัดสรรของไดเรกทอรีปลายทางการเปลี่ยนแปลงการ..เชื่อมโยงและจำนวนลิงค์ของไดเรกทอรีหลักถ้าไฟล์เป็นไดเรกทอรี นอกจากนี้ฉันไม่แน่ใจว่าไฟล์ตัวเองได้รับผลกระทบหรือไม่

คำถามนี้ถูกถามในลักษณะที่แตกต่างกันเล็กน้อยเกี่ยวกับ Super User หน้า Wikipedia ในmvคำสั่งยังอธิบายได้ค่อนข้างดี:

โดยทั่วไปแล้วการย้ายไฟล์ภายในระบบไฟล์เดียวกันนั้นต่างจากการคัดลอกไฟล์แล้วจึงลบไฟล์ต้นฉบับ บนแพลตฟอร์มที่ไม่รองรับการเปลี่ยนชื่อ syscall ลิงค์ใหม่จะถูกเพิ่มไปยังไดเรกทอรีใหม่และลบต้นฉบับ ข้อมูลของไฟล์ไม่สามารถเข้าถึงได้

Linux มีการเปลี่ยนชื่อ syscallและจะเปลี่ยนชื่อไฟล์เป็นอะตอมมินนั่นคือไม่สามารถแตกได้การดำเนินการ ดังนั้นไม่ระบบไฟล์จะไม่สอดคล้องในสถานการณ์ที่คุณอธิบาย