ฉันสามารถใส่แฟ้มลงในไดเรกทอรีได้กี่ไฟล์


561

มันสำคัญแค่ไหนที่ฉันเก็บไฟล์ไว้ในไดเรกทอรีเดียว? ถ้าเป็นเช่นนั้นมีกี่ไฟล์ในไดเรกทอรีที่มีมากเกินไปและสิ่งที่มีผลกระทบของการมีไฟล์มากเกินไป? (นี่เป็นเซิร์ฟเวอร์ Linux)

พื้นหลัง: ฉันมีเว็บไซต์อัลบั้มรูปภาพและทุกภาพที่อัปโหลดจะถูกเปลี่ยนชื่อเป็นรหัส 8 หลักฐานสิบหก (พูด, a58f375c.jpg) นี่คือเพื่อหลีกเลี่ยงข้อขัดแย้งของชื่อไฟล์ (หากอัปโหลดไฟล์จำนวนมาก "IMG0001.JPG") ชื่อไฟล์ดั้งเดิมและข้อมูลเมตาที่มีประโยชน์ใด ๆ จะถูกเก็บไว้ในฐานข้อมูล ตอนนี้ฉันมีไฟล์ประมาณ 1500 ไฟล์ในไดเรกทอรีรูปภาพ สิ่งนี้ทำให้การแสดงรายการไฟล์ในไดเรกทอรี (ผ่าน FTP หรือไคลเอนต์ SSH) ใช้เวลาไม่กี่วินาที แต่ฉันไม่เห็นว่ามันจะมีผลกระทบอะไรนอกจากนั้น โดยเฉพาะอย่างยิ่งดูเหมือนจะไม่มีผลกระทบใด ๆ กับความเร็วของไฟล์รูปภาพที่ถูกส่งไปยังผู้ใช้

ฉันคิดเกี่ยวกับการลดจำนวนภาพโดยทำไดเรกทอรีย่อย 16 รายการ: 0-9 และ af จากนั้นฉันจะย้ายรูปภาพไปยังไดเรกทอรีย่อยโดยยึดตามหลักฐานสิบหกแรกของชื่อไฟล์ แต่ฉันไม่แน่ใจว่ามีเหตุผลใดที่จะต้องทำเช่นนั้นยกเว้นการแสดงรายการไดเรกทอรีเป็นครั้งคราวผ่าน FTP / SSH

คำตอบ:


736

FAT32 :

  • จำนวนไฟล์สูงสุด: 268,173,300
  • จำนวนไฟล์สูงสุดต่อไดเรกทอรี: 2 16  - 1 (65,535)
  • ขนาดไฟล์สูงสุด: 2 GiB - 1 โดยไม่มีLFS , 4 GiB - 1 พร้อม

NTFS :

  • จำนวนไฟล์สูงสุด: 2 32  - 1 (4,294,967,295)
  • ขนาดไฟล์สูงสุด
    • การติดตั้ง: 2 44  - 2 6ไบต์ (16 TiB - 64 KiB)
    • ตามทฤษฎี: 2 64  - 2 6ไบต์ (16 EiB - 64 KiB)
  • ขนาดเสียงสูงสุด
    • การใช้งาน: 2 32  - 1 กลุ่ม (256 TiB - 64 KiB)
    • ตามทฤษฎี: 2 64  - 1 กลุ่ม (1 YiB - 64 KiB)

ext2 :

  • จำนวนไฟล์สูงสุด: 10 18
  • จำนวนไฟล์สูงสุดต่อไดเรกทอรี: ~ 1.3 × 10 20 (ปัญหาประสิทธิภาพเกิน 10,000)
  • ขนาดไฟล์สูงสุด
    • 16 GiB (ขนาดบล็อก 1 KiB)
    • 256 GiB (ขนาดบล็อก 2 KiB)
    • 2 TiB (ขนาดบล็อก 4 KiB)
    • 2 TiB (ขนาดบล็อก 8 KiB)
  • ขนาดเสียงสูงสุด
    • 4 TiB (ขนาดบล็อก 1 KiB)
    • 8 TiB (ขนาดบล็อก 2 KiB)
    • 16 TiB (ขนาดบล็อก 4 KiB)
    • 32 TiB (ขนาดบล็อก 8 KiB)

