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

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

ฉันไม่มีความรู้เกี่ยวกับระบบปฏิบัติการที่ใช้งานได้ดังนั้นฉันจึงไม่รู้เลยว่านี่เป็นเรื่องจริงและในสถานการณ์ใด คำถามหลักของฉันคือ: สิ่งนี้เกิดขึ้นตามที่อธิบายไว้ในระบบ Linux / Unix (และอาจเป็นระบบปฏิบัติการอื่น ๆ )? ตัวอย่างเช่นนี่หมายความว่าถ้าฉันปิดคอมพิวเตอร์ทันทีหลังจากที่ฉันแก้ไขและบันทึกไฟล์การเปลี่ยนแปลงของฉันจะหายไปมากที่สุด? บางทีมันอาจขึ้นอยู่กับประเภทของดิสก์ - ฮาร์ดไดรฟ์แบบดั้งเดิมกับดิสก์แบบโซลิดสเตต?

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

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

พวกเขาอาจจะ ฉันจะไม่พูดว่า "น่าจะ" แต่ความเป็นไปได้นั้นขึ้นอยู่กับหลาย ๆ อย่าง

วิธีที่ง่ายในการเพิ่มประสิทธิภาพของการเขียนไฟล์คือสำหรับระบบปฏิบัติการที่จะแคชข้อมูลบอกแอปพลิเคชันที่เขียนผ่านไปแล้ว (โกหก) แล้วทำการเขียนในภายหลัง สิ่งนี้มีประโยชน์อย่างยิ่งหากมีกิจกรรมดิสก์อื่น ๆ เกิดขึ้นในเวลาเดียวกัน: ระบบปฏิบัติการสามารถจัดลำดับความสำคัญการอ่านและทำการเขียนในภายหลัง นอกจากนี้ยังสามารถลบความต้องการสำหรับการเขียนที่แท้จริงได้อย่างสมบูรณ์เช่นในกรณีที่มีการลบไฟล์ชั่วคราวอย่างรวดเร็วหลังจากนั้น

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

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

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

นอกจากfsync()นั้นยังมีsync()และการsyncfs()เรียกของระบบที่ขอให้ระบบตรวจสอบให้แน่ใจว่าการเขียนทั่วทั้งระบบทั้งหมดหรือการเขียนทั้งหมดบนระบบไฟล์เฉพาะได้ตีดิสก์ ยูทิลิตีsyncนี้สามารถใช้เรียกสิ่งเหล่านั้นได้

จากนั้นยังมีการO_DIRECTตั้งค่าสถานะopen()ซึ่งควร "พยายามลดผลกระทบของแคชของ I / O ไปและกลับจากไฟล์นี้" การลบการแคชช่วยลดประสิทธิภาพดังนั้นส่วนใหญ่จะถูกใช้โดยแอปพลิเคชัน (ฐานข้อมูล) ที่ทำการแคชของตนเองและต้องการควบคุมมัน ( O_DIRECTไม่ได้โดยไม่มีปัญหาความคิดเห็นเกี่ยวกับมันในหน้าคนค่อนข้างสนุก)

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

วิธีที่ระบบไฟล์เกี่ยวข้องกับการเปลี่ยนแปลงของข้อมูลเมตาและการเรียงลำดับระหว่างข้อมูลเมตาและการเขียนข้อมูลนั้นมีความแตกต่างกันมาก ตัวอย่างเช่นext4หากคุณตั้งค่าสถานะการเมานdata=journalท์การเขียนทั้งหมด - แม้แต่การเขียนข้อมูล - จะต้องผ่านเจอร์นัลและควรจะค่อนข้างปลอดภัย นั่นหมายความว่าพวกเขาจะถูกเขียนสองครั้งดังนั้นประสิทธิภาพจึงลดลง ตัวเลือกเริ่มต้นพยายามเรียงลำดับการเขียนเพื่อให้ข้อมูลอยู่ในดิสก์ก่อนที่จะอัปเดตข้อมูลเมตา ตัวเลือกอื่น ๆ หรือระบบไฟล์อื่น ๆ อาจจะดีขึ้นหรือแย่ลง; ฉันจะไม่ลองแม้แต่การศึกษาแบบเบ็ดเสร็จ

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

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

ตัวอย่างบางส่วนคือ:

