คำถามติดแท็ก journaling

ใน Windows มีเครื่องมือค้นหาไฟล์ที่ดีที่เรียกว่าEverythingซึ่งfindเร็วกว่าและแตกต่างจากlocateผลลัพธ์ที่เป็นปัจจุบันเสมอ AFAIK ใช้งานได้โดยการกรอกฐานข้อมูลจากวารสาร NTFS (มันไม่ทำงานกับระบบไฟล์อื่น) ฉันสงสัยว่ามีบางอย่างที่คล้ายกัน (ฉันไม่สนใจ GUI จุดของฉันคือความเร็วและการรับประกันที่ทันสมัย) สำหรับ Linux (ext3 หรือ ext4) ฉัน googled แต่ไม่พบอะไรเลย สิ่งนี้สามารถทำได้หรือแม้กระทั่งคนที่ทำงานกับมัน?

46 filesystems  search  journaling 

สถานการณ์แบบคลาสสิก: ฉันวิ่งได้ไม่ดีrmและรับรู้ได้ทันทีหลังจากนั้นฉันก็ลบไฟล์ผิด (ไม่มีอะไรสำคัญและฉันมีการสำรองข้อมูลล่าสุดอย่างอดทน แต่ก็น่ารำคาญ) รู้ว่ากิจกรรมของดิสก์ต่อไปเป็นศัตรูของฉันถ้าฉันต้องการกู้คืนไฟล์ด้วยextundeleteหรือเครื่องมือดังกล่าวฉันก็ขับเคลื่อนเครื่องลงทางกายภาพทันที (เช่นด้วยปุ่มเปิดปิดไม่ใช่ด้วยhaltหรือคำสั่งใด ๆ ) นี่เป็นแล็ปท็อปที่ไม่มีงานสำคัญที่ทำงานอยู่หรือมีอะไรเปิดอยู่ดังนั้นจึงเป็นการทำงานที่ยอมรับได้ (โดยวิธีการที่ฉันได้เรียนรู้ตั้งแต่นั้นมาสิ่งแรกที่ต้องทำในสถานการณ์ดังกล่าวจะประเมินก่อนหากไฟล์ที่หายไปอาจจะยังคงเปิดโดยกระบวนการhttps://unix.stackexchange.com/a/101247 - หากเป็นเช่นนั้นคุณควรกู้คืนด้วยวิธีนี้แทนที่จะปิดเครื่อง) ถึงกระนั้นเมื่อเครื่องถูกปิดฉันคิดว่าในขณะที่และตัดสินใจว่าไฟล์ไม่คุ้มค่ากับการลงทุนในการบูทระบบสดเพื่อการพิสูจน์หลักฐานที่เหมาะสม ดังนั้นฉันจึงขับเคลื่อนเครื่องสำรอง แล้วฉันก็ค้นพบว่าไฟล์ของฉันยังคงนั่งอยู่บนดิสก์: สิ่งที่rmไม่ได้แพร่กระจายไปยังดิสก์ก่อนที่ฉันจะปิดตัวลง ฉันเต้นเล็กน้อยและขอบคุณพระเจ้าแห่งดูแลระบบสำหรับการให้อภัยที่ไม่คาดคิดของเขา คำถามของฉันคือตอนนี้เพื่อทำความเข้าใจว่ามันเป็นไปได้อย่างไรและอะไรคือความล่าช้าทั่วไปก่อนที่rmจะแพร่กระจายสู่ดิสก์ ฉันรู้ว่าดิสก์ IO ไม่ได้ถูกลบทิ้งทันที แต่มันอยู่ในหน่วยความจำระยะหนึ่ง แต่ฉันคิดว่าดิสก์เจอร์นัลจะทำให้แน่ใจได้อย่างรวดเร็วว่าการดำเนินการที่ค้างอยู่จะไม่สูญหายทั้งหมด https://unix.stackexchange.com/a/78766ดูเหมือนจะบอกกล่าวกับกลไกแยกต่างหากเพื่อล้างหน้าสกปรกและเพื่อล้างการดำเนินการของวารสาร แต่ไม่ได้ให้รายละเอียดที่เพียงพอเกี่ยวกับวิธีที่วารสารจะเกี่ยวข้องกับrmและความล่าช้าที่คาดไว้ก่อนหน้า การดำเนินการจะถูกล้างออก รายละเอียดเพิ่มเติม: ข้อมูลอยู่ในพาร์ติชัน ext4 ภายในโวลุ่ม LUKS และเมื่อบูตเครื่องสำรองข้อมูลฉันเห็นสิ่งต่อไปนี้ในsyslog: Sep 24 10:24:58 gamma kernel: [ 11.457007] EXT4-fs (dm-0): 1 orphan inode deleted Sep 24 10:24:58 gamma kernel: …

31 linux-kernel  data-recovery  rm  virtual-memory  journaling 

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

28 filesystems  journaling  corruption 

ฉันมีการตั้งค่าแบบฝังตัวโดยใช้ initramfs สำหรับระบบไฟล์รูท แต่ใช้พาร์ติชัน ext3 แบบกำหนดเองที่ติดตั้งอยู่บนไดรฟ์ IDE แบบคอมแพคแฟลช เนื่องจากความถูกต้องของข้อมูลเมื่อเผชิญกับการสูญเสียพลังงานเป็นปัจจัยที่สำคัญที่สุดในการตั้งค่าทั้งหมดฉันจึงใช้ตัวเลือกต่อไปนี้เพื่อเมานต์ (ด้านล่างคือรายการจาก/etc/fstabไฟล์ของฉัน <file system> <mount pt> <type> <options> <dump><pass> /dev/sda2 /data ext3 auto,exec,relatime,sync,barrier=1 0 2 ฉันมาจากตัวเลือกเหล่านี้จากการอ่านหนังสือบนอินเทอร์เน็ต สิ่งที่ฉันเป็นห่วงคือเนื้อหาของการ/proc/mountsให้ดังต่อไปนี้: /dev/sda2 /data ext3 rw,sync,relatime,errors=continue,user_xattr,acl, barrier=1,data=writeback 0 0 จากสิ่งที่ฉันเข้าใจจากการอ่านรอบตัวคือฉันต้องการใช้data=journalตัวเลือกสำหรับการเมานต์ของฉันเพราะนี่เป็นการป้องกันที่ดีที่สุดต่อการเสียหายของข้อมูล อย่างไรก็ตามจากหน้า man สำหรับตัวเลือก ext3 ที่เฉพาะเจาะจงซึ่งmountจะกล่าวถึงสิ่งต่อไปนี้เกี่ยวกับตัวเลือก writeback: การเก็บข้อมูลจะไม่ถูกเก็บไว้ - ข้อมูลอาจถูกเขียนลงในระบบไฟล์หลักหลังจากที่เมตาดาต้าของมันถูกส่งไปยังเจอร์นัลแล้ว ข่าวลือนี้เป็นตัวเลือกทรูพุตที่สูงที่สุด มันรับประกันความสมบูรณ์ของระบบแฟ้มภายในอย่างไรก็ตามมันสามารถอนุญาตให้ข้อมูลเก่าที่จะปรากฏในไฟล์หลังจากความผิดพลาดและการกู้คืนวารสาร ฉันสับสนมากเกี่ยวกับเรื่องนี้ - หน้าคนดูเหมือนว่าจะแนะนำว่าสำหรับความสมบูรณ์ของระบบไฟล์ฉันต้องการที่จะระบุdata=writebackตัวเลือกmountแต่อ้างอิงอื่น ๆ มากที่สุดที่ฉันได้พบ (รวมทั้งหนังสือที่ตีพิมพ์บางอย่างเกี่ยวกับลินุกซ์ฝังตัว) …

15 mount  ext3  journaling