ext3 :

  • จำนวนไฟล์สูงสุด: min (volumeSize / 2 13 , numberOfBlocks)
  • ขนาดไฟล์สูงสุด: เหมือนกับ ext2
  • ขนาดปริมาตรสูงสุด: เหมือนกับ ext2

ext4 :

  • จำนวนไฟล์สูงสุด: 2 32  - 1 (4,294,967,295)
  • จำนวนไฟล์สูงสุดต่อไดเรกทอรี: ไม่ จำกัด
  • ขนาดไฟล์สูงสุด: 2 44  - 1 ไบต์ (16 TiB - 1)
  • ขนาดปริมาณสูงสุด: 2 48  - 1 ไบต์ (256 TiB - 1)

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

19
เนื่องจากเราอยู่ในปี 2012 ตอนนี้ฉันคิดว่าถึงเวลาที่ต้องชี้แจงว่า ext4 ไม่มีข้อ จำกัด เกี่ยวกับจำนวนไดเรกทอรีย่อย ขนาดไฟล์สูงสุดยังเพิ่มขึ้นถึง 16 TB นอกจากนี้ขนาดโดยรวมของระบบไฟล์อาจสูงถึง 1 EB = 1,048,576 TB
devsnd

7
เห็นได้ชัดว่า ext3 ยังมีขีด จำกัด 60,000 ไฟล์ (หรือไดเรกทอรีหรือลิงค์) ต่อไดเรกทอรี ฉันพบวิธีที่ยากเกี่ยวกับเรื่องนี้
ซ้อน

8
คำตอบเก่า ๆ ฉันรู้… แต่เมื่อคุณเขียนEXT4 - จำนวนไฟล์สูงสุด: 2³² - 1 (4,294,967,295)และจำนวนไฟล์สูงสุดต่อไดเรกทอรี: ไม่ จำกัดคุณสับสนจริงๆเพราะ2³² - 1! =“ ไม่ จำกัด ” ฉันเดาว่าฉันต้องการกาแฟตอนนี้ ;) อย่างไรก็ตาม +1
e-sushi

11
ขีด จำกัด ของระบบไฟล์อย่างหนักไม่ตอบคำถาม " มันสำคัญแค่ไหนที่ฉันเก็บไฟล์ไว้ในไดเรกทอรีเดียว? "
Etki

191

ฉันมีมากกว่า 8 ล้านไฟล์ในไดเรกทอรี ext3 เดียว libc readdir()ซึ่งถูกใช้โดยfind, lsและส่วนใหญ่ของวิธีการอื่น ๆ ที่กล่าวถึงในหัวข้อนี้ไปยังรายการไดเรกทอรีที่มีขนาดใหญ่

เหตุผลlsและfindช้าในกรณีนี้คือการreaddir()อ่านรายการไดเรกทอรีในเวลา 32K เท่านั้นดังนั้นบนดิสก์ที่ช้าก็จะต้องมีหลายคนอ่านรายการไดเรกทอรี มีวิธีแก้ไขปัญหาความเร็วนี้ ฉันเขียนบทความเกี่ยวกับเรื่องนี้อย่างละเอียดที่: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- LS /

กุญแจนำออกไปคือ: ใช้getdents()โดยตรง - http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.htmlมากกว่าสิ่งที่อยู่บนพื้นฐานของ libc readdir()เพื่อให้คุณสามารถระบุบัฟเฟอร์ ขนาดเมื่ออ่านรายการไดเรกทอรีจากดิสก์