• tmpfsเป็นระบบไฟล์ที่มีอยู่ใน RAM เท่านั้น (หรือมากกว่านั้นอย่างแม่นยำในแคชบัฟเฟอร์)
• ramfsระบบไฟล์ที่มีอยู่ใน RAM เท่านั้น
• ระบบไฟล์เครือข่ายใด ๆ (NFS, CIFS / SMB, AFS, AFP, …)
• ใด ๆระบบแฟ้มเสมือน ( sysfs, procfs, devfs, shmfs, ... )

แต่ถึงแม้สำหรับระบบไฟล์ที่มีดิสก์สำรองก็มักจะไม่เป็นเช่นนี้ หน้าวิธีการเสียหายฐานข้อมูล SQLiteมีบทที่เรียกว่าความล้มเหลวในการซิงค์ซึ่งอธิบายวิธีการเขียนในหลายกรณี (ในกรณีนี้ให้กับฐานข้อมูล SQLite) อาจล้มเหลวที่จะมาถึงบนดิสก์ SQLite นอกจากนี้ยังมีกระดาษสีขาวอธิบายห่วงมากมายที่คุณต้องกระโดดผ่านที่จะรับประกันปรมาณูกระทำใน SQLite (โปรดทราบว่าAtomic Writeนั้นยากกว่าปัญหามากกว่าแค่เขียนแต่แน่นอนว่าการเขียนลงดิสก์นั้นเป็นปัญหาย่อยของการเขียนเชิงอะตอมและคุณสามารถเรียนรู้มากมายเกี่ยวกับปัญหานั้นได้จากบทความนี้) บทความนี้มี ส่วนในสิ่งที่สามารถไปผิดที่มีส่วนย่อยเกี่ยวกับDisk Flushที่ไม่สมบูรณ์ซึ่งเป็นตัวอย่างของความซับซ้อนที่อาจป้องกันการเขียนจากดิสก์ (เช่นคอนโทรลเลอร์ HDD รายงานว่าเขียนไปยังดิสก์เมื่อจริงแล้วมันไม่มี - ใช่มีผู้ผลิต HDD ที่ทำสิ่งนี้ และอาจเป็นเรื่องถูกกฎหมายตามข้อกำหนดของ ATA เนื่องจากเป็นคำที่คลุมเครือในส่วนนี้)

มันเป็นความจริงที่ระบบปฏิบัติการส่วนใหญ่รวมถึง Unix, Linux และ Windows ใช้แคชการเขียนเพื่อเพิ่มความเร็วในการทำงาน นั่นหมายความว่าการปิดคอมพิวเตอร์โดยไม่ต้องปิดเครื่องเป็นความคิดที่ไม่ดีและอาจนำไปสู่การสูญเสียข้อมูล เช่นเดียวกันหากคุณลบที่เก็บข้อมูล USB ก่อนที่จะพร้อมที่จะลบ

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

กล่าวโดยสรุปมีเหตุผลว่าทำไมคุณควรปิดเครื่องคอมพิวเตอร์อย่างถูกต้องและเตรียมที่เก็บข้อมูล USB อย่างถูกต้องเพื่อนำออก

1. ที่เก็บข้อมูลแบบ Flash

มันขึ้นอยู่กับประเภทของดิสก์ (ฮาร์ดไดร์ฟดั้งเดิมเทียบกับโซลิดสเตตดิสก์) หรือตัวแปรอื่น ๆ ที่ฉันอาจไม่ทราบหรือไม่? มันเกิดขึ้น (ถ้ามี) เฉพาะใน Linux หรือมีอยู่ในระบบปฏิบัติการอื่นหรือไม่?

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

ในที่เก็บข้อมูลราคาประหยัดเช่นการ์ด SD คุณสามารถคาดหวังว่าจะลบบล็อกการลบทั้งหมด (ใหญ่กว่า 4KB หลายเท่า) สูญเสียข้อมูลซึ่งอาจเป็นไฟล์ต่าง ๆ หรือโครงสร้างที่สำคัญของระบบไฟล์

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

เมื่อใช้กรอบการทดสอบของเราเราจะทำการทดสอบชุดผลิตภัณฑ์ 17 รายการจากผู้จำหน่ายหกรายโดยใช้วงจรการฉีดผิดมากกว่าสามพันวงจร ผลการทดลองของเราพบว่าอุปกรณ์ SSD ที่ทดสอบ 14 รายการจาก 17 ชิ้นมีพฤติกรรมความล้มเหลวที่น่าประหลาดใจภายใต้ข้อผิดพลาดด้านพลังงานรวมถึงความเสียหายของบิตการเขียนที่ไม่เหมาะสมการเขียนที่ไม่สามารถระบุได้

