حلّ المجتمع

يبدو أن نسخ ZimaOS عبر NVMe محدود بسرعة 600 MB/s: اختبر التخزين باستخدام dd وfio ونفس مجموعة البيانات

A January 2026 community benchmarking guide arguing that a ~600 MB/s ZimaOS Files copy does not prove NVMe is limited to SATA speed. It recommends comparing the same workload through dd, fio, CLI copy, and GUI copy while watching CPU and I/O. The commands are community guidance, not IceWhale's official benchmark procedure.

لا يثبت عرض نسخ الملفات في ZimaOS بسرعة تقارب 600–650 ميغابايت/ثانية أن جهاز NVMe نفسه محدود بسرعة SATA. يفصل دليل المجتمع في المصدر، على نحو صحيح، بين معدل نقل التخزين الخام ومعدل نقل سير عمل نسخ الملفات. قد يضيف مدير ملفات يستند إلى المتصفح معالجةً للبيانات الوصفية، وتتبعًا للتقدم، ومنطقًا للسلامة، وعمليات نسخ في مساحة المستخدم، ونفقات عامة لنظام الملفات، وعمليات لكل ملف، وهي أمور لا يقيسها الاختبار المعياري المباشر.

النهج الأكثر فائدة هو المقارنة: اختبر وحدة التخزين نفسها باستخدام حمل إدخال/إخراج مباشر تسلسلي كبير، ثم انسخ الملف الكبير نفسه عبر سطر الأوامر و«الملفات». إذا بلغت الاختبارات الخام/المباشرة عدة غيغابايتات في الثانية بينما ظل النسخ عبر الواجهة الرسومية قريبًا من 600 ميغابايت/ثانية، فمن المرجح أن يكون عنق الزجاجة أعلى من جهاز NVMe.

رقم واحد لنسخ ملف ليس اختبارًا معياريًا لـ NVMe

تعتمد سرعة النسخ الداخلية على:

  • كون المصدر والوجهة على الجهاز نفسه أو على جهازين مختلفين؛
  • نوع نظام الملفات؛
  • سلوك النسخ عند الكتابة؛
  • حجم الملف وعدد الملفات؛
  • استهلاك وحدة المعالجة المركزية؛
  • ذاكرة الصفحات المؤقتة؛
  • تنفيذ النسخ.

قد تكون نتيجة تبلغ 600 ميغابايت/ثانية ممتازة لسير عمل واحد وضعيفة لسير عمل آخر.

ابدأ بملف اختبار تسلسلي كبير

تقلل الملفات الكبيرة من ضوضاء البيانات الوصفية، وتسهّل تفسير معدل النقل المستدام. استخدم المصدر ملفًا بحجم 10 غيغابايت كي يستمر الحمل مدة كافية للمراقبة.

قبل إنشاء ملف اختبار كبير، تحقّق من توفر مساحة فارغة كافية على وحدة التخزين المستهدفة. فقد يؤدي اختبار يملأ قرص النظام أو البيانات إلى عطل مختلف.

استخدم المصدر dd مع عمليات كتابة مباشرة

اقترح دليل المجتمع:

dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progress

oflag=direct يقلل تأثيرات ذاكرة الصفحات المؤقتة على مسار الكتابة. وهذا مفيد لإجراء فحص تقريبي للكتابة التسلسلية.

لا تفترض أن كل إصدار أو جهاز أو نظام ملفات يقبل حجم الكتلة نفسه أو يتعامل مع الإدخال/الإخراج المباشر بالطريقة نفسها.

كن أكثر حذرًا عند تفسير اختبار القراءة باستخدام dd في المصدر

ثم قرأ المصدر الملف إلى /dev/null. من دون خيار قراءة الإدخال/الإخراج المباشر أو التحكم في ذاكرة التخزين المؤقت، قد تُخدَم أجزاء من ملف حديث من ذاكرة الصفحات المؤقتة، مما يبالغ في سرعة القراءة الظاهرية.

لإجراء مقارنة موثوقة للتخزين، فضّل أداةً أو إعدادًا يستخدم الإدخال/الإخراج المباشر صراحةً في كلا الاتجاهين، أو تأكد من فهمك لتأثيرات التخزين المؤقت.

fio هو المعيار الأفضل والأكثر تحكمًا لاختبار التخزين

استخدم مثال الكتابة المستدامة في المصدر:

fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reporting

لا تزال هذه إرشادات من المجتمع، لكنها تتخذ شكلًا أوضح للاختبار المعياري: حجم اختبار محدد، وعمليات كتابة تسلسلية، وعمق قائمة انتظار، وإدخال/إخراج مباشر، ومدة تشغيل، ونتائج مجمّعة.