6
อ่านแล้วน่าสนใจ! ฉันสามารถถามในสถานการณ์ที่คุณมี 8 ล้านไฟล์ในไดเรกทอรีเดียวได้ไหม ฮ่าฮ่า
Aᴄʜᴇʀᴏɴғᴀɪʟ

ฉันมีเหมือนกัน ฉันได้ย้ายคอลัมน์ Blob ของตารางแล้วแต่ละคอลัมน์ Blob ที่ฉันส่งออกเป็นไฟล์ มันเป็นประมาณ 8 ล้านไฟล์ :)
เข็ม

65

ฉันมีไดเรกทอรีที่มีไฟล์ 88,914 ไฟล์อยู่ในนั้น เช่นเดียวกับตัวคุณเองนี่ใช้สำหรับจัดเก็บภาพขนาดย่อและบนเซิร์ฟเวอร์ Linux

ไฟล์ที่แสดงรายการผ่าน FTP หรือฟังก์ชั่น php นั้นช้าใช่ แต่ก็ยังมีประสิทธิภาพในการแสดงไฟล์ เช่น www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg มีเวลารอ 200-400 มิลลิวินาที เมื่อเปรียบเทียบกับเว็บไซต์อื่นฉันมีไฟล์ประมาณ 100 ไฟล์ในไดเรกทอรีภาพจะปรากฏหลังจากรอประมาณ 40ms

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


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

1
มันจะมีประโยชน์ในการติดตั้งไดรฟ์ด้วย noatime เช่นกัน: howtoforge.com/และอ่านสิ่งนี้เช่นกัน: serverfault.com/questions/354017//
mgutt

2
คุณใช้ระบบไฟล์อะไรในเวลาที่มันช้ามาก? ตัวอย่างเช่น XFS ควรสามารถจัดการไฟล์ 100,000 ไฟล์ในไดเรกทอรีได้อย่างง่ายดายโดยไม่ชะลอตัวลงอย่างเห็นได้ชัด
อีธาน

1
ขัดแย้งกับความเห็นของคนอื่น ๆ ส่วนใหญ่ฉันต้องการยืนยันคำตอบนี้ เรามีภาพหลายแสนภาพในเว็บไซต์เครือข่ายสังคมของเรา เพื่อปรับปรุงประสิทธิภาพเราถูกบังคับให้มี 100 (หรือ 1,000 ไฟล์สำหรับบางไฟล์) และแจกจ่ายไฟล์ไปยังพวกเขา (ext3 บน linux + Apache สำหรับเรา)
wmac

57

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

ดังนั้นความเร็วไม่ควรเป็นปัญหานอกเหนือจากที่คุณจดบันทึกไว้ซึ่งรายชื่อนั้นจะใช้เวลานานกว่า

มีการ จำกัด จำนวนไฟล์ทั้งหมดในหนึ่งไดเรกทอรี ฉันดูเหมือนจะจำได้ว่ามันทำงานได้ถึง 32000 ไฟล์แน่นอน


4
Gnome และ KDE โหลดไดเรกทอรีขนาดใหญ่อย่างช้าๆ windows จะแคชไดเรกทอรีเพื่อให้เหมาะสม ฉันรัก Linux แต่ kde และ gnome เขียนได้ไม่ดี
rook

1
และ ext4 นั้นดูเหมือนจะมีค่าเท่ากับ dir_index เป็นค่าเริ่มต้น
ศ. Falken ผิดสัญญา

22
มีข้อ จำกัด ของไดเรกทอรีย่อยประมาณ 32K ในหนึ่งไดเรกทอรีใน ext3 แต่ OP กำลังพูดถึงไฟล์ภาพ ไม่มีข้อ จำกัด (ในทางปฏิบัติ?) สำหรับไฟล์ในระบบไฟล์ ext3 ที่เปิดใช้งานดัชนี Dir
Peter N Lewis

1
คำตอบนี้ล้าสมัยในปัจจุบันเริ่มต้นคือ ext4
บอริส

