เหตุใดจึงมีความแตกต่างอย่างมากระหว่าง“ ขนาด” และ“ ขนาดบนดิสก์”

302

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

สกรีนช็อตแสดงไฟล์ 50,875 ไฟล์ใน 1,504 โฟลเดอร์ 105 MB เป็นดิสก์ 1.43 GB

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

BTW โฟลเดอร์นี้อยู่ในการ์ด SD ของโทรศัพท์ Android ของฉัน ภายในแอพนี้แผนที่ของฉันเก็บแผนที่ที่เก็บไว้ในแคชและแอพจะได้รับแผนที่จาก Google Maps

filesystems

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

10

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

— CVn

1

@ MichaelKjörling Heh ฉันเพียงแค่การแก้ไขในการสนทนาเล็ก ๆ น้อย ๆ เกี่ยวกับการกระจายตัว (ได้ฟุ้งซ่านบิตก่อนหน้านี้)

— บ๊อบ

21

@ MichaelKjörling อย่าแก้ไขคำถามย้อนหลังเพื่อให้พอดีกับคำตอบ คำตอบอย่างใดอย่างหนึ่งที่อยู่ส่วนการกระจายตัวของคำถามของ OP การแก้ไขของคุณจะต้องย้อนกลับเพื่อหลีกเลี่ยงความสับสน

— DanteTheEgregore

5

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

— CVn

11

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

— A. Donda

303

^{ฉันจะสมมติว่าคุณกำลังใช้ระบบไฟล์ FAT / FAT32 ที่นี่เนื่องจากคุณพูดถึงว่านี่เป็นการ์ด SD NTFS และ exFAT ทำตัวคล้ายกับหน่วยการจัดสรร ระบบไฟล์อื่นอาจแตกต่างออกไป แต่ไม่รองรับ Windows}

หากคุณมีไฟล์ขนาดเล็กจำนวนมากเป็นไปได้อย่างแน่นอน พิจารณาสิ่งนี้:

50,000 ไฟล์
ขนาดคลัสเตอร์ 32 kB (หน่วยการจัดสรร) ซึ่งเป็นค่าสูงสุดสำหรับ FAT32

ตกลงตอนนี้พื้นที่ต่ำสุดที่ใช้คือ 50,000 * 32,000 = 1.6 GB (ใช้ส่วนนำหน้าของ SI ไม่ใช่เลขฐานสองเพื่อทำให้คณิตศาสตร์ง่ายขึ้น) พื้นที่ที่แต่ละไฟล์ใช้ในดิสก์นั้นมีขนาดหน่วยการจัดสรรหลายเท่าเสมอและที่นี่เราสมมติว่าแต่ละไฟล์นั้นมีขนาดเล็กพอที่จะใส่ในหน่วยเดียวโดยมีพื้นที่เหลือ (เปล่า) เหลืออยู่

หากไฟล์แต่ละไฟล์มีค่าเฉลี่ย 2 kB คุณจะได้รับผลรวมประมาณ 100 MB - แต่คุณต้องเสีย 15x (30 kB ต่อไฟล์) โดยเฉลี่ยเนื่องจากขนาดหน่วยการจัดสรร

คำอธิบายในเชิงลึก

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

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

ทำไมขนาดหน่วยการจัดสรรแตกต่างกัน มันจะเป็นการแลกเปลี่ยนกันระหว่างการมีตารางที่ใหญ่กว่า (สมุดที่อยู่เช่นบอกว่า John เป็นเจ้าของบ้านที่ 123 Fake Street, 124 Fake Street, 666 Satan Lane, ฯลฯ ) หรือเนื้อที่ที่สูญเปล่าในแต่ละยูนิต (บ้าน) หากคุณมีไฟล์ที่มีขนาดใหญ่ขึ้นจะเหมาะสมกว่าที่จะใช้หน่วยการจัดสรรที่ใหญ่กว่า - เนื่องจากไฟล์ไม่ได้รับหน่วยใหม่ (เฮ้าส์) จนกว่าจะเต็มหน่วยอื่น ๆ ทั้งหมด หากคุณมีไฟล์ขนาดเล็กจำนวนมากเอาล่ะคุณจะต้องมีโต๊ะขนาดใหญ่ (สมุดที่อยู่) อยู่แล้วดังนั้นอาจให้หน่วยเล็ก ๆ (บ้าน) ด้วย

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

