
F*ck file system - أداة بحث عن الملفات من سطر الأوامر تتجاوز نواة نظام التشغيل وتقرأ القرص الخاص بك مباشرة
هذه أداة سطر أوامر للبحث في الملفات (مثل grep) لا تستخدم نواة نظام التشغيل لقراءة الملفات، بل تقرأ أقراصك مباشرة. إنها عديمة الفائدة عمليًا، ولكنها رائعة بشكل جنوني.
هذا مجرد ~1.5k سطر من كود C يقوم بـ:
/dev/rdisk*)؛ البحث في ملف صورة لا يحتاج إلى صلاحيات مرتفعةsync يدوي)ولكن في نفس الوقت
read()، بدلاً من ذلك يقوم بـ pread على جهاز الكتلة مباشرةللبحث السريع الفعلي عن الملفات، اطلع على مشروعي fff - فهو يتفوق بشكل كبير على ripgrep دون الحاجة إلى sudo.
على لينكس، معظم أنظمة الملفات سهلة التنفيذ
هذا هو أسهل نظام ملفات للدعم: إنه نظام ملفات يسجل (journaling) يكتب في المكان (لا نسخ عند الكتابة)، لذا في معظم الأوقات هذا هو أفضل نظام ملفات لـ ffs. أحيانًا قد ترى أن ffs لا يمكنه رؤية بعض التحديثات الحديثة للملفات، قد يحدث هذا إذا كانت النواة تحتجز التحديثات الحديثة في الذاكرة المؤقتة وتؤجل الكتابة إلى القرص. يمكنك فرض المزامنة باستخدام
sync
نظام الملفات B-tree أكثر تعقيدًا بشكل كبير، وهو تخزين ملفات أكثر كفاءة ويأتي مع قيد إضافي:
عند تحديث أي ملف على نظام الملفات الخاص بك، يتطلب superblock بأكمله تحديثًا أيضًا، مما يعني أنه إذا قرأ ffs الـ superblock (شجرة b عالية المستوى) وبعد ذلك قامت النواة بتحديث الشجرة - تصبح القراءة بأكملها غير صالحة.
يمكن تجاوز ذلك باستخدام fsfreeze أو عن طريق إنشاء وحدة تخزين منفصلة غير مثبتة
APFS هو نظام ملفات مملوك لشركة Apple تم هندسته عكسيًا وهو مدعوم أيضًا هنا، لكن Apple زادت بشكل كبير من سياساتها الأمنية.
لن تتمكن من تشغيل ffs على القرص الرئيسي دون تعطيل SIP
SIP - حماية سلامة النظام هي ميزة أمان خاصة تمنع أي وصول إلى superblock القرص الرئيسي حتى كمستخدم جذر. لا يمكنك تجاوزها حتى مع sudo؛ يجب عليك تعطيل هذه الميزة (قد تكون معطلة بالفعل إذا كنت تستخدم مشاريع مثل yabai).
هناك طريقة لاختبار ffs على نظام ملفات Apple دون لمس القرص الرئيسي - يمكنك البحث في ملفات .dmg الخام دون أي صلاحيات مرتفعة (نعم، مثبتات التطبيقات هي مجرد وحدات تخزين غير مثبتة). باستخدام ffs لا تحتاج إلى تثبيت أي شيء، يمكنك فقط إعطائه مسارًا إلى البايتات الخام لوحدة تخزين مع نوع نظام الملفات:
ffs "<QUERY>" /path/to/volume.dmg apfs
لأن ffs يقرأ البايتات مباشرة، يمكنك استخدامه للبحث في أي وحدات تخزين غير مثبتة دون تثبيتها على نظام الملفات. على سبيل المثال، قراءة ملفات .iso أو .dmg.
هذا هو الجزء الأطرف - ffs ليس لديه إمكانية الوصول إلى ذاكرة التخزين المؤقت لنظام الملفات VFS / kernel. لهذا السبب سيكون أبطأ في الدلائل الصغيرة (أو المخزنة مؤقتًا بالفعل)، ولكن أسرع تدريجيًا بمجرد استنفاد الذاكرة المؤقتة واضطرار النواة للذهاب وقراءة حالة القرص الفعلية.
لماذا؟ بالضبط لإثبات أن VFS kernel يصبح في مرحلة ما عبئًا إضافيًا.
هذه نتيجة مقارنة البحث بين ffs و ripgrep على محرك مثبت بنظام btrfs. لاحظ أن ripgrep يستخدم مطابقًا ومتجولًا في الملفات قائمًا على SIMD أكثر تقدمًا، بينما ffs هو مجرد ~1.8k سطر من كود C.
[repos — 631k files]
ffs |#### | 5.505s
rg |### | 4.813s
[dev — 1.50M files]
ffs |############ | 18.413s
rg |################# | 25.673s
[home — 3.25M files]
ffs |######################## | 36.205s
rg |##################################################| 74.690s
الأعلام المستخدمة لـ ripgrep هي -F --no-heading -H -n --no-ignore --hidden --one-file-system --no-messages - مما يجعله يصدر نفس نتائج ffs.
كل ما تحتاجه لتجميع المشروع هو libzstd لـ btrfs، و openmp في pkg-config الخاص بك ثم ببساطة
make ffs
ffs --help