1
"ไม่มีข้อ จำกัด (ในทางปฏิบัติ?) สำหรับไฟล์ในระบบไฟล์ ext3 ที่เปิดใช้งาน Dir Index" - ฉันเพิ่งใช้พื้นที่ไฟล์ในไดเรกทอรีบนระบบไฟล์ 4TB ext4 ที่dir_indexเปิดใช้งาน ฉันมีประมาณ 17 ล้านไฟล์ในไดเรกทอรี คำตอบคือการเปิดlarge_dirกับ tune2fs
lunixbochs

49

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

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

หรือ

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

33
@Steve ใช้ find (1) และ / หรือ xargs (1) สำหรับกรณีเหล่านี้ ด้วยเหตุผลเดียวกันเป็นความคิดที่ดีที่จะใช้เครื่องมือดังกล่าวในสคริปต์แทนการขยายบรรทัดคำสั่ง
Dave C

3
@Steve คุณเห็นประสิทธิภาพลดลงหรือไม่เมื่อจำนวนไฟล์ในโฟลเดอร์เพิ่มขึ้น หรือไม่มีความสัมพันธ์?
Pacerier

6
นี่เป็นจุดที่ดี แต่สำหรับ nitpick เหตุผลที่ให้นั้นผิด รายการอาร์กิวเมนต์ยาวเกินไปเป็นข้อ จำกัด ไม่ของเปลือก แต่ระบบexecการดำเนินงาน โดยทั่วไปแล้วเชลล์สามารถขยาย wildcard ได้ - มันเป็นการเรียกไปยังexecอาร์กิวเมนต์หลายตัวที่ส่งกลับข้อผิดพลาด
jw013

เมื่อคืนฉันมีข้อผิดพลาดเดียวกัน (Fedora 15) กับ "rm" (somefiles *) ที่มีประมาณ 400,000 ไฟล์ในไดเรกทอรี ฉันสามารถตัดไฟล์เก่าด้วย "ค้นหา" จนถึงจุดที่ฉันสามารถ "rm" ด้วยสัญลักษณ์แทน
PJ Brunet

10.000.000 ไฟล์ไปยังไดเรกทอรีใน etx4 ทำงานได้ดี ประสิทธิภาพการทำงานไม่มากเมื่อเข้าถึง แต่ค่อนข้างช้าด้วยไวด์การ์ด ระวังเมื่อใช้โปรแกรมเชลล์ที่ชอบเรียงชื่อไฟล์! :)
Simon Rigét

25

ฉันกำลังทำงานกับปัญหาที่คล้ายกันในขณะนี้ เรามีโครงสร้างไดเรกทอรีลำดับชั้นและใช้รหัสรูปภาพเป็นชื่อไฟล์ ตัวอย่างเช่นภาพที่มีid=1234567อยู่ใน

..../45/67/1234567_<...>.jpg

ใช้ตัวเลข 4 ตัวสุดท้ายเพื่อกำหนดว่าไฟล์จะไปที่ใด

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


1
นี่เป็นทางออกที่ดีงาม ทุกระดับของไดเรกทอรีของคุณลงไปที่ไฟล์จะมีมากที่สุด 100 รายการในนั้นถ้าคุณติดกับการแบ่ง 2 หลักและไดเรกทอรีด้านล่างส่วนใหญ่จะมี 1 ไฟล์
RobKohr

การใช้งาน PHP: stackoverflow.com/a/29707920/318765
mgutt

21

สำหรับสิ่งที่คุ้มค่าฉันเพิ่งสร้างไดเรกทอรีในext4ระบบไฟล์ที่มี 1,000,000 ไฟล์ในนั้นจากนั้นสุ่มเข้าถึงไฟล์เหล่านั้นผ่านเว็บเซิร์ฟเวอร์ ฉันไม่ได้สังเกตเห็นพรีเมี่ยมใด ๆ ในการเข้าถึงไฟล์เหล่านั้น (พูด) มีเพียง 10 ไฟล์เท่านั้น