لا تُوجّه مهمة fio مدمّرة إلى جهاز خام يحتوي على بيانات فعلية. استخدم ملف اختبار مؤقتًا على نظام ملفات، ما لم تكن تفهم العواقب تمامًا.

قارن بين واجهة المستخدم الرسومية وسطر الأوامر باستخدام مجموعة البيانات نفسها

أقوى نصيحة منهجية في المصدر هي استخدام الملف الكبير نفسه لكليهما:

  • نسخة عبر سطر الأوامر؛
  • نسخة عبر «ملفات ZimaOS».

إذا كانت مجموعة البيانات والمصدر والوجهة ونظام الملفات متطابقة، فإن الفرق يعكس خط أنابيب النسخ بصورة أكثر مباشرة.

قد تكون الملفات الصغيرة أبطأ بكثير

تتطلب آلاف الصور أو ملفات المشاريع أو الصور المصغرة أو إدخالات AppData عمليات فتح/إنشاء/بيانات وصفية/تحقق من المجموع الاختباري بصورة متكررة. وقد ينخفض معدل النقل الإجمالي كثيرًا عن معدل نقل فيلم واحد كبير أو ملف ISO، حتى مع استخدام وحدة NVMe سريعة جدًا.

يمكن أن يضيف النسخ عند الكتابة في Btrfs وسلوك البيانات الوصفية مزيدًا من الحمل، اعتمادًا على العملية المحددة.

راقب استخدام المعالج والإدخال/الإخراج أثناء تشغيل النسخ البطيء

يوصي المصدر بمراقبة استخدام القرص والمعالج في الوقت نفسه. والهدف هو تحديد ما إذا كان:

  • القرص مشبع؛
  • تشكّل نواة واحدة من المعالج عنق الزجاجة؛
  • تتنافس عملية أخرى على عمليات الإدخال/الإخراج؛
  • ينتظر خط أنابيب النسخ بدلًا من تشغيل وحدة التخزين بكامل طاقتها.

هذا أكثر إفادة من ذكر رقم شريط التقدم في «الملفات» وحده.

تعتمد سرعة NVMe أيضًا على مسارات PCIe والجهاز

حتى وحدة NVMe السليمة قد تعمل بأقل من الرقم التسويقي لها إذا:

  • المنفذ يستخدم PCIe x1/x2 بدلًا من x4؛
  • المنصة تستخدم PCIe Gen 3 بدلًا من Gen 4؛
  • تتعرض وحدة SSD للاختناق الحراري؛
  • تتشارك وحدة التحكم المسارات؛
  • تنفد ذاكرة SLC المؤقتة أثناء عمليات الكتابة المستمرة.

ينبغي مقارنة الاختبار الحقيقي بطوبولوجيا العتاد، لا بتوقع عام من نوع «NVMe = ‏7 جيجابايت/ثانية».

تفصل أدلة النقل الحالية من IceWhale أيضًا بين مسارات واجهة المستخدم ومسارات النقل الأسرع

لطالما أظهر دليل IceWhale الخاص بـ ZimaCube وThunderbolt أن مسار النقل عبر واجهة مستخدم ZimaOS يعمل بسرعة أقل من مسار Samba/Thunderbolt المباشر، مما يعزز الفكرة العامة بأن واجهة الملفات ليست مطابقة لإنتاجية التخزين الخام أو إنتاجية الشبكة.

استخدم قائمة التحقق الحالية لاستكشاف مشكلات النقل في ZimaOS وإصلاحها لإجراء الفحوصات المدعومة من جانب الشبكة.

احذف ملفات الاختبار عند الانتهاء

كبير dd/fio يمكن للملفات أن تستهلك عشرات الجيجابايت بسرعة. احذف ملفات الاختبار المعروفة بعد تسجيل النتائج، وتحقق من المساحة الحرة بعد ذلك.

الأسئلة الشائعة حول اختبار أداء NVMe

هل تثبت سرعة 600 ميجابايت/ثانية في «ملفات ZimaOS» أن وحدة NVMe محدودة بسرعة SATA؟

لا. فهو يقيس سير عمل النسخ هذا، وليس الإمكانات الخام لوحدة NVMe.

لماذا قد تبدو قراءة dd سريعة بشكل غير واقعي؟

قد يُخدَم الملف المكتوب حديثًا جزئيًا من ذاكرة التخزين المؤقت للصفحات، ما لم يتجنب اختبار القراءة التخزين المؤقت صراحةً.

ما أفضل مقارنة لخط أنابيب النسخ عبر واجهة المستخدم الرسومية؟

استخدم نفس المصدر/الوجهة ونفس مجموعة البيانات الكبيرة في كلٍّ من واجهة سطر الأوامر و«الملفات»، ثم قارن بينهما مع مراقبة استخدام المعالج وإدخال/إخراج وحدة التخزين.