مشاريع WSL2 على محرك Windows تضر الأداء: إليك السبب

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

المشكلة الحقيقية تكمن في مكان وجود ملفاتك

نظام ملفات Windows يفرض عقوبة أداء خفية

إذا كان مشروعك موجودًا في مكان مثل:

/mnt/c/Users/YourName/projects/my-app

أنت لا تعمل حقًا على نظام ملفات Linux. أنت تعمل على نظام ملفات Windows، الذي يتم الوصول إليه عبر طبقة ترجمة.

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

ومع ذلك، عندما تصل إلى الملفات تحت /mnt/c، /mnt/d، أو أي محرك أقراص Windows مثبت، يجب أن تعبر كل عملية ملف حدودًا بين Linux و Windows. هذه الحدود هي حيث يموت الأداء (بهدوء، دون إظهار أخطاء، مما يجعل الأمر أسوأ).

لماذا يؤدي هذا فعليًا إلى إبطاء الأمور

أعباء العمل كثيفة الملفات تضخم تكلفة ترجمة نظام الملفات

أعباء عمل التطوير الحديثة تعتمد بشكل كبير على الملفات. فكر فيما يحدث عندما تقوم بتشغيل شيء مثل:

npm install
pip install
cargo build
npm run dev

تقوم هذه الأدوات بإنشاء وقراءة وتعديل آلاف الملفات الصغيرة. وهي تعتمد على الوصول السريع لنظام الملفات والسلوك المتوقع.

على نظام ملفات Linux الأصلي، يتم تحسين هذا، ولكن على نظام ملفات Windows الذي يتم الوصول إليه عبر WSL2، تتضمن كل من هذه العمليات ترجمة بين نظامين مختلفين.

نتيجة لذلك، تعمل الأمور، ولكن كل شيء أبطأ. أحيانًا يكون أبطأ بمرتين، وأحيانًا 10 مرات، وفي بعض الحالات، يمكن أن يكون أسوأ. لا تلاحظ ذلك دائمًا على الفور لأن التباطؤ موزع على العديد من العمليات الصغيرة، ولكن بمرور الوقت، يتراكم.

إحدى أسهل الطرق لملاحظة هذه المشكلة هي باستخدام Git. قم بتشغيل git status أو git checkout على مستودع كبير مخزن تحت /mnt/c، وقارنه بنفس المستودع داخل دليل Linux الرئيسي الخاص بك.

الفرق ليس خفيًا، فـ Git يُجري الكثير من عمليات نظام الملفات. فهو يمسح الدلائل، ويتحقق من البيانات الوصفية، ويقارن حالات الملفات. على جسر نظام ملفات بطيء، يصبح هذا الأمر واضحًا بشكل مؤلم. غالبًا ما يلوم الناس Git نفسه أو يفترضون أن مستودعهم “كبير فقط”. في الواقع، اختيار نظام الملفات هو الذي يسبب معظم الضرر.

عرض آخر شائع هو مراقبة الملفات غير الموثوقة. تعتمد أدوات مثل webpack أو Vite أو nodemon على أحداث نظام الملفات لاكتشاف التغييرات. في نظام ملفات Linux الأصلي، يتم تسليم هذه الأحداث بكفاءة.

عبر حدود Windows، تصبح الأمور غير متسقة.

قد تلاحظ:

• التغييرات لا تؤدي إلى إعادة البناء
• إعادة التحميل المتأخرة
• زيادة استخدام وحدة المعالجة المركزية (CPU) بسبب آليات الاستقصاء الاحتياطية

هذا ليس خطأً في أدواتك، بل هو نتيجة لكيفية ترجمة إشعارات نظام الملفات بين Windows و Linux. انقل المشروع إلى نظام ملفات WSL2، وستختفي هذه المشكلات عادةً.

الراحة المضللة لـ /mnt/c

الراحة تخفي تكلفة الوصول عبر الأنظمة

من المفهوم تمامًا لماذا ينتهي المطاف بالناس هنا. تبدأ العمل في Windows وملفاتك ومحررك موجودان هناك. يبدو طبيعيًا أن تصل إليها من WSL2 عبر /mnt/c.

يمنحك هذا وهم بيئة موحدة. نظام ملفات واحد، يمكن الوصول إليه من كل من Windows و Linux، باستثناء أنه ليس موحدًا بل هو مجسر، والجسور لها تكاليفها.

هذا الإعداد جيد للوصول العرضي إلى الملفات، ولكنه ليس جيدًا لأعباء عمل التطوير النشطة التي تعتمد على عمليات نظام الملفات عالية التردد.

عندما تعمل على نظام ملفات Linux داخل WSL2، يكون الفرق فوريًا. يبدو مسارك كالتالي:

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

ولكن ماذا عن الوصول من Windows؟

المحررات الحديثة تدعم بالفعل سير عمل Linux عن بُعد

هذا هو الجزء الذي يجعل الناس يترددون. إذا كان مشروعك موجودًا داخل WSL2، فكيف تفتحه في محرر Windows الخاص بك؟

الجواب هو أن الأدوات الحديثة قد حلت هذه المشكلة بالفعل. إذا كنت تستخدم VS Code، فإن ملحق Remote WSL يسمح لك بفتح نظام ملفات Linux الخاص بك مباشرة. يعمل محرر VS Code على Windows، ولكن الملفات تبقى داخل WSL2.

هذا هو سير العمل المقصود. إنه يتجنب (وليس بشكل كامل) عقوبة الأداء مع الحفاظ على تجربة التطوير الخاصة بك سليمة. يمكنك أيضًا الوصول إلى ملفات WSL عبر المسار الخاص:

\wsl$YourDistrohomeyouruserprojects

متى قد لا تزال تستخدم /mnt/c

بعض أعباء العمل لا تزال تستفيد من نظام ملفات Windows

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

بمجرد أن تتبنى هذا النموذج، يصبح قرار نظام الملفات واضحًا. لن تقوم عادةً بتطوير مشروع Linux على نظام ملفات مُثبّت على الشبكة بزمن وصول عالٍ. ستبقيه محليًا. في WSL2، نظام ملفات Linux هو بيئتك المحلية، ونظام ملفات Windows بعيد فعليًا من منظور Linux.

إصلاحه يستغرق دقائق

نقل المشروع أو استنساخه داخل نظام ملفات Linux

الحل ليس معقدًا. كل ما عليك فعله هو نقل مشروعك:

mv /mnt/c/Users/YourName/projects/my-app ~/projects/ 

أو استنساخه مرة أخرى مباشرة داخل WSL2:

git clone <repo>  ~/projects/my-app 

حدّث محرر الأكواد الخاص بك لفتح الموقع الجديد.

يعتمد الأداء على الموقع أكثر من الضبط

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

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