ทำไมการจัดเรียงข้อมูลไดรฟ์ C เพิ่มพื้นที่ว่างในดิสก์ของฉัน 10 GB

ฉันใช้Defragglerเพื่อจัดระเบียบพื้นที่ว่างบน 100 GB C: \ drive ซึ่งเต็ม 85 GB หลังจากการจัดเรียงข้อมูลไดรฟ์แสดงเพียง 75 GB เต็ม พื้นที่ว่าง 10 GB ปรากฏขึ้นอย่างน่าอัศจรรย์ได้อย่างไร ฉันทำข้อมูลสูญหายหรือไม่?

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

ntfs disk-space defragment

— goweon
แหล่งที่มา

อาจเป็นการโต้ตอบกับ shadow copy: ดูตัวอย่าง ( piriform.com/docs/defraggler/technical-information/

— ......

นอกจากนี้ Defraggler ยังมีตัวเลือกในการล้างถังรีไซเคิลก่อนจัดเรียงข้อมูล

— oKtosiTe

คำตอบ:

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

ฉันไม่เห็นสิ่งใดในประวัติรุ่นของ Defraggler หรือเอกสารที่ระบุว่าสามารถจัดเรียงไฟล์ได้อย่างถูกต้องเพื่อป้องกันการกำจัดสำเนาเงา อันที่จริงแล้วเธรดนี้จากฟอรัมสนับสนุนของ Defraggler ระบุว่าพวกเขารู้ว่ามันเกิดขึ้น (มีโพสต์จากผู้ดูแลบอร์ดที่ติดป้ายว่า "Official Piriform Bug Fixer" ในเธรด) แต่ไม่ได้ระบุว่าพวกเขากำลังจะแก้ไขหรือไม่

Shadow Copy อาจหายไปเมื่อคุณทำการจัดเรียงข้อมูลแบบวอลลุ่ม : สาเหตุที่เป็นเช่นนี้คือโดยค่าเริ่มต้น VSS ทำงานกับกลุ่ม 16 KB โดยค่าเริ่มต้นในขณะที่ NTFS ส่วนใหญ่มีการจัดรูปแบบด้วย 4 KB กลุ่ม ดังนั้นหากการดำเนินการ Defrag กำลังเคลื่อนย้ายข้อมูลที่ไม่ใช่หลาย ๆ คลัสเตอร์ 16 KB (หรือ "ระยะทาง" มันถูกย้ายไม่ใช่หลาย KB 16) จากนั้น VSS จะติดตามมันเป็นการเปลี่ยนแปลงและอาจล้างข้อมูลทั้งหมดของคุณ ภาพรวม

MSDN: จัดเรียงข้อมูลไฟล์ :

เมื่อเป็นไปได้ให้ย้ายข้อมูลในบล็อกที่เรียงชิดกันโดยเพิ่มขึ้นทีละ 16 กิโลไบต์ (KB) สิ่งนี้จะลดค่าใช้จ่ายในการคัดลอกเมื่อเขียนเมื่อเปิดใช้งาน Shadow Copy เนื่องจากพื้นที่สำเนาเงาเพิ่มขึ้นและลดประสิทธิภาพเมื่อเงื่อนไขต่อไปนี้เกิดขึ้น:

ขนาดบล็อกคำร้องขอย้ายมีค่าน้อยกว่าหรือเท่ากับ 16 KB

เดลต้าย้ายไม่ได้เพิ่มขึ้นทีละ 16 KB

Vista ของตัว defrag ไม่ได้ทำสิ่งนี้ :

การเปลี่ยนแปลงหนึ่งอย่างที่ไม่ชัดเจนต่อผู้ใช้คือการเพิ่มประสิทธิภาพของ Shadow Copy ในระหว่างการจัดเรียงข้อมูล Defrag มีฮิวริสติกพิเศษเพื่อย้ายบล็อกไฟล์ด้วยวิธีที่จะลดการใช้พื้นที่การทำสำเนาการเขียนและการเก็บสำเนาเงา หากไม่มีการปรับให้เหมาะสมนี้กระบวนการจัดเรียงข้อมูลจะช่วยเร่งการลบสำเนาเงาที่เก่ากว่า

— afrazier
แหล่งที่มา

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

— Slartibartfast

@Slartibartfast: มันเป็นปัญหาถ้าแอพเขียนไม่ถูกต้อง ฉันจะอัปเดตคำตอบพร้อมหลักฐานเพิ่มเติมตอนนี้ฉันไม่ได้ใช้โทรศัพท์ :-)

— afrazier

@afrazier - แม้ว่าฉันคิดว่าคำตอบที่อัพเดตของ ThouArtNotDoc เป็นคำตอบทั่วไปที่ดีกว่า ฉันต้องยอมรับว่าเงาสำเนาน่าจะมีบทบาทในสถานการณ์ของ OP ฉันพบสิ่งนี้เช่นกัน: "หากคุณวางแผนที่จะจัดเรียงข้อมูลวอลุ่มที่เปิดใช้งาน Shadow Copy ขอแนะนำให้คุณใช้ขนาดของคลัสเตอร์ (หรือหน่วยการจัดสรร) เป็น 16 KB หรือใหญ่กว่าหากคุณไม่เปลี่ยนแปลงจำนวนการเปลี่ยนแปลงที่เกิดขึ้น โดยกระบวนการจัดเรียงข้อมูลอาจทำให้สำเนาเงาถูกลบเร็วกว่าที่คาดไว้ " - MS: "การออกแบบ Shadow Copy กลยุทธ์" technet.microsoft.com/en-us/library/cc728305(WS.10).aspx

— Ƭᴇcʜιᴇ007

@afrazier: ยืนยันแล้ว จุดคืนค่าระบบก่อนหน้านี้ทั้งหมดหายไป ในการกำหนดค่าฉันมีการตั้งค่า 12% เป็นพื้นที่ว่างสูงสุดที่อนุญาตสำหรับ shadow copy ดังนั้น 10 GB จึงไม่มีเหตุผล ในทางตรงกันข้ามฉันเพิ่งติดตั้งเกมขนาด 9 GB ซึ่งสามารถเขียนทับจุดคืนค่าก่อนหน้าได้

— goweon

@firebat: พื้นที่ที่ใช้โดย System Restore ใช้สำหรับติดตามการเปลี่ยนแปลงของไฟล์ (snapshotted) ที่มีอยู่ไม่ใช่ไฟล์ใหม่ การติดตั้งเกมใหม่จะไม่ส่งผลกระทบต่อพื้นที่การคืนค่าระบบ แต่อาจมีการปะแก้ขนาดใหญ่

— afrazier

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

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

แต่เดี๋ยวก่อนฉันอาจจะผิด ...

แก้ไข: สนับสนุนข้อมูลจากที่นี่ :

เมื่อสตรีมข้อมูลที่ไม่ใช่ถิ่นที่อยู่มีการแยกส่วนมากเกินไปเพื่อให้แผนที่การจัดสรรที่มีประสิทธิภาพไม่สามารถบรรจุภายใน MFT ได้อย่างสมบูรณ์แผนที่การจัดสรรอาจถูกเก็บไว้เป็นสตรีมแบบไม่มีถิ่นที่อยู่อาศัยด้วยสตรีมอาศัยขนาดเล็กที่มีการจัดสรรทางอ้อม แผนที่ไปยังแผนที่การจัดสรร Non-resident ที่มีประสิทธิภาพของสตรีมข้อมูลที่ไม่ใช่ที่อยู่

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

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

— James T Snell
แหล่งที่มา

ป.ล. - ต้องมีการแยกส่วนง่าย ๆ

— James T Snell

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

— Kushal

Dunno, 10G ดูเหมือนมาก แต่ IME ดิสก์เต็มมากมีแนวโน้มที่จะ fragment มากมากขึ้นอย่างรวดเร็วกว่าดิสก์แยกส่วนน้อย ถ้าเขาอยู่ที่> 85% ก่อนหน้า (เนื่องจากเขาโพรบหมายถึง 85GiB แต่เป็นดิสก์ 100GB) และอาจเต็มในเวลาเดียวกันเขาอาจมีการแยกส่วนสูงตระหง่านและประสิทธิภาพการทำงานที่น่ากลัว

— Bernd Haug

ฉันจะไม่เชื่อในพื้นที่ 10GB ที่เพิ่มขึ้นเพียงแค่ไม่ติดตามชิ้นส่วน ด้วยขนาดบล็อก 4096k และสมมติว่าแต่ละแฟรกเมนต์ต้องใช้บล็อกเต็มเพื่อติดตาม (ซึ่งเป็นเท็จ) ซึ่งจะต้องมีการติดตามชิ้นส่วนเดิม2.5 ล้านชิ้น แต่ไม่ได้เพิ่มพื้นที่ว่างให้มากขึ้น

— CarlF

@Doc - ตัวชี้จะไม่ใช้ทั้งบล็อก หาก (เป็นไปได้) บล็อกการจัดสรรแต่ละบล็อกมีหลายเซกเตอร์คุณต้องมีพอยน์เตอร์น้อยลงเนื่องจากมีบล็อคที่จะติดตามข้อมูลของคุณน้อยลงดังนั้นค่าโสหุ้ยที่เป็นไปได้สูงสุดในการติดตามแฟรกเมนต์ทั้งหมดจะน้อยกว่า 3% ฉันไม่ทราบรายละเอียดที่แน่นอนของ NTFS แต่ด้วยระบบการจัดเก็บข้อมูล FAT (ไม่มีประสิทธิภาพ) คุณยังไม่สามารถรับค่าใช้จ่าย 10% สำหรับตารางการจัดสรรไฟล์ (ตัวชี้การติดตามชิ้นส่วน) ที่ FAT ตั้งชื่อตาม

— Steve314