สิ่งนี้แตกต่างอย่างสิ้นเชิงกับประสบการณ์ของฉันเมื่อntfsไม่กี่ปีที่ผ่านมา


ไฟล์ประเภทใด ข้อความหรือรูปภาพฉันอยู่ใน ext4 และต้องนำเข้า 80000 ภาพในไดเรกทอรีเดียวภายใต้ wordpress และต้องการทราบว่ามันจะโอเคไหม
Yvon Huynh

1
@YvonHuynh: ประเภทของไฟล์ไม่เกี่ยวข้องอย่างสมบูรณ์ ค่าใช้จ่ายในไดเรกทอรีของรายการ / ติดตามไฟล์เหมือนกันโดยไม่คำนึงถึง
TJ Crowder

14

ปัญหาที่ใหญ่ที่สุดที่ฉันพบคือในระบบ 32 บิต เมื่อคุณผ่านหมายเลขที่กำหนดเครื่องมือเช่น 'ls' จะหยุดทำงาน

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


9

ฉันมีปัญหาเดียวกัน พยายามจัดเก็บไฟล์หลายล้านไฟล์ในเซิร์ฟเวอร์ Ubuntu ใน ext4 สิ้นสุดการใช้งานการวัดประสิทธิภาพของฉันเอง พบว่าไดเรกทอรีแบนทำงานได้ดีขึ้นในขณะที่ใช้งานง่ายกว่า:

มาตรฐาน

เขียนบทความ


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

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

7

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

ตัวอย่างเช่น F-Spot เก็บไฟล์ภาพถ่ายเป็น YYYY \ MM \ DD \ filename.ext ซึ่งหมายถึงไดเรกทอรีที่ใหญ่ที่สุดที่ฉันต้องจัดการด้วยในขณะที่จัดการกับคอลเลกชันภาพถ่ายของฉัน ~ 20000 ด้วยตนเองคือประมาณ 800 ไฟล์ นอกจากนี้ยังทำให้สามารถเรียกดูไฟล์ได้ง่ายขึ้นจากแอปพลิเคชันบุคคลที่สาม อย่าสันนิษฐานว่าซอฟต์แวร์ของคุณเป็นสิ่งเดียวที่จะเข้าถึงไฟล์ซอฟต์แวร์ของคุณ


6
ฉันโฆษณากับการแบ่งพาร์ติชันตามวันที่เพราะการนำเข้าจำนวนมากอาจทำคลัสเตอร์ไฟล์ในบางวัน
สูงสุด

จุดที่ดี คุณควรพิจารณาถึงกรณีการใช้งานของคุณก่อนที่จะเลือกโครงร่างการแบ่ง ฉันบังเอิญนำเข้ารูปภาพเป็นเวลาหลายวันโดยมีการกระจายค่อนข้างกว้างและเมื่อฉันต้องการจัดการภาพถ่ายนอกวันที่ F-Spot เป็นวิธีที่ง่ายที่สุดในการค้นหาพวกเขาดังนั้นมันจึงเป็นการชนะสองครั้งสำหรับฉัน
Sparr

7

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

แม้ว่าระบบไฟล์จะไม่ถูกต้องก็ยังเป็นไปได้อย่างแน่นอนสำหรับโปรแกรมที่แสดงรายการเนื้อหาไดเรกทอรีให้เลอะและเรียงลำดับ O (n ^ 2) เพื่อให้อยู่ในด้านที่ปลอดภัยฉันจะ จำกัด จำนวนไฟล์ต่อ ไดเรกทอรีไม่เกิน 500


7

มันขึ้นอยู่กับระบบไฟล์ที่ใช้และธงบางตัว

ตัวอย่างเช่นext3สามารถมีไฟล์ได้หลายพันไฟล์ แต่หลังจากสองสามพันมันเคยช้ามาก ส่วนใหญ่เมื่อรายชื่อไดเรกทอรี แต่เมื่อเปิดไฟล์เดียว ไม่กี่ปีที่ผ่านมาได้รับตัวเลือก 'htree' ซึ่งสั้นลงอย่างมากเวลาที่จำเป็นในการรับ inode ที่มีชื่อไฟล์

