بنية دليل ذاكرة التخزين المؤقت

Question

أنا بصدد تنفيذ التخزين المؤقت لمشروعي.بعد النظر في هياكل دليل ذاكرة التخزين المؤقت، رأيت العديد من الأمثلة مثل:

cache
cache/a
cache/a/a/
cache/a/...
cache/a/z
cache/...
cache/z
...

انت وجدت الفكرة.مثال آخر لتخزين الملفات، لنفترض أن الملف الخاص بنا يحمل اسمًا IMG_PARTY.JPG, ، الطريقة الشائعة هي وضعها في دليل باسم:

files/i/m/IMG_PARTY.JPG

تتبادر إلى ذهني بعض الأفكار، لكن أود أن أعرف الأسباب الحقيقية لذلك.

• تقوم أنظمة الملفات التي تقوم بعمليات بحث خطية بالعثور على الملفات بشكل أسرع عندما يكون هناك عدد أقل منها في الدليل.مثل هذا الهيكل ينشر الملفات بشكل رقيق.

• حتى لا تعبث بالمرافق * لا شىء مثل rm, ، والتي تأخذ عددًا محدودًا من الوسائط وحذف عدد كبير من الملفات مرة واحدة يميل إلى الاختراق (على الرغم من الاضطرار إلى تمريرها find إلخ.)

ما هو السبب الحقيقي؟ما هي بنية دليل ذاكرة التخزين المؤقت "الجيدة" ولماذا؟

Answer 1

في كل مرة كنت أفعل ذلك، كان ذلك لتجنب عمليات البحث الخطية البطيئة في أنظمة الملفات.لحسن الحظ، على الأقل في نظام Linux، أصبح هذا شيئًا من الماضي.

ومع ذلك، حتى اليوم، مع الأدلة المستندة إلى b-tree، سيكون من الصعب التعامل مع دليل كبير جدًا، نظرًا لأن الأمر سيستغرق وقتًا طويلاً ويومًا فقط للحصول على قائمة بجميع الملفات، ناهيك عن العثور على الملف الصحيح.

Answer 2

فقط استخدم التواريخ.منذ سوف تقوم بإزالة حسب التاريخ.:)

Answer 3

اذا فعلت ls -l, ، يجب أن تكون كافة الملفات stat()للحصول على التفاصيل، مما يضيف إلى حد كبير وقت القائمة - ويحدث هذا سواء كانت FS تستخدم بنيات مجزأة أو خطية.

لذلك، حتى لو كانت FS لديها القدرة على التعامل مع أحجام الدليل الكبيرة بشكل لا يصدق، فهناك أسباب وجيهة لعدم وجود هياكل مسطحة كبيرة (إنها أيضًا خنزير يجب نسخه احتياطيًا)

لقد قمت بقياس GFS2 (مجمع) مع 32000 ملف في دليل أو تم ترتيبها في بنية شجرة - كانت القوائم المتكررة أسرع بحوالي 300 مرة من الحصول على قائمة عندما كانت جميعها في بنية مسطحة (قد يستغرق الأمر ما يصل إلى 10 دقائق للحصول على قائمة) سرد الدليل)

أظهر EXT4 نسبًا مماثلة ولكن نظرًا لأن نقطة النهاية كانت بضع ثوانٍ فقط، فلن يلاحظها معظم الناس.