การกระจายตัว?

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

การแก้ปัญหาที่เป็นไปได้

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

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

— ผมบ๊อบ
แหล่งที่มา

3

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

— ฮอบส์

3

(โดยทางเทคนิคแล้วมันเรียกว่า "หย่อน")

— hobbs

1

ขนาดคลัสเตอร์ยัง จำกัด ขนาดระบบไฟล์สูงสุด ตัวอย่างเช่นหากพื้นที่ที่อยู่ของคุณเป็น 32 บิตคุณจะมีกลุ่มรวมที่เป็นไปได้ ~ 4.29 พันล้าน ตอนนี้ถ้าคุณใช้ขนาดคลัสเตอร์ที่เล็กที่สุดที่สนับสนุนโดย NTFS (512 ไบต์) คุณสามารถกำหนดที่อยู่ได้สูงสุด 512 * 2 ^ 32 ไบต์ = 2 GiB ถ้าคุณต้องการไดรฟ์ข้อมูลที่สามารถเก็บข้อมูลได้มากกว่า 2 GiB คุณต้องเพิ่มขนาดของคลัสเตอร์ ทั้งหมดนี้เป็นอิสระจากไฟล์ที่ใหญ่ที่สุดที่คุณพยายามจัดเก็บโดยที่คุณไม่สามารถจัดเก็บไฟล์ที่มีขนาดใหญ่กว่า 2 GiB ซึ่งเป็นปัญหาที่น้อยที่สุดของคุณ

— Andon M. Coleman

4 กลุ่ม KiB จะอนุญาตให้คุณจัดการไฟล์ในระดับเสียงที่มีขนาดใหญ่ถึง 16 TiB ซึ่งน่าจะเพียงพอสำหรับอนาคตอันใกล้นี้

— Andon M. Coleman

1

เขาสามารถบีบอัดไฟล์ขนาดเล็กลงในไฟล์ขนาดใหญ่ไฟล์เดียว

— einpoklum

45

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

ภายในแอพนี้แผนที่ของฉันเก็บแผนที่ที่เก็บไว้ในแคชและแอพจะได้รับแผนที่จาก Google Maps

บางทีคุณควรพูดคุยกับผู้พัฒนาเพื่อใช้การเก็บถาวรหรือฐานข้อมูลแทนหลายไฟล์ นี่อาจจะช่วยให้ดิสก์มีการกระจายตัวน้อยลงและจะประหยัดพื้นที่โดยเฉพาะอย่างยิ่งถ้าเป็นแฟลชไดรฟ์ NAND หากคุณอธิบายสถานการณ์ที่ไร้สาระซึ่งข้อมูล 100MB / ข้อมูลที่เป็นประโยชน์กลายเป็น 1.4GiB มีบางอย่างผิดปกติกับวิธีการจัดเก็บข้อมูลและนักพัฒนาควรนำโซลูชันที่ดีกว่ามาใช้

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

1

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

— Bob

1

@Bob ดังนั้นการแก้ปัญหาควรมาจากนักพัฒนาด้าน D:

— Braiam

4

นั่นเป็นความจริงโดยสิ้นเชิง ฉันคิดว่าในเวลานี้ฉันควรเปลี่ยนแอพของฉัน

— vfsoraki

17

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

— bcrist

1

เป็นความจริงอย่างแน่นอน ..... +1

— arundevma

25

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

สิ่งนี้ใช้ได้กับ NTFS เท่านั้นกับความรู้ของฉัน โฆษณาเป็นที่รู้จักสำหรับการใช้ที่ถูกต้องและไม่ถูกต้องตามกฎหมาย:

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

โฆษณาอย่างง่าย: ไฟล์ NTFS ใด ๆ สามารถเก็บสตรีมข้อมูลได้หลายรายการ (เข้าใจ "ไฟล์ย่อย") หนึ่งคือกระแสหลักที่ใช้โดย Windows Explorer และเครื่องมือ Windows อื่น ๆ มันเก็บเนื้อหาปกติของไฟล์ กระแสข้อมูลอื่นอาจมีข้อมูลอื่นเช่นเดียวกับกระแสหลัก แต่ไม่สามารถจัดการได้โดยตรงโดยเครื่องมือ Windows (โดยเฉพาะ Explorer จะแสดงขนาดไฟล์เท่ากับขนาดของกระแสหลักโดยไม่คำนึงถึงขนาดของโฆษณา) คุณต้องใช้เครื่องมือหรือรหัสพิเศษในการเขียนอ่านและค้นหาโฆษณา