2017: https://dl.acm.org/citation.cfm?id=2992782&preflayout=flat

2013: https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf?wptouch_preview_theme=enabled

2. การหมุนฮาร์ดดิสก์ไดรฟ์

การหมุน HDDs มีลักษณะแตกต่างกัน เพื่อความปลอดภัยและความเรียบง่ายฉันขอแนะนำให้สมมติว่าพวกเขามีความไม่แน่นอนในทางปฏิบัติเช่นเดียวกับที่เก็บข้อมูลแบบแฟลช

เว้นแต่คุณจะมีหลักฐานเฉพาะซึ่งคุณไม่ชัดเจน ฉันไม่มีตัวเลขเปรียบเทียบสำหรับการหมุน HDD

HDD อาจทำให้ส่วนที่เขียนไม่สมบูรณ์มีการตรวจสอบที่ไม่ดีซึ่งจะทำให้เราล้มเหลวในการอ่านที่ดีในภายหลัง พูดอย่างกว้าง ๆ ว่าโหมดความล้มเหลวของ HDD นั้นคาดว่าจะสมบูรณ์ ระบบไฟล์ Linux ดั้งเดิมได้รับการออกแบบโดยคำนึงถึงมัน พวกเขามุ่งมั่นที่จะรักษาสัญญาfsync()ในการเผชิญกับความผิดพลาดของการสูญเสียพลังงานประเภทนี้ (เราอยากเห็นสิ่งนี้รับประกันใน SSD)

อย่างไรก็ตามฉันไม่แน่ใจว่าระบบไฟล์ลีนุกซ์จะสามารถทำสิ่งนี้ได้หรือไม่

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

2.1 หากคุณไม่ทราบว่าสัญญา fsync () คืออะไร

สัญญา fsync () เป็นแหล่งที่มาของข่าวดีและข่าวร้าย คุณต้องเข้าใจข่าวดีก่อน

ข่าวดี: fsync()มีการบันทึกไว้เป็นอย่างดีว่าเป็นวิธีที่ถูกต้องในการเขียนข้อมูลไฟล์เช่นเมื่อคุณกด "บันทึก" rename()และมันก็เป็นที่เข้าใจกันอย่างกว้างขวางว่าบรรณาธิการข้อความเช่นต้องแทนที่ไฟล์ที่มีอยู่โดยใช้อะตอม สิ่งนี้มีไว้เพื่อให้แน่ใจว่าคุณเก็บไฟล์เก่าไว้เสมอหรือรับไฟล์ใหม่ (ซึ่งถูกfsync()แก้ไขก่อนเปลี่ยนชื่อ) คุณไม่ต้องการถูกปล่อยให้มีไฟล์ใหม่เป็นแบบครึ่งภาษา

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

ดังนั้นแอปพลิเคชันที่มีอยู่ซึ่งไม่ได้ใช้ fsync () อย่างถูกต้อง

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

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

ความละเอียดในปัจจุบันคือระบบไฟล์ Linux ที่เป็นที่นิยมในปัจจุบัน ค่าเริ่มต้นเพื่อสนับสนุนรูปแบบการเปลี่ยนชื่อ () โดยไม่ต้องใช้ fsync ()ใช้ "ความเข้ากันได้ข้อผิดพลาดข้อบกพร่อง" กับรุ่นก่อนหน้า สิ่งนี้สามารถปิดการใช้งานได้ด้วยตัวเลือกการเมานnoauto_da_allocต์

นี่ไม่ใช่การป้องกันที่สมบูรณ์ โดยพื้นฐานแล้วมันจะทำการล้าง IO ที่ค้างอยู่ที่เวลาเปลี่ยนชื่อ () แต่จะไม่รอให้ IO ทำการทำให้เสร็จสิ้นก่อนที่จะเปลี่ยนชื่อ มันดีกว่าหน้าต่างอันตราย 60 วินาที! ดูเพิ่มเติมที่คำตอบของระบบไฟล์ใดที่จำเป็นต้องใช้ fsync () เพื่อความปลอดภัยจากการชนเมื่อแทนที่ไฟล์ที่มีอยู่ด้วยการเปลี่ยนชื่อ ()

ระบบไฟล์ที่ได้รับความนิยมน้อยกว่าบางระบบไม่มีการป้องกัน XFS ปฏิเสธที่จะทำเช่นนั้น และUBIFSก็ไม่ได้นำไปใช้เช่นกันอาจยอมรับได้ แต่ต้องการงานจำนวนมากเพื่อให้เป็นไปได้ หน้าเดียวกันชี้ให้เห็นว่า UBIFS มีปัญหา "สิ่งที่ต้องทำ" อื่น ๆ สำหรับความสมบูรณ์ของข้อมูลรวมถึงการสูญเสียพลังงาน UBIFS เป็นระบบไฟล์ที่ใช้โดยตรงกับที่เก็บข้อมูลแฟลช ฉันจินตนาการว่าความยากลำบากบางอย่างที่ UBIFS กล่าวถึงกับที่เก็บข้อมูลแฟลชอาจเกี่ยวข้องกับข้อบกพร่องของ SSD

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

dirty_expire_centisecsค่าเริ่มต้นของ Linux เป็น3000 (30 วินาที)และควบคุมระยะเวลาก่อนที่ข้อมูลที่เพิ่งเขียนใหม่จะ "หมดอายุ" (ดูhttps://lwn.net/Articles/322823/ )

ดูhttps://www.kernel.org/doc/Documentation/sysctl/vm.txtเพื่อดู tunables ที่เกี่ยวข้องเพิ่มเติมและ google สำหรับอีกมากมาย (เช่น google on dirty_writeback_centisecs)

ค่าเริ่มต้นของ Linux /proc/sys/vm/dirty_writeback_centisecsคือ 500 (5 วินาที)และ PowerTop แนะนำให้ตั้งค่าเป็น 1500 (15 วินาที) เพื่อลดการใช้พลังงาน

การเขียนกลับที่ล่าช้ายังให้เวลาแก่เคอร์เนลเพื่อดูว่าไฟล์จะมีขนาดใหญ่เพียงใดก่อนที่จะเริ่มเขียนลงดิสก์ ระบบไฟล์ที่มีการจัดสรรล่าช้า (เช่น XFS และอื่น ๆ ในทุกวันนี้) ไม่ได้เลือกตำแหน่งบนดิสก์เพื่อวางข้อมูลของไฟล์ที่เขียนใหม่จนกว่าจะมีความจำเป็นแยกจากการจัดสรรพื้นที่สำหรับ inode เอง สิ่งนี้ช่วยลดการแตกแฟรกเมนต์โดยปล่อยให้พวกเขาหลีกเลี่ยงการเริ่มต้นไฟล์ขนาดใหญ่ในช่องว่าง 1 เมกะไบต์ระหว่างไฟล์อื่นเช่น

หากมีการเขียนข้อมูลจำนวนมากการเขียนข้อมูลกลับสู่ดิสก์สามารถถูกทริกเกอร์โดยเกณฑ์สำหรับข้อมูลที่สกปรก (ยังไม่ได้ซิงค์กับดิสก์) เท่าใดที่สามารถอยู่ใน pagecache

หากคุณไม่ได้ทำอะไรมากไฟกิจกรรมฮาร์ดไดรฟ์ของคุณจะไม่ทำงานต่อเป็นเวลา 5 (หรือ 15) วินาทีหลังจากกดปุ่มบันทึกในไฟล์ขนาดเล็ก

หากโปรแกรมแก้ไขของคุณใช้fsync()หลังจากเขียนไฟล์เคอร์เนลจะเขียนลงดิสก์โดยไม่ชักช้า (และfsyncจะไม่ส่งคืนจนกว่าข้อมูลจะถูกส่งไปยังดิสก์จริง)

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

บนดิสก์ที่หมุนได้ (แม่เหล็ก) คุณอาจเห็นความล่าช้าเล็กน้อยระหว่าง 7 ถึง 10 ms ก่อนข้อมูลจากคำสั่งการเขียน SATA จะปลอดภัยจากการปิดเครื่องหากมีการรอ / อ่าน / เขียนล่วงหน้า (คำตอบอื่น ๆ ของคำถามนี้ให้รายละเอียดเพิ่มเติมเกี่ยวกับแคชเขียนดิสก์และอุปสรรคในการเขียนที่ FSs ที่ถูกเจอร์นัลสามารถใช้เพื่อหลีกเลี่ยงความเสียหาย)