لماذا يكون تشغيل npm install بطيئًا على محرك Windows الخاص بي في WSL؟

تُنشئ مديرات الحزم مثل npm أو pip آلاف الملفات الصغيرة أثناء التثبيت. وعندما تُكتب هذه الملفات عبر حدود نظامي التشغيل إلى محرك Windows بنظام NTFS، يتحمل كل ملف على حدة تكلفة ترجمة إضافية، مما يسبب اختناقات أداء كبيرة.

أداء نظام ملفات WSL: لماذا يُبطئ الوصول عبر حدود نظامي التشغيل الكود لديك

Q: أين ينبغي أن أخزّن ملفات مشروعي عند استخدام WSL؟

ينبغي تخزين ملفات مشروعك داخل نظام ملفات Linux الأصلي (مثل مجلد المستخدم الرئيسي، على سبيل المثال ~/my-project) بدلًا من محركات Windows المركّبة (مثل /mnt/c/)، لضمان أقصى سرعات القراءة والكتابة.

Q: هل يمكنني استخدام Visual Studio Code لتحرير الملفات المخزّنة داخل نظام ملفات Linux؟

نعم. فبتثبيت الإضافة Remote - WSL في Visual Studio Code، يمكنك فتح الملفات الموجودة داخل توزيعة Linux الخاصة بـ WSL وتحريرها وتصحيح أخطائها مباشرةً، مع الاستمرار في استخدام واجهة المحرر القياسية في Windows.

Q: ما الفرق بين طريقة تعامل Windows وLinux مع أسماء الملفات؟

أنظمة ملفات Linux حساسة لحالة الأحرف بصرامة (فتعامل File.txt وfile.txt على أنهما ملفان مختلفان)، في حين أن نظام NTFS في Windows غير حساس لحالة الأحرف افتراضيًا. وغالبًا ما يؤدي تشغيل أدوات Linux على المجلدات المستضافة في Windows إلى فشل عمليات البناء بسبب هذه الفروق السلوكية الجوهرية.

By Mirko Peters · 2026-10-27

اكتشف لماذا يُبطئ الوصول إلى الملفات عبر نظامي التشغيل أداء WSL، واطّلع على أفضل الممارسات لتخزين الملفات على نظام Linux الأصلي وتسريع سير عمل التطوير لديك.

Automatically translated with AI from the original post. Read the English original

Cover: Windows Subsystem for Linux (WSL) - Simply Explained

اكتشف لماذا يؤدي الجمع بين نظامي ملفات Windows وLinux داخل نظام Windows الفرعي لـ Linux (WSL) إلى اختناقات أداء كبيرة. تعرّف على القواعد الأساسية للإبقاء على مجلدات مشاريعك في الجانب الصحيح من حدود نظام التشغيل، لتسريع مهام البناء الكثيفة على القرص وتثبيت الحزم وعمليات git بشكل ملحوظ.

النقاط الرئيسية

يؤدي تخزين ملفات مشاريع Linux على محركات Windows (عبر /mnt/c/) إلى تدهور حاد في الأداء بسبب تكاليف الترجمة عبر الحدود.
تتأثر أشجار الملفات الضخمة، مثل مجلدات node_modules، أكثر من غيرها عند عبور حدود نظام التشغيل أثناء عمليات البناء والتحديث.
توصي Microsoft رسميًا بالإبقاء على ملفاتك في نظام التشغيل نفسه الذي تعمل فيه الأدوات التي تستخدمها لتحريرها وترجمتها.
توفر VS Code إضافة Remote WSL تتيح تحرير الملفات المستضافة في Linux بسلاسة عبر واجهة Windows دون أي تراجع في الأداء.
تختلف قواعد حساسية حالة الأحرف اختلافًا كبيرًا بين نظامي ملفات Windows وLinux، مما يجعل اختيار موقع المجلد الصحيح ضروريًا لتجنب أخطاء غير متوقعة.

فهم الفجوة بين نظامي ملفات Windows وLinux

من أكثر الأخطاء شيوعًا التي يقع فيها المطورون عند اعتماد نظام Windows الفرعي لـ Linux سوءُ وضع الملفات. يدير Windows وLinux مساحات التخزين الخاصة بهما وفق نماذج معمارية مختلفة تمامًا. فعند تشغيل WSL 2، أنت تستخدم نواة Linux حقيقية تعمل داخل آلة افتراضية خفيفة. وهذا يعني أن توزيعة Linux لديك تحتفظ بنظام ملفات Linux أصلي ومعزول خاص بها، يعمل وفق معايير POSIX.

في المقابل، تعتمد بيئة Windows القياسية على NTFS، وتستخدم أحرف محركات الأقراص مثل محرك C:. ولسد هذه الفجوة، يقوم WSL تلقائيًا بتركيب محركات Windows داخل بيئة Linux ضمن المجلد /mnt/، فيظهر محرك C مثلًا بالمسار /mnt/c. ورغم أن ذلك يجعل كل ملف على الجهاز المضيف قابلًا للقراءة والكتابة من طرفية Linux، فإنه يُدخل تكلفة أداء خفية وباهظة تُعرف بمسار الترجمة عبر الحدود.

لماذا يتباطأ الوصول إلى الملفات عبر الحدود

في كل مرة تقرأ فيها أداة Linux ملفًا موجودًا على جانب Windows من النظام أو تكتب فيه، يجب أن يعبر الطلب الحدود الفاصلة بين الآلة الافتراضية الخفيفة ونظام Windows المضيف. وبالنسبة إلى ملف نصي واحد أو نص برمجي صغير، تكون تكلفة الترجمة هذه غير ملحوظة. غير أن مسارات تطوير البرمجيات الحديثة نادرًا ما تتعامل مع ملف واحد فقط.