ประเด็นหลักคือในกรณีที่สังเกตเห็นความแตกต่างของไฟล์ขนาดใหญ่อย่ามองข้ามความเป็นไปได้ของโฆษณาและมัลแวร์ที่ซ่อนอยู่

ลิงค์อื่น

หากต้องการทดสอบโฆษณาอย่างปลอดภัยให้ลองที่ระดับ DOS / CMD ...

สร้างและแสดงเนื้อหาของไฟล์ในรูทของ C:

C:\> echo The main data stream> test.txt
C:\> type test.txt

ผลลัพธ์:

C:\> The main data stream

ตอนนี้เพิ่มโฆษณาด้วยวิธีเดียวกันเพียงระบุชื่อโฆษณานอกเหนือจากชื่อไฟล์:

C:\> echo The secret message> test.txt:secret

คุณเพิ่งซ่อนข้อความลับในไฟล์ โปรดทราบว่าขนาดไฟล์ใน Explorer ไม่ได้เปลี่ยนแปลงทั้ง ๆ ที่เราเพิ่มไบต์ในโฆษณา "ความลับ"

ลองแสดงเนื้อหาโฆษณา:

C:\> type test.txt:secret

ผลลัพธ์:

The filename, directory name, or volume label syntax is incorrect.

CMD typeไม่สามารถแสดงเนื้อหาของโฆษณา เราจะใช้ Notepad แทน:

notepad test.txt:secret

ใน Notepad เราสามารถดูเนื้อหาของโฆษณา:

The secret message

นอกจากนี้คุณยังสามารถซ่อนไฟล์ปฏิบัติการเต็มรูปแบบในโฆษณาของไฟล์ข้อความที่ไร้เดียงสาและรันได้ตลอดเวลา ความมั่งคั่งไม่เป็นอันตรายต่อแฮกเกอร์ :-)

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

ฉันไม่ใช่คนแบบตัวเองงานของฉันส่วนใหญ่ทำใน Linux มันมีประโยชน์มาก ขอบคุณ

— vfsoraki

4

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

— adric

19

ปัญหาอาจเกิดจากขนาดของคลัสเตอร์

ตามที่Microsoft :

หากคุณไม่ได้ใช้การบีบอัด NTFS สำหรับไฟล์หรือโฟลเดอร์ใด ๆ ที่มีอยู่ในไดรฟ์ความแตกต่างระหว่าง SIZE และ SIZE ON DISK จะเป็นการสิ้นเปลืองเนื้อที่เนื่องจากขนาดของคลัสเตอร์ที่ใหญ่กว่าที่จำเป็น คุณควรพยายามใช้ขนาดคลัสเตอร์ที่ดีที่สุดเพื่อให้ค่า SIZE ON DISK ใกล้เคียงกับค่า SIZE มากที่สุด ความคลาดเคลื่อนที่มากเกินไประหว่าง SIZE ON DISK และค่า SIZE เป็นข้อบ่งชี้ว่าขนาดคลัสเตอร์เริ่มต้นใหญ่เกินไปสำหรับขนาดไฟล์เฉลี่ยที่คุณเก็บไว้ในไดรฟ์ข้อมูลและควรลดลง สิ่งนี้สามารถทำได้โดยการสำรองวอลุ่มจากนั้นทำการฟอร์แมตโวลุ่มโดยใช้คำสั่ง format และสวิตช์ / a เพื่อระบุขนาดการจัดสรรที่เหมาะสม: IE: format D: /a:2048 (ตัวอย่างนี้ใช้ขนาดคลัสเตอร์ 2-KB)

ลองฟอร์แมตไดรฟ์ของคุณด้วยขนาดคลัสเตอร์ที่เล็กลง

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

4

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

— Ruslan

2

หากต้องการเพิ่มสิ่งที่ @Ruslan กล่าวขณะนี้ฮาร์ดไดรฟ์ที่ใหม่กว่ามีขนาดเซกเตอร์ 4 kB และจะเป็นการดีที่สุดที่จะจัดระบบไฟล์ให้กับเซกเตอร์กายภาพและมีขนาดเซกเตอร์กายภาพเป็นขนาดหน่วยการจัดสรร

