كيفية تتبع نقل ملف عن بُعد يفشل عند نفس حجم الملف

إيفا وونغ

IceWhale author

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

How to Trace a Remote File Transfer That Fails at the Same File Size - Zima Store Online

عادةً ما يفشل النقل الذي يتوقف عند نفس عدد البايتات بشكل متكرر بسبب حد حتمي أو خطوة بعد النقل بدلاً من فقدان الحزم العشوائي.

بالنسبة لخدمة NAS عن بُعد أو خدمة ملفات مستضافة ذاتيًا، قد يكون نقطة الفشل المرئية ناتجة عن نظام الملفات الوجهة، المساحة الحرة أو تطبيق الحصة، حد تحميل التطبيق، وكيل عكسي، عداد عميل 32-بت، عمر اتصال ثابت، أو معالجة التحقق من الصحة بعد وصول الحمولة. أسرع تشخيص يسجل الإزاحة الدقيقة للبايت والوقت المنقضي، ثم يغير حجم الملف، معدل النقل، البروتوكول، والوجهة متغيرًا واحدًا في كل مرة.

سجل الإزاحة الدقيقة للبايت ومرحلة الفشل

قم بتشغيل نفس النقل مرتين وسجل حجم المصدر، البايتات المنقولة، النسبة المئوية، الوقت المنقضي، خطأ العميل، خطأ الخادم، وما إذا كان هناك ملف جزئي متبقٍ. ميز بين الفشل أثناء نقل الحمولة والفشل أثناء إعادة التسمية، التحقق من الصحة، الالتزام، الفهرسة، أو تأكيد API النهائي.

حالة دعم WinSCP فشلت مرارًا عند 4 جيجابايت حتى حدد المستخدم حد حجم ملف FAT32. كشف الحد الدقيق للبايت عن قيد تخزين بدلاً من مشكلة توجيه SFTP أو SCP.

إذا كان عدد البايتات متطابقًا ضمن هامش صغير، أعطِ الأولوية للحدود الثابتة والحدود الصحيحة. إذا كان الوقت المنقضي متطابقًا لكن عدد البايتات يتغير مع سرعة النقل، أعطِ الأولوية لانتهاء مهلة الاتصال، الوكيل، الخمول، أو المصادقة.

غيّر سرعة النقل لفصل الحجم عن الوقت

انقل نفس الملف مرة على المسار البعيد العادي ومرة عبر مسار أبطأ أو أسرع عمدًا. سجل ما إذا كان الفشل يتبع نفس عدد البايتات أو نفس المدة الزمنية.

وجد نقاش API الخاص بـ Dropbox أن الملفات التي تبدو وكأنها تفشل فوق 4 جيجابايت قد تعكس بدلاً من ذلك انتهاء مهلة طلب HTTP، واقترح التنزيلات الجزئية القائمة على النطاق لتجنب طلب طويل واحد.

عندما يتحرك عدد البايتات لكن الوقت المنقضي يظل ثابتًا، افحص عمر جلسة النفق، مهلة قراءة الوكيل، الرموز المنتهية الصلاحية، واكتشاف الخمول. عندما يبقى الفشل عند قيمة بايت واحدة دقيقة رغم تغير كبير في السرعة، استمر في فحص نظام الملفات، الحصة، العميل، وحدود التطبيق.

اختبر عدة ملفات حول الحد المشتبه به

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

وصف تقرير منتدى FlashFXP نقل FTP توقف عند 4.00 جيجابايت بالضبط. غالبًا ما تشير الحدود التي هي قوى اثنين مثل 2 جيجابايت، 4 جيجابايت، أو 8 جيجابايت إلى حد عداد، نظام ملفات، أو تطبيق.

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

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

افحص نظام الملفات الوجهة، الحصة، والمساحة المؤقتة

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

قد تقبل خدمة عن بُعد التدفق الكامل إلى موقع مؤقت وتفشل فقط عند نقل أو الالتزام بالملف. هذا ينتج عنه خطأ عميل بالقرب من 100 بالمئة رغم أن مسار الشبكة سلم تقريبًا كل البايتات.

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

تجاوز التطبيق، الوكيل، أو النفق طبقة واحدة في كل مرة

قارن سير العمل البعيد العادي مع اختبار بروتوكول مباشر: SFTP بدلاً من تحميل ويب، وصول VPN مباشر بدلاً من وكيل عكسي عام، أو نقل LAN محلي بدلاً من النفق البعيد. احتفظ بنفس تخزين المصدر والوجهة.

وجد مستخدم rclone أن التحميلات الكبيرة تعيد التشغيل مرارًا بعد توقف طويل حتى تغيير المهلة، بينما بدا أن الخادم يقوم بـ عمل تحقق من الصحة بعد التحميل. هذا يوضح لماذا الفشل في نهاية نفس الملف ليس دائمًا حدًا لعدد البايتات.

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

تحقق من الإصلاح باستخدام اختبارات الاستئناف والتحقق من الصحة

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

يوفر سير عمل ZimaSpace لـ تهيئة نقل NAS كبير طريقة أكثر أمانًا لإعادة الاختبار دون إعادة تشغيل مهمة متعددة التيرابايت من الصفر.

يكتمل التشخيص فقط عندما يتم تجاوز الحد القديم مرارًا، يلتزم الخادم بالملف، تتطابق التحقق من الصحة، وتحدد السجلات الطبقة المصححة. لا تقبل إعادة المحاولة التلقائية التي تخفي فشلًا حتميًا وتضيع النطاق الترددي بصمت.