الدليل الأقوى في سلسلة النقاش هذه ليس لقطة شاشة «الملفات» التي تُظهر سرعة 600 ميجابايت/ثانية، بل اختبار التخزين المباشر اللاحق. فقد قاس أحد المستخدمين، بينما ظلت سرعة النسخ عبر واجهة ZimaOS WebUI في حدود 600–650 ميجابايت/ثانية، عمليات كتابة مباشرة بسرعة تقارب 2.3 جيجابايت/ثانية باستخدام dd، وعمليات كتابة بسرعة نحو 2.2 جيجابايت/ثانية باستخدام fio. وهذا يستبعد تفسيرًا شاملًا لنظام التشغيل مفاده أن «سرعة NVMe محدودة بسرعة SATA III» على ذلك الجهاز.
والاستنتاج الأكثر تحفظًا هو أن الرقم البطيء كان مرتبطًا بسير عمل النسخ الداخلي في «الملفات»، أو بتأثيرات أحمال النسخ مثل البيانات الوصفية، وBtrfs CoW، والتخزين المؤقت، أو حدود التنفيذ بخيط واحد، وليس بمسار NVMe الفعلي نفسه.
المصدر أعاد إنتاج الحد عبر عدة مسارات للنسخ
أفاد Dave بسلوك مشابه عبر عمليات النسخ من NVMe واحد إلى NVMe آخر، ومن NVMe إلى RAID0، ومن RAID0 إلى NVMe واحد، وعبر مسارات 10GbE. وقال مستخدم آخر لاحقًا إن النسخ عبر SMB من Windows إلى ZimaOS يمكن أن يصل إلى السرعة الكاملة لـ10GbE، بينما ظل النسخ الداخلي في «الملفات» عند نحو 650 ميجابايت/ثانية.
بلغت عمليات الكتابة المباشرة باستخدام dd نحو 2.3 جيجابايت/ثانية
استخدم المصدر الأمر dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progress، ونشر نتيجة قريبة من 2.3 جيجابايت/ثانية، وهي أعلى بكثير من معدل النقل العملي لـSATA III.
بلغت fio أيضًا نحو 2.2 جيجابايت/ثانية
أظهر تشغيل fio في المصدر عمليات كتابة بسرعة تقارب 2163 ميبيبايت/ثانية / 2268 ميجابايت/ثانية. ورغم أن محرك التنفيذ المتزامن المحدد حدّ فعليًا من عمق قائمة الانتظار إلى واحد، فقد أثبتت النتيجة مع ذلك أن مكدس التخزين يستطيع تجاوز رقم نسخ «الملفات» بعدة أضعاف.
تعامل بحذر مع رقم القراءة باستخدام dd الوارد في المصدر
قاس المصدر أيضًا سرعة قراءة تقارب 3.0 جيجابايت/ثانية عند قراءة ملف الاختبار المكتوب حديثًا إلى /dev/null. ونظرًا إلى أن هذه القراءة لم تستخدم صراحةً الإدخال والإخراج المباشر أو تفريغ ذاكرة الصفحات، فقد يؤثر التخزين المؤقت في الرقم.
انخفاض استخدام المعالج الإجمالي لا يستبعد وجود اختناق في خيط واحد
يمكن لمسار نسخ في مساحة المستخدم أن يستنفد نواة واحدة، بينما يظل استخدام المعالج الإجمالي متواضعًا على نظام متعدد الأنوية. راقب استخدام المعالج لكل خيط واستخدام القرص أثناء عملية النسخ البطيئة في «الملفات».
قارن الملف الكبير نفسه بين سطر الأوامر و«الملفات»
استخدم المصدر والوجهة وملف الاختبار الكبير نفسه لعمليات النسخ عبر «الملفات» وسطر الأوامر، ثم قارن النتائج باختبار إدخال وإخراج مباشر مؤقت. وبهذا تفصل بين الحمل الزائد للنسخ في الواجهة أو الخلفية وبين قدرة الجهاز الخام.
يمكن لعدد الملفات والبيانات الوصفية في Btrfs تغيير سرعة النسخ الفعلية
تتطلب آلاف الملفات الصغيرة عمليات متكررة على البيانات الوصفية، كما يمكن لسلوك النسخ عند الكتابة في Btrfs أن يغير تكلفة النسخ الداخلي.
لا تسمِّ هذا اختناقًا شاملًا حاليًا في ZimaOS
يقدم المصدر دليلًا قويًا على وجود اختناق تاريخي في «الملفات» أو النسخ الداخلي على عدة أنظمة. لكنه لا يثبت أن ZimaOS 1.7.1 الحالي لا يزال يفرض السقف نفسه تمامًا على كل مجموعة من العتاد ونظام الملفات.
يمكن للنسخ الداخلي أن يقرأ ويكتب وحدة التخزين نفسها في الوقت ذاته
إذا كان المصدر والوجهة على NVMe فعلي واحد أو في مجموعة RAID واحدة، فيتعين على القرص تنفيذ عمليات القراءة والكتابة في الوقت نفسه. لذلك لا تكون سرعة النسخ الظاهرة قابلة للمقارنة مع اختبار كتابة تسلسلية أحادي الاتجاه.
سجّل أجهزة المصدر والوجهة الفعلية قبل مقارنة النتائج. فعبارة «نسخ داخلي» تصف مسار البرنامج، ولا تعني بالضرورة وجود قرصَي SSD مستقلين.
تحقق من عرض جسر PCIe وتوليده قبل مقارنة الأرقام التسويقية
قد يتقيد NVMe عالي الأداء بوصلة PCIe x1/x2، أو بتوليد أقدم، أو بمشاركة مسارات الشرائح، أو بكون فتحة المنصة موصّلة بطريقة تختلف عن حجم موصلها الفعلي. ويستبعد وصول اختبار خام إلى أكثر من 2 جيجابايت/ثانية وجود سقف قدره 600 ميجابايت/ثانية، لكنه قد يظل أقل من الحد الأقصى المعلن لقرص SSD المكتبي لأسباب مشروعة تتعلق بالبنية.
يمكن للنسخ المستمر أن يفعّل حدود الحرارة أو ذاكرة SLC المؤقتة في SSD
تتعامل الاختبارات القصيرة وعمليات نسخ الملفات الطويلة مع أقراص SSD بطرق مختلفة. فقد يبدأ القرص بسرعة عالية جدًا ثم ينخفض أداؤه بعد امتلاء ذاكرة pseudo-SLC المؤقتة أو ارتفاع درجة الحرارة. راقب درجة حرارة NVMe ومعدل النقل المستمر خلال فترة طويلة بما يكفي قبل عزو كل انخفاض إلى «الملفات».
يمكن لذاكرة الصفحات أن تجعل بعض الاختبارات تبدو أسرع من الجهاز
تُعد نتيجة الكتابة المباشرة في المصدر دليلًا قويًا لأنها استخدمت الإدخال والإخراج المباشر. أما اختبارات القراءة التي تُجرى مباشرة بعد الكتابة فقد تتأثر بذاكرة النظام المؤقتة ما لم يتجاوزها الاختبار صراحةً.
ولإجراء مقارنات قابلة للتكرار، استخدم إعدادًا للاختبار يوضح ما إذا كان الإدخال والإخراج المباشر مفعّلًا، واجعل حجم ملف الاختبار كبيرًا بما يكفي لتقليل تشويه الذاكرة المؤقتة.
أعد اختبار مسار «الملفات» الحالي قبل اعتبار 600 ميجابايت/ثانية حدًا ثابتًا للمنتج
تمتد سلسلة النقاش عبر إصدارات ZimaOS التي سبقت الإصدار الحالي. فإذا بدا أن «الملفات» لا تزال محدودة السرعة اليوم، فأعد إنتاج المشكلة باستخدام الملف الكبير نفسه، والمصدر والوجهة نفسيهما، ومقارنة حالية مع سطر الأوامر أو الإدخال والإخراج المباشر. فهذا ينتج دليلًا قابلًا للتنفيذ بدلًا من الاستمرار إلى ما لا نهاية في اعتماد سقف رقمي قديم.
الأسئلة الشائعة حول سرعة NVMe
هل أثبت المصدر أن ZimaOS يحد سرعة NVMe إلى سرعة SATA؟
لا. فقد تجاوزت عمليات الكتابة المباشرة باستخدام dd وfio سرعة 2 جيجابايت/ثانية على النظام نفسه.
إلى ماذا أشار المصدر بقوة أكبر؟
إلى مسار النسخ الداخلي في WebUI أو مدير الملفات، أو إلى الحمل الزائد الناتج عن عبء العمل، وليس إلى جهاز NVMe نفسه.
هل ينبغي اعتبار نتيجة قراءة dd بعد الكتابة مباشرةً سرعة القرص الخالصة؟
ليس بالضرورة. فمن دون استخدام قراءة مباشرة أو التحكم في التخزين المؤقت، يمكن لذاكرة الصفحات المؤقتة أن تؤثر في النتيجة.