ส่วนตัวผมใช้ไดเรกทอรีย่อยเพื่อรักษาระดับส่วนใหญ่ภายใต้รายการหนึ่งพันหรือมากกว่านั้น ในกรณีของคุณฉันจะสร้าง 256 ไดเรกทอรีโดยมีเลขฐานสิบหกสองหลักสุดท้ายของ ID ใช้ตัวเลขสุดท้ายและไม่ใช่ตัวเลขแรกดังนั้นคุณจะได้รับการโหลดที่สมดุล


6
หากชื่อไฟล์นั้นสุ่มสมบูรณ์มันจะไม่สำคัญว่าจะใช้ตัวเลขใด
แปลกหน้า

อันที่จริงชื่อไฟล์เหล่านี้ถูกสร้างแบบสุ่ม
กีบ

2
หรือใช้ N ไบต์แรกของไฟล์ย่อย SHA-1 ของชื่อไฟล์
gawi

6

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

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

เมื่อไม่นานมานี้ฉันถูกกัดโดยระบบไฟล์ที่จัดรูปแบบด้วยบล็อก 2K ซึ่งอธิบายข้อความเคอร์เนลไดเรกทอรีแบบเต็มอย่างไม่น่าเชื่อwarning: ext3_dx_add_entry: Directory index full!เมื่อฉันคัดลอกจากระบบไฟล์ ext3 อื่น ในกรณีของฉันไดเรกทอรีที่มีไฟล์เพียง 480,000 ไฟล์ไม่สามารถคัดลอกไปยังปลายทางได้


5

คำถามเกิดขึ้นกับสิ่งที่คุณจะทำกับไฟล์

ใน Windows ไดเรกทอรีใด ๆ ที่มีไฟล์มากกว่า 2k มักจะเปิดช้าสำหรับฉันใน Explorer หากเป็นไฟล์รูปภาพทั้งหมดมากกว่า 1k มักจะเปิดช้ามากในมุมมองรูปขนาดย่อ

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


5

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

ในสภาพแวดล้อมปัจจุบันเรามีกลุ่มของฮาร์ดแวร์และซอฟต์แวร์ที่แตกต่างกันมาก - บางส่วนเป็น 32 บิตบางคนเป็น 64 บิตบางคนทันสมัยและบางคนพยายามและเป็นจริง - เชื่อถือได้และไม่เคยเปลี่ยน เพิ่มเข้าไปที่นั่นคือฮาร์ดแวร์ที่เก่ากว่าและใหม่กว่า OS ที่เก่ากว่าและใหม่กว่าผู้จำหน่ายที่แตกต่างกัน (Windows, Unixes, Apple, ฯลฯ ) และสาธารณูปโภคและเซิร์ฟเวอร์มากมายที่เข้ากันได้ เนื่องจากฮาร์ดแวร์ได้รับการปรับปรุงและซอฟต์แวร์ได้รับการแปลงเป็นความเข้ากันได้ 64 บิตจึงมีความล่าช้าอย่างมากในการทำให้ชิ้นส่วนทั้งหมดของโลกที่มีขนาดใหญ่และซับซ้อนนี้เล่นได้อย่างรวดเร็วพร้อมกับการเปลี่ยนแปลงที่รวดเร็ว

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

ตัวอย่างเช่นฉันมีเซิร์ฟเวอร์สื่อที่มีไฟล์ขนาดใหญ่มาก ผลลัพธ์มีเพียง 400 ไฟล์ที่บรรจุไดรฟ์ 3 TB ใช้ไอโหนดเพียง 1% แต่ใช้พื้นที่ทั้งหมด 95% บางคนที่มีไฟล์ขนาดเล็กจำนวนมากอาจหมด inode ก่อนที่จะเข้ามาเติมเต็มพื้นที่ (บนระบบไฟล์ ext4 ตามกฎของหัวแม่มือจะใช้ 1 inode สำหรับแต่ละไฟล์ / ไดเรกทอรี) ในขณะที่ในทางทฤษฎีจำนวนไฟล์ทั้งหมดที่อาจมีอยู่ในไดเรกทอรีนั้นแทบจะไม่มีที่สิ้นสุด เพียงแค่ความสามารถของระบบไฟล์

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