تأمل ما يحدث عند تشغيل أمر مثل npm install أو git clone على مجلد مشروع موجود داخل /mnt/c/my-project. فهذه العمليات تولّد آلاف طلبات إنشاء الملفات الصغيرة وتعديلها بتتابع سريع. ويدفع كل ملف من هذه الملفات الصغيرة تكلفة العبور. والنتيجة التراكمية أن عمليات كان ينبغي أن تستغرق ثوانٍ قد تمتد إلى دقائق، مما يدفع كثيرًا من المطورين إلى الاعتقاد خطأً بأن WSL بطيء بطبعه، بينما السبب الحقيقي هو سوء اختيار موقع المجلد فقط.

حساسية حالة الأحرف وتعارض الأذونات

لا يقتصر الضرر عند عبور حدود نظام التشغيل على الأداء. فقواعد نظام الملفات الأساسية تتعارض أيضاً بطرق تُفسد عمل التطبيقات. يتسم جذر نظام الملفات الأصلي في Linux بحساسية صارمة لحالة الأحرف، فالملفان Script.js وscript.js يُعاملان ككيانين مختلفين تماماً. في المقابل، يتجاهل نظام NTFS في Windows حالة الأحرف افتراضياً.

علاوة على ذلك، تعتمد أدوات سطر الأوامر في Linux بشكل كبير على أعلام الملكية والأذونات التي تديرها أدوات مثل chmod وchown. ولا تُطابق أنظمة ملفات Windows هذه الأذونات بشكل أصلي بالطريقة التي تتوقعها أدوات Linux. وعند تنفيذ الشيفرة عبر هذا الحد، قد تفشل الروابط الرمزية في الحل بشكل صحيح، وقد تُخرج نصوص البناء أخطاء غامضة لأنها لا تستطيع تطبيق أذونات الملفات التي تحتاجها بيئة التشغيل.

أفضل الممارسات لسير عمل WSL السريع

لتجنب هذه المزالق المتعلقة بالأداء والحفاظ على تجربة تطوير سلسة، ينبغي عليكم التزام عادتين أساسيتين. أولاً، احرصوا دائماً على وجود مشاريع Linux داخل نظام ملفات Linux الأصلي (في مجلد المستخدم الرئيسي مثلاً ~/projects/)، وأبقوا المشاريع المعتمدة على Windows فقط في جانب Windows.

ثانياً، استفيدوا من قوة الأدوات الحديثة لربط واجهة المستخدم دون التضحية بسرعة التنفيذ. ولا حاجة للتخلي عن محررات Windows المفضلة لديكم. فباستخدام إضافة Remote - WSL لبرنامج Visual Studio Code، يمكنكم فتح مشروع مخزَّن بالكامل داخل نظام ملفات Linux الأصلي مع الاستمتاع بواجهة رسومية مألوفة وسريعة الاستجابة في Windows. يعمل المحرر على Windows، بينما تعمل تنفيذ الشيفرة والاختبار وإدارة الحزم بأقصى سرعة داخل بيئة Linux.

الخلاصة والخطوات التالية

إن إتقان حدود أنظمة الملفات هو الخطوة الأهم على الإطلاق في تحويل WSL من تجربة مُحبِطة إلى أداة العمل اليومية. فعندما تتوافق أدواتكم وملفاتكم مع الجانب الصحيح من انقسام نظام التشغيل، تتخلصون من زمن الاستجابة المتأخر وتتجنبون أخطاء الأذونات الغامضة.

للاطلاع على نظرة أشمل لكيفية تكامل هذه الميزة مع سير عمل التطوير والخدمات السحابية الحديثة، استمعوا إلى الحلقة الكاملة من بودكاست M365 FM. تعمّقوا في الحديث الكامل لاكتشاف اختصارات التثبيت، ومقارنات الإصدارات، وكيف يسد WSL الفجوة بين الأجهزة المحلية وبنية Azure السحابية التحتية!

الأسئلة المتداولة

أين ينبغي أن أخزّن ملفات مشروعي عند استخدام WSL؟

ينبغي تخزين ملفات مشروعكم داخل نظام ملفات Linux الأصلي (مثل مجلد المستخدم الرئيسي، على سبيل المثال ~/my-project) بدلاً من محركات Windows المتصلة (مثل /mnt/c/)، لضمان أقصى سرعات القراءة والكتابة.

لماذا يكون تشغيل npm install بطيئاً على محرك Windows داخل WSL؟

تُنشئ مديرات الحزم مثل npm أو pip آلاف الملفات الصغيرة أثناء التثبيت. وعندما تُكتب هذه الملفات عبر حد نظام التشغيل إلى محرك Windows بنظام NTFS، يتحمل كل ملف على حدة عبئاً إضافياً للترجمة، مما يسبب اختناقات كبيرة في الأداء.

هل يمكنني استخدام Visual Studio Code لتحرير الملفات المخزنة داخل نظام ملفات Linux؟

نعم. فبتثبيت إضافة Remote - WSL لبرنامج Visual Studio Code، يمكنكم فتح الملفات الموجودة داخل توزيعة Linux الخاصة بـ WSL وتحريرها وتصحيح أخطائها مباشرة، مع الاستمرار في استخدام واجهة المحرر القياسية في Windows.

ما الفرق بين طريقة تعامل Windows وLinux مع أسماء الملفات؟

تتسم أنظمة ملفات Linux بحساسية صارمة لحالة الأحرف، فتعامل File.txt وfile.txt كملفين مختلفين، في حين يتجاهل نظام NTFS في Windows حالة الأحرف افتراضياً. ويؤدي تشغيل أدوات Linux على مجلدات مستضافة في Windows غالباً إلى فشل عمليات البناء بسبب هذه الاختلافات السلوكية الكامنة.