ประสิทธิภาพ NTFS ไม่ดี

เหตุใดประสิทธิภาพของระบบไฟล์ NTFS จึงค่อนข้างแย่เมื่อเทียบกับ Linux / ext3 บ่อยครั้งที่ฉันเห็นสิ่งนี้เมื่อตรวจสอบต้นไม้ต้นกำเนิด (ขนาดใหญ่) จากการโค่นล้ม การชำระเงินใช้เวลาประมาณ 10-15 นาทีสำหรับ NTFS ในขณะที่การชำระเงินที่สอดคล้องกันบน Linux (บนฮาร์ดแวร์ที่เกือบเหมือนกัน) ทำให้ลำดับความสำคัญเร็วขึ้น (1 - 1.5 นาที)

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

แก้ไข: นี่ไม่ได้หมายความว่าเป็นคำถามการอักเสบ "NTFS เมื่อเทียบกับ ext3"; ฉันสนใจอย่างแท้จริงว่าเหตุใด NTFS จึงทำงานได้ไม่ดีในบางกรณี มันเป็นแค่การออกแบบที่ไม่ดี (ซึ่งฉันสงสัย) หรือมีประเด็นอื่น ๆ ที่เข้ามาเล่น

NTFS มีสิ่งนี้เรียกว่าตารางแฟ้มต้นแบบ ฟังดูเจ๋งจริงๆเมื่อคุณอ่าน

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

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

ใน ext2 และ 3 โดยคมชัดบล็อกไฟล์สำหรับทุกไฟล์จะถูกเก็บไว้ถัดจากที่เมตาดาต้าของไดเรกทอรีสำหรับไดเรกทอรีที่พวกเขาอยู่ใน (ถ้าเป็นไปได้ถ้าดิสก์ของคุณจะถูกจัดเรียงและคุณมีพื้นที่ว่างประมาณ 20%) ซึ่งหมายความว่าเมื่อ svn กำลังเปิดไดเรกทอรีจำนวนบล็อกจะถูกแคชโดยทั่วไปในแคช 16mb นั้นบนไดรฟ์ของคุณและจากนั้นอีกครั้งในแคชของเคอร์เนล ไฟล์เหล่านั้นอาจรวมถึงไฟล์. svn และไฟล์การแก้ไขสำหรับการอัปเดตครั้งล่าสุดของคุณ สิ่งนี้มีประโยชน์เนื่องจากไฟล์เหล่านั้นมีแนวโน้มที่ไฟล์ svn บางส่วนจะดูที่ถัดไป NTFS ไม่ได้ทำเช่นนี้ถึงแม้ว่าส่วนใหญ่ของ MFT ควรจะถูกแคชในระบบพวกเขาอาจไม่ได้เป็นส่วนที่คุณต้องการต่อไป

ปัญหาเฉพาะของคุณก็เพราะ

1. การโค่นล้มเองนั้นมาจากโลกของ UNIX ดังนั้นเวอร์ชั่น Windows จึงถือว่ามีคุณสมบัติด้านประสิทธิภาพที่คล้ายคลึงกัน
2. ประสิทธิภาพของระบบไฟล์ NTFS นั้นยอดเยี่ยมมากเพราะมีไฟล์ขนาดเล็ก

สิ่งที่คุณเห็นคือสิ่งประดิษฐ์ของสิ่งที่ออกแบบมาสำหรับระบบปฏิบัติการเฉพาะโดยมีสมมติฐานด้านประสิทธิภาพของระบบปฏิบัติการนั้น สิ่งนี้มักจะพังทลายลงอย่างไม่ดีเมื่อนำไปใช้กับระบบอื่น ตัวอย่างอื่น ๆ จะฟอร์กกับเธรด บน UNIX-like วิธีดั้งเดิมของการ parallizing บางสิ่งบางอย่างเพียงเพื่อวางไข่กระบวนการอื่น บน Windows ที่กระบวนการใช้เวลาเริ่มต้นอย่างน้อยห้าครั้งจึงเป็นความคิดที่ไม่ดี

โดยทั่วไปแล้วคุณไม่สามารถใช้สิ่งประดิษฐ์ใด ๆ ของระบบปฏิบัติการเฉพาะเพื่อให้กับอีกอันที่มีสถาปัตยกรรมที่แตกต่างกันอย่างมากมาย อย่าลืมว่า NTFS มีคุณสมบัติของระบบไฟล์มากมายที่ไม่ได้ใช้ในระบบไฟล์ UNIX ที่ใช้กันอย่างแพร่หลาย ณ จุดนั้นเช่น journaling และ ACL สิ่งเหล่านั้นมาในราคา

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

หมายเหตุด้านข้าง:การอัปเดตครั้งเดียวของที่เก็บ SVN ขนาดใหญ่ที่ฉันใช้อยู่นั้นมีการใช้งานไฟล์ประมาณ 250,000 ไฟล์ เสียงเล็ก ๆ บอกฉันว่ามันเป็นจริงสำหรับ 24 ไฟล์ที่เปลี่ยน ...

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