4

ฉันจำได้ว่ารันโปรแกรมที่สร้างไฟล์จำนวนมากที่เอาท์พุท ไฟล์ถูกเรียงลำดับที่ 30000 ต่อไดเรกทอรี ฉันจำไม่ได้ว่ามีปัญหาการอ่านใด ๆ เมื่อฉันต้องใช้ผลลัพธ์ที่ผลิตซ้ำ มันอยู่ในแล็ปท็อป Ubuntu Linux แบบ 32 บิตและแม้กระทั่งNautilusก็ยังแสดงเนื้อหาของไดเรกทอรีแม้หลังจากนั้นไม่กี่วินาที

ระบบไฟล์ ext3: โค้ดที่คล้ายกันในระบบ 64 บิตสามารถทำงานได้ดีกับ 64000 ไฟล์ต่อไดเรกทอรี


4

"ขึ้นอยู่กับระบบไฟล์"
ผู้ใช้บางคนกล่าวว่าผลกระทบต่อประสิทธิภาพขึ้นอยู่กับระบบไฟล์ที่ใช้ แน่นอน. ระบบไฟล์เช่น EXT3 อาจช้ามาก แต่แม้ว่าคุณจะใช้ EXT4 หรือ XFS คุณไม่สามารถป้องกันรายการโฟลเดอร์ผ่านlsหรือfindหรือผ่านการเชื่อมต่อภายนอกเช่น FTP จะช้าลงช้าลง

วิธีการแก้ปัญหา
ผมชอบแบบเดียวกับ@armandino เพื่อที่ฉันจะใช้ฟังก์ชั่นเล็ก ๆ น้อย ๆ ใน PHP เพื่อแปลง ID เป็น filepath ที่ให้ผลลัพธ์ 1,000 ไฟล์ต่อไดเรกทอรี:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

หรือคุณสามารถใช้รุ่นที่สองหากคุณต้องการใช้ตัวอักษรและตัวเลข:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

ผล:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

อย่างที่คุณเห็นสำหรับ$int-version ทุก ๆ โฟลเดอร์มีไฟล์มากถึง 1,000 ไฟล์และมากถึง 99 ไดเรกทอรีที่มีไฟล์ 1000 ไฟล์และ 99 ไดเรกทอรี ...

แต่อย่าลืมว่าหลายไดเรกทอรีทำให้เกิดปัญหาประสิทธิภาพเดียวกัน!

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


3

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


3

ฉันพบปัญหาที่คล้ายกัน ฉันพยายามเข้าถึงไดเรกทอรีที่มีมากกว่า 10,000 ไฟล์อยู่ในนั้น ใช้เวลานานเกินไปในการสร้างรายการไฟล์และเรียกใช้คำสั่งประเภทใด ๆ กับไฟล์ใด ๆ

ฉันคิด php script เล็กน้อยเพื่อทำสิ่งนี้เพื่อตัวเองและพยายามหาวิธีที่จะป้องกันไม่ให้เบราว์เซอร์หมดเวลา

ต่อไปนี้เป็นสคริปต์ PHP ที่ฉันเขียนเพื่อแก้ไขปัญหา

รายการไฟล์ใน Directory ที่มีไฟล์มากเกินไปสำหรับ FTP

มันช่วยคนได้อย่างไร


1

ไม่ใช่คำตอบ แต่เป็นเพียงคำแนะนำ

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

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

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

เพื่อเอาชนะขีด จำกัด ของฮาร์ดแวร์คุณสามารถใช้ RAID-0


1

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.