ปรัชญาของการล่าช้าในการเขียนข้อมูลลงดิสก์คืออะไร

ใน Linux การดำเนินการคำสั่งที่เสร็จสิ้นแล้วเช่นcpหรือddไม่ได้หมายความว่าข้อมูลถูกเขียนไปยังอุปกรณ์ หนึ่งมีการยกตัวอย่างเช่นการโทรsyncหรือเรียกว่า "Safely Remove" หรือ "Eject" ฟังก์ชั่นบนไดรฟ์

ปรัชญาของวิธีการดังกล่าวคืออะไร? เหตุใดข้อมูลจึงไม่ถูกเขียนพร้อมกัน ไม่มีอันตรายที่การเขียนจะล้มเหลวเนื่องจากข้อผิดพลาด I / O หรือไม่?

ปรัชญาของวิธีการดังกล่าวคืออะไร?

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

เหตุใดข้อมูลจึงไม่ถูกเขียนพร้อมกัน

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

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

ไม่มีอันตรายใด ๆ ที่การเขียนจะล้มเหลวเนื่องจากข้อผิดพลาดของ IO?

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

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

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

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

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

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

ไม่มีอันตรายใด ๆ ที่การเขียนจะล้มเหลวเนื่องจากข้อผิดพลาดของ IO?

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

อะซิงโครนัส I / O ที่บัฟเฟอร์ถูกใช้งานก่อน Linux และแม้กระทั่งก่อนหน้า Unix ยูนิกซ์มีมันและมีลูกหน่อของมันทั้งหมด

นี่คือสิ่งที่ Ritchie และ Thompson เขียนไว้ในกระดาษ CACM ของพวกเขาระบบการแบ่งปันเวลา UNIX :

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

ในคำถามของคุณคุณเขียนว่า:

ไม่มีอันตรายใด ๆ ที่การเขียนจะล้มเหลวเนื่องจากข้อผิดพลาดของ IO?

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

BSD เพิ่มการfsyncเรียกระบบเพื่อให้โปรแกรมสามารถมั่นใจได้ว่าข้อมูลไฟล์ถูกเขียนลงบนดิสก์อย่างสมบูรณ์ก่อนที่จะดำเนินการต่อและระบบ Unix ที่ตามมาได้จัดเตรียมตัวเลือกในการเขียนแบบซิงโครนัส GNU dd มีตัวเลือกconv=fsyncเพื่อให้แน่ใจว่าข้อมูลทั้งหมดถูกเขียนออกมาก่อนที่คำสั่งจะออก มีประโยชน์เมื่อเขียนถึงแฟลชไดรฟ์แบบถอดได้ช้าซึ่งข้อมูลบัฟเฟอร์อาจใช้เวลาหลายนาทีในการเขียน

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

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

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

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

อย่างไรก็ตามการรวมกันของการอ่านที่คาดการณ์ไว้โดยการอ่าน (ไปยังแคช / บัฟเฟอร์) มากกว่าที่ถูกถาม - และการเรียงลำดับข้อมูลที่รอการเขียนดังนั้นจึงสามารถเขียนได้ใน "one motion" - จริงๆแล้วเป็นความคิดที่ดีมาก เวลาโดยเฉพาะอย่างยิ่งในระบบที่มีจำนวนผู้อ่านและเขียนจำนวนมาก

มันไม่เฉพาะเจาะจงกับ Linux และมันถูกเรียกว่าแคชหน้า (ซึ่ง Linux ทำได้ค่อนข้างดี) ดูเพิ่มเติมที่http://linuxatemyram.com/ ; ดังนั้นหากไฟล์ถูกเขียนให้อ่านอีกครั้งหลังจากนั้นสองสามวินาทีบ่อยครั้งมากที่ไม่จำเป็นต้องใช้ดิสก์ I / O

ข้อได้เปรียบหลักคือในหลาย ๆ ระบบมี RAM จำนวนมากและบางส่วนสามารถใช้เป็นแคชโดยเคอร์เนล ดังนั้นการดำเนินการกับไฟล์บางอย่างสามารถทำกำไรจากการแคชนี้ได้ นอกจากนี้เวลาของดิสก์ I / O นั้นช้ากว่ามาก (โดยทั่วไปจะเป็นหลายพันเท่าสำหรับ SDD และช้าลงเกือบหนึ่งล้านเท่าสำหรับฮาร์ดดิสก์เชิงกล) กว่า RAM

รหัสแอปพลิเคชันสามารถให้คำแนะนำเกี่ยวกับแคชนี้: ดูเช่นposix_fadvise (2) & madvise (2)

จานหมุนช้ากว่าแรม เราใช้การแคชของการอ่าน / เขียนเพื่อ 'ซ่อน' ข้อเท็จจริงนี้

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

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

และเราจำเป็นต้องเขียนแคช - ดิสก์หมุนช้ามากเมื่อเทียบกับ แต่การทำประเภท RAID ที่ทันสมัยมีโทษอย่างมากต่อการทำงาน

ยกตัวอย่างเช่น RAID 6 เพื่อที่จะเขียน IO อย่างสมบูรณ์จะต้อง:

• อ่านบล็อคการอัพเดท
• อ่าน parity1
• อ่าน parity 2
• เขียนบล็อกใหม่
• เขียนพาริตี 1
• เขียนพาริตี 2

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

แต่มีวิธีแก้ปัญหาที่ง่ายดีเขียน coalescing หากคุณสามารถสร้าง 'เต็มแถบ' เขียนในบัฟเฟอร์คุณไม่จำเป็นต้องอ่านพาริตี้จากดิสก์ของคุณ - คุณสามารถคำนวณได้ตามสิ่งที่คุณมีในหน่วยความจำ

เป็นสิ่งที่พึงปรารถนามากที่จะทำสิ่งนี้เพราะเมื่อนั้นคุณจะไม่ต้องเขียนภาคขยายอีกต่อไป แน่นอนคุณสามารถจบลงด้วยการลงโทษการเขียนที่ต่ำกว่า RAID 1 + 0

พิจารณา:

RAID 6, 8 + 2 - 10 แกน

8 บล็อกข้อมูลต่อเนื่องกันเพื่อเขียน - คำนวณพาริตีในแคชและเขียนหนึ่งบล็อกไปยังแต่ละดิสก์ 10 การเขียนต่อ 8 หมายถึงโทษการเขียน 1.25 10 ดิสก์ของ RAID 1 + 0 ยังคงมีโทษการเขียนเป็น 2 (เพราะคุณต้องเขียนไปยังแต่ละ submirror) ดังนั้นในสถานการณ์นี้คุณสามารถทำให้ RAID 6 ทำงานได้ดีกว่า RAID1 + 0 ในการใช้งานจริงคุณจะได้รับโปรไฟล์ IO เพิ่มขึ้นอีกเล็กน้อย

ดังนั้นการเขียนแคชจึงมีความแตกต่างอย่างมากต่อประสิทธิภาพการรับรู้ของชุด RAID - คุณจะได้รับการเขียนด้วยความเร็ว RAM และมีโทษการเขียนต่ำ - ปรับปรุงปริมาณงานที่ยั่งยืนถ้าคุณทำ

และถ้าคุณทำไม่ได้คุณจะประสบกับประสิทธิภาพการทำงานที่ช้าของ SATA แต่คูณด้วย 6 และเพิ่มความขัดแย้งในนั้น SATA RAID-6 แบบ 10 ทางของคุณโดยไม่ต้องเขียนแคชจะเร็วกว่าไดรฟ์เดียวที่ไม่มี RAID ... แต่ก็ไม่มาก

คุณมีความเสี่ยงแม้ว่า - ตามที่คุณสังเกต - การสูญเสียพลังงานหมายถึงการสูญเสียข้อมูล คุณสามารถลดสิ่งนี้ได้โดยการล้างแคชรอบแบตเตอรี่สำรองแคชของคุณหรือใช้ SSD หรือแคชที่ไม่ลบเลือนอื่น ๆ

ไม่มีคำตอบอื่น ๆ ที่กล่าวถึงความล่าช้าในการจัดสรร XFS, ext4, BTRFS และ ZFS ทั้งหมดใช้มัน XFS ใช้งานมาตั้งแต่ก่อนมี ext4 ดังนั้นฉันจะใช้มันเป็นตัวอย่าง:

XFSไม่แม้แต่จะตัดสินใจว่าจะวางข้อมูลไว้ที่ใดจนกระทั่งเขียนข้อมูล การจัดสรรที่ล่าช้าให้ข้อมูลแก่ผู้จัดสรรมากขึ้นเพื่อใช้เป็นฐานในการตัดสินใจ เมื่อเขียนไฟล์เป็นครั้งแรกจะไม่มีทางรู้ว่ามันจะเป็นไฟล์ 4k หรือไฟล์ 1G- และยังคงเติบโต หากมีพื้นที่ว่างต่อเนื่อง 10G อยู่ที่ใดที่หนึ่งการวางไฟล์ 4k ไว้ที่จุดเริ่มต้นจะไม่ดี การวางไฟล์ขนาดใหญ่ไว้ที่จุดเริ่มต้นของพื้นที่ว่างขนาดใหญ่จะช่วยลดการกระจายตัว

คำตอบอื่น ๆ ทั้งหมดที่นี่เป็นอย่างน้อยส่วนใหญ่ถูกต้องสำหรับกรณีปกติและฉันขอแนะนำให้อ่านใด ๆ ของพวกเขาก่อนฉัน แต่คุณพูดถึง dd และ dd มีกรณีการใช้งานทั่วไปที่อาจไม่เกี่ยวข้องกับการเขียนแคช การแคชการเขียนถูกนำไปใช้เป็นหลักในระดับระบบไฟล์ อุปกรณ์ Raw โดยปกติจะไม่ทำการเขียนแคช (ไดรเวอร์อุปกรณ์หลายตัวเช่นการจู่โจมหรือ lvm เป็นอีกลูกหนึ่งของแว็กซ์) เนื่องจาก dd มักจะใช้กับอุปกรณ์บล็อกดิบมันมี bs และตัวเลือกที่เกี่ยวข้องเพื่อให้สามารถเขียนขนาดใหญ่เพื่อประสิทธิภาพที่ดีขึ้นในอุปกรณ์ดิบ สิ่งนี้ไม่เป็นประโยชน์เมื่อจุดปลายทั้งสองเป็นไฟล์ปกติ (แม้ว่าการเขียนขนาดใหญ่จะใช้การเรียกของระบบน้อยลงในกรณีนี้) สถานที่ทั่วไปอื่น ๆ ที่สามารถมองเห็นได้โดยเฉพาะอย่างยิ่งนี้คือแพ็คเกจ mtools ซึ่งเป็นการใช้งานระบบไฟล์ไขมันของผู้ใช้ การใช้ mtools กับฟลอปปี้ไดรฟ์จะรู้สึกซบเซาอย่างไม่น่าเชื่อเนื่องจากเครื่องมือต่างๆมีการซิงโครนัสอย่างสมบูรณ์และฟลอปปี้ไดรฟ์นั้นช้ามากอย่างไม่น่าเชื่อ การติดตั้งฟลอปปี้และการใช้ระบบไฟล์เคอร์เนลจะตอบสนองได้ดีกว่ายกเว้นการต่อเชื่อมซึ่งเป็นแบบซิงโครนัส (และสำคัญมากสำหรับวิธีการดังกล่าวเพื่อป้องกันการสูญหายของข้อมูล มีโปรแกรมอื่นเพียงไม่กี่โปรแกรมที่ฉันทราบว่ามีการใช้งานเป็นประจำกับอุปกรณ์ดิบเช่นฐานข้อมูลที่กำหนดค่าเป็นพิเศษ (ซึ่งใช้แคชการเขียนของตนเอง) tar และอุปกรณ์พิเศษและเครื่องมือระบบไฟล์เช่น chdsk, mkfs และ mt การติดตั้งฟลอปปี้และการใช้ระบบไฟล์เคอร์เนลจะตอบสนองได้ดีกว่ายกเว้นการต่อเชื่อมซึ่งเป็นแบบซิงโครนัส (และสำคัญมากสำหรับวิธีการดังกล่าวเพื่อป้องกันการสูญหายของข้อมูล มีโปรแกรมอื่นเพียงไม่กี่โปรแกรมที่ฉันทราบว่ามีการใช้งานเป็นประจำกับอุปกรณ์ดิบเช่นฐานข้อมูลที่กำหนดค่าเป็นพิเศษ (ซึ่งใช้แคชการเขียนของตนเอง) tar และอุปกรณ์พิเศษและเครื่องมือระบบไฟล์เช่น chdsk, mkfs และ mt การติดตั้งฟลอปปี้และการใช้ระบบไฟล์เคอร์เนลจะตอบสนองได้ดีกว่ายกเว้นการต่อเชื่อมซึ่งเป็นแบบซิงโครนัส (และสำคัญมากสำหรับวิธีการดังกล่าวเพื่อป้องกันการสูญหายของข้อมูล มีโปรแกรมอื่นเพียงไม่กี่โปรแกรมที่ฉันทราบว่ามีการใช้งานเป็นประจำกับอุปกรณ์ดิบเช่นฐานข้อมูลที่กำหนดค่าเป็นพิเศษ (ซึ่งใช้แคชการเขียนของตนเอง) tar และอุปกรณ์พิเศษและเครื่องมือระบบไฟล์เช่น chdsk, mkfs และ mt

ปรัชญาไม่ปลอดภัยโดยค่าเริ่มต้น

มีสองกลยุทธ์ที่สมเหตุสมผลและชัดเจนที่เป็นไปได้: flush การเขียนลงดิสก์ทันทีหรือการเขียนล่าช้า UNIX เลือกอดีตอย่างหลัง เพื่อความปลอดภัยคุณต้องโทรหาfsyncหลังจากนั้น

อย่างไรก็ตามคุณสามารถระบุล่วงหน้าเพื่อความปลอดภัยโดยการติดตั้งอุปกรณ์ที่มีตัวเลือกหรือต่อไฟล์โดยการเปิดพวกเขาด้วยsyncO_SYNC

โปรดจำไว้ว่า UNIX ได้รับการออกแบบมาสำหรับผู้เชี่ยวชาญด้านคอมพิวเตอร์ "ปลอดภัยโดยค่าเริ่มต้น" ไม่ได้รับการพิจารณา ความปลอดภัยหมายถึง I / O ที่ช้าลงและระบบแรก ๆ เหล่านั้นมี I / O ที่ช้ากว่าทำให้ราคาสูงขึ้น น่าเสียดายที่ UNIX และ Linux ไม่ได้เปลี่ยนเป็นการใช้ค่าเริ่มต้นอย่างปลอดภัยแม้ว่านี่เป็นการเปลี่ยนแปลงที่ไม่ทำลาย

มันแลกเปลี่ยนความน่าเชื่อถือเล็กน้อยเพื่อเพิ่มปริมาณงานได้อย่างมาก

ตัวอย่างเช่นโปรแกรมบีบอัดวิดีโอ ด้วยการเขียนล่าช้า ("เขียนกลับ"):

1. ใช้เวลาบีบอัดเฟรม 10ms
2. ปัญหาการเขียนเฟรมลงดิสก์
3. รอ 10ms สำหรับดิสก์เพื่อรับทราบการเขียนเสร็จสมบูรณ์
4. GOTO 1

กับ

1. ใช้เวลาบีบอัดเฟรม 10ms
2. ปัญหาการเขียนเฟรมไปยังดิสก์ (เสร็จสมบูรณ์ในพื้นหลัง)
3. GOTO 1

รุ่นที่สองปรากฏขึ้นเร็วเป็นสองเท่าเนื่องจากสามารถใช้ CPU และดิสก์ได้ในเวลาเดียวกันในขณะที่รุ่นแรกมักจะรอหนึ่งหรืออื่น ๆ

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

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

1. บัฟเฟอร์การเขียนเติมจนถึงจุดที่ไม่สามารถยอมรับการร้องขอการเขียนรอการตัดอีกต่อไปจนกว่าการเขียนจะเสร็จสมบูรณ์จริง ๆ

2. จำเป็นต้องปิดหรือลบอุปกรณ์ที่อยู่ระหว่างการเขียน

3. แอปพลิเคชันร้องขอการยืนยันเป็นพิเศษว่าการเขียนเสร็จสมบูรณ์จริง ๆ

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

นอกจากนี้ยังมี:

เขียน "สวัสดี Joe Moe"
เร็วกว่า:
เขียน "สวัสดี"
เขียน "Joe"
เขียน "Moe"

และนอกจากนี้ยังมี:

เขียน "สวัสดีคุณเป็นอย่างไรบ้าง"
เร็วกว่า:
เขียน "สวัสดีเกิดอะไรขึ้น"
ลบ
เขียนว่า"Howdy คุณเป็นอย่างไรบ้าง"
ลบ
เขียนว่า"สวัสดีคุณเป็นอย่างไรบ้าง"

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