— Bob

1

@ รุสลันฉันเชื่อว่าคุณควรจะบอกว่ามันควรจะเป็นพลังของสองเท่า 4096 12288 (3 × 4096) และ 20480 (5 × 4096) ไม่ใช่ตัวเลือกที่ดี

— สกอตต์

9

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

คุณไม่สามารถเปลี่ยนขนาดคลัสเตอร์ของ NAND ได้ (เป็นคุณสมบัติทางกายภาพของฮาร์ดแวร์การ์ด SD ของคุณ)

ขั้นแรกให้รัน scandisk / chkdsk บนการ์ด SD ของคุณเพื่อให้แน่ใจว่าปัญหาการรายงานขนาดไม่ได้อยู่ในระบบไฟล์ที่เสียหาย

ประการที่สองฉันขอแนะนำให้คุณรายงานข้อผิดพลาดไปยัง Google Map devs เพื่อให้พวกเขาเป็นผู้ตำหนิที่นี่ พวกเขาควรจะใช้วิธีการจัดเก็บที่เหนือกว่า การแก้ไขควรทำให้แอปพลิเคชันทำงานได้เร็วขึ้นในอุปกรณ์จำนวนมากเนื่องจาก I / O น้อยลงและกิจกรรมไดรเวอร์ของระบบไฟล์

— Matias N Goldberg
แหล่งที่มา

จริงๆแล้วมันไม่ใช่ Google Maps แต่เป็นแอพอื่นที่ใช้ Google Maps ฉันแจ้งผู้พัฒนาและเพิ่งลบไฟล์เหล่านั้นออกจาก SD ของฉัน

— vfsoraki

7

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

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

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

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

ดังนั้นในกรณีนี้เอกสารหน้าหนึ่งของฉันจะยังคงครอบครองกล่องเดียวโดยไม่มีการแบ่งปันอะไรอีกเลย

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

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

6

นอกเหนือจากขนาดคลัสเตอร์คุณยังสามารถมีความคลาดเคลื่อนเนื่องจากเงื่อนไขต่อไปนี้:

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

— Archimedes Trajano
แหล่งที่มา

โดยทั่วไปนั่นอาจเป็นจริง แต่ในกรณีของฉันหน่วยการจัดสรรสูงเป็นปัญหา

— vfsoraki

3

ใช่ฉันแค่พยายามเพิ่มคำตอบโดยให้เหตุผลที่เป็นไปได้มากกว่าสำหรับความคลาดเคลื่อน

— Archimedes Trajano

6

คุณควรดูรายการ Block Suballocation ใน Wikipedia นั่นคือสิ่งที่เกิดขึ้นกับคุณ การใช้ระบบไฟล์ด้วยการสนับสนุน Tail Packaging เป็นโซลูชันระดับระบบไฟล์สำหรับปัญหานี้นอกเหนือจากการเปลี่ยนขนาดคลัสเตอร์การจัดสรร

ทุกคนมีความไม่สะดวกที่จำเป็นต้องฟอร์แมตดิสก์ใหม่

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

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

http://en.wikipedia.org/wiki/Tail_packing

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

0

ฉันสังเกตเห็นความแตกต่างของขนาดไฟล์ใหญ่ใน Windows 10 ในแต่ละไฟล์ แต่ถ้าฉันดูที่คุณสมบัติของไฟล์ SAME จากตำแหน่งเดียวกัน (ไดรฟ์เครือข่าย) ด้วย Windows XP ความคลาดเคลื่อนขนาดใหญ่ไม่ได้อยู่ที่นั่น แตกต่างกันเล็กน้อยซึ่งเป็นสิ่งที่คุณคาดหวัง ฉันคิดว่ามีข้อผิดพลาดใน Windows 10 ไฟล์ที่มีขนาด 449MB อาจไม่ถึง 3.99GB ซึ่งเป็นสิ่งที่ Windows 10 บอกฉัน

— เดวิดฮัทชินส์
แหล่งที่มา

1

เพียงแค่ FYI คำถามไม่มีส่วนเกี่ยวข้องกับ Windows 10 OP คือการใช้ windows 7

— TheKB