วิธีที่ง่ายที่สุด
btrfs-zero-log /dev/sda5
คุณได้รับปัญหานั้นเพราะธุรกรรม (เขียนหรือลบ) ติดอยู่ในบันทึกประจำวันและดิสก์ไม่ตรงกับมัน
มันทำงานอย่างไร:
ดังนั้นเมื่อข้อมูลถูกเขียนครั้งที่ 1 มันจะถูกเขียนไปยังเจอร์นัลแล้วจึงไปที่ดิสก์ (หรือในเวลาเดียวกัน แต่วารสารจะบันทึกข้อมูลเมตาเกี่ยวกับการเขียนที่กำลังจะมาถึง - ไม่แน่ใจว่า ... ต้องการการวิจัยเพิ่มเติมในส่วนนั้น) ...
ทั้งนี้หากคุณปิดระบบในช่วงกลางของการเขียนนี้ / ลบหรือทำอะไรบางอย่าง hickups ระบบ (ลงจากหลังม้า USB ที่ถือ btrfs ของคุณจุดติดตั้ง) จากนั้นเมื่อผลตอบแทนว่าติดจะไม่ทำงานมันจะล้มเหลว ( dmesgและbtrfsckประสงค์ แสดงข้อผิดพลาดในรายละเอียดเพิ่มเติม) ...
มองไปที่ dmesg คุณจะเห็นข้อความ transid ที่เหมือนกัน
คุณจะเห็นสิ่งนี้:
parent transid verify failed on 109973766144 wanted 1823 found 1821
นั่นหมายความว่า btrfs ต้องการ transif 1826 (นั่นคือในวารสาร) แต่บนดิสก์ที่เห็น 1821 ดังนั้นดิสก์จึงมีธุรกรรม 2 รายการที่ไม่สอดคล้องกับวารสาร ฉันเองมีความเสี่ยงที่ brtfs-zero-log ที่นี่เพียงเพราะธุรกรรม 2 รายการเท่านั้น แต่จะปลอดภัย 100% หากนี่เป็นข้อมูลเดียวของคุณ (โดยวิธีถ้าคุณมีข้อมูลสำคัญคุณไม่ควรมีสำเนาเพียง 1 สำเนาเสมอมีสำเนา / สำรองข้อมูลในตำแหน่งอื่นที่ปลอดภัยเสมอ - โทษผู้สร้าง btrfs จะไม่ แสดงให้เห็นถึงบุคคลที่ขาดความรับผิดชอบในการไม่มีการสำรองข้อมูล - btrfs ไม่ใช่โซลูชันการสำรองข้อมูลระบบไฟล์ของมัน - ไม่มีอะไรเป็นโซลูชันการสำรองข้อมูลที่แท้จริงนอกเหนือจากการมีสำเนาของมันที่อื่น ๆ - ไม่แม้แต่ไดรฟ์พาริตี้หรือมิเรอร์ นั่งอยู่ใต้ดินในเทือกเขาแอลป์ในขณะที่สำเนาที่ใช้งานอยู่ในสำนักงานของคุณในเท็กซัส)
parent transid verify failed on 31302336512 wanted 62455 found 62456
ที่นี่วารสารต้องการ 62455 แต่ดิสก์อยู่ข้างหน้า 62456 ดังนั้นในกรณีของคุณฉันจะลบบันทึกประจำวัน วารสารไม่ได้อัปเดตในเวลานี้ ฉันบอกคุณอีกครั้งว่าการเป็นสิ่งที่ปลอดภัยถ้าข้อมูลของคุณเท่านั้นและสิ่งสำคัญยิ่ง (น่าละอายกับคุณ) และฉันจะดำเนินการด้านล่างก่อนเพื่อความปลอดภัย
ใช้ btrfsck / dev / sda5 (ซึ่งวิธีการตรวจสอบแบบอ่านอย่างเดียวเพื่อความปลอดภัยอย่างสมบูรณ์ตัวเลือก btrfsck เพียงตัวเดียวที่คุณต้องกังวล) จะแสดงข้อความเหล่านั้น
แต่ระวังว่าข้อมูลนั้นสำคัญหรือไม่ฉันต้องทำก่อน (ดังที่คนอื่นพูด)
mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3
จากนั้น cp หรือ rsync ไฟล์ทั้งหมดของคุณไปยังตำแหน่งที่ปลอดภัยจากนั้นเมื่อทำ btrfs-zero-log อย่างปลอดภัยหากเป็นการดำเนินการที่ประสบความสำเร็จคุณเพิ่งเสียเวลาสำรองระบบของคุณ (แต่ถ้ามันไม่สำเร็จคุณก็แค่บันทึก ตูด)
จากนั้นหากการเมานต์ล้มเหลวจะทำการกู้คืน btrfs (ดัมพ์ของระบบเนื่องจากฉันเข้าใจว่าเป็นการดำเนินการที่สามารถกู้คืนได้ แต่มันจะขอ Y หรือ y ทุก ๆ ครั้งเพื่อดูเอาต์พุต)
btrfs restore /dev/sda5 /USB
จากนั้นเมื่อปลอดภัย (เมื่อเสร็จสิ้นการกู้คืน btrfs) ให้ทำ btrfs-zero-log หากการดำเนินการที่ประสบความสำเร็จคุณเพิ่งเสียเวลาสำรองระบบของคุณ (แต่ถ้าไม่สำเร็จคุณจะบันทึก ass)
คุณสามารถเรียกใช้หน้าจอก่อน
screen /bin/bash
btrfs restore /dev/sda5 /USB
หน้าจอด้านบันทึก
หากต้องการแยกออก (คำสั่งจะยังคงทำงาน): ให้ควบคุมแล้วพิมพ์ ": detach" โดยไม่ใส่เครื่องหมายอัญประกาศแล้วกด ENTER
อีกวิธีในการแยกออก: จากนั้นให้ปิด putty หรือเทอร์มินัลของคุณและมันจะแยกออก (คำสั่ง / การคืนค่าจะยังคงทำงานอยู่)
หากต้องการตรวจสอบให้ตรวจสอบย้อนกลับไปที่:
screen -x
หน้าจอ -x จะแนบกับเซสชันแม้ว่าจะถูกแยกออกและไม่เหมือนกับ -h ที่บอกว่าจะแนบแม้ว่าจะแนบไว้แล้วก็ตาม)
หากคุณมีหลายหน้าจอ screen -x จะบอกว่าคุณต้องเจาะจงมากขึ้นในการแนบกับเซสชัน:
screen -ls
ls สำหรับรายการทุกเซสชันง่ายต่อการจดจำ
เพื่อดู PID คุณสามารถทำสิ่งนี้ได้:
ps aux | grep screen
เมื่อคุณพบ PID ของคุณแล้วเรียกใช้หน้าจอเช่นนี้:
screen -x PID
ที่จะแนบไปกับเซสชั่นที่เฉพาะเจาะจง คุณสามารถมีหลายเซสชัน / สีโป๊วที่แนบมากับหน้าจอเดียวกัน (พวกเขาจะส่งข้อความที่เหมือนกันคุณสามารถพิมพ์คำสั่งในที่เดียวและพวกเขาจะถูกมิเรอร์ในสีโป๊วอื่น ๆ )
nospace_cache?