Systemd-swap: الإسبات حقا غير ممكن؟

TeslaBargain ، نوع من سحر الفودو الأسود.

بالطبع من الممكن أن تجعلها بمفردك - حتى تتمكن من القيام بذلك بنفسك.

بالنسبة إلى zram ، تحتاج إلى جعل كل هذه الأشياء تحدث قبل السبات:

1. إضافة ملف مبادلة جديد
2. قم بتهيئته وتبديله
3. أضف جميع المعلومات للوصول إلى البيانات الموجودة في swapfile إلى kernel cmdline (تغيير تكوين اليرقة ، أو نظام التمهيد ، أو lilo ، أو u-boot وما إلى ذلك؟)
4. مبادلة الزرام
5. السبات (أعتقد أنك لا تعرف مقدار الوقت الذي فقدته قبل حدوث كل ذلك ، لجعل السبات ممكنًا)
6. بعد إعادة التشغيل / الخروج من وضع الإسبات ، يجب عليك القيام بكل هذه الأشياء بترتيب عكسي.

وهذا سيعمل فقط على fs التي تدعم هذا النوع من ملفات المبادلة ، أي لملفات btrfs غير الممكنة.

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

ماذا لو كان هناك خيار لتهيئة وتبديل ملفات مبادلة كافية للنظام لإسبات كل الذاكرة المتوفرة عند بدء تشغيل systemd-swap؟ وقم بإجراء مكالمات bootctl ، أو استخدم نوعًا من المواقع الثابتة للاختبار ، للحصول على معلومات للوصول إلى البيانات في ملف المبادلة إلى kernel cmdline في نظام التشغيل systemctl-boot أو rEFInd أو grub أو أيًا كان؟

بهذه الطريقة ، سيكون التأخر الحقيقي الوحيد هو استبدال zram ، وهو شيء لا مفر منه في استخدام zram.

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

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

تحرير: هذا https://gist.github.com/klingtnet/c972b8182e4e2818d6d551b0cbeac44b
بالإضافة إلى تبادل النظام (zram)

أعتقد أنه يمكن تحقيق ذلك من خلال تبديل الأولويات + الخطافات لإسبات systemd. لم يجيب البحث السريع لأسئلة Stackoverflow المختلفة عن هذا السؤال ، لذا يجب أن أقوم باختباره يدويًا. هذا في الواقع حل أسهل بكثير من ذلك الذي كنت أفكر فيه ، وبالتالي قد يتم تنفيذه قبل 5.0 (على الرغم من أن الإصلاح الكامل يجب أن يكون في 5.0)

IIRC ، يتطلب الإسبات جهاز مبادلة واحد ، لذا يجب أن يكون كبيرًا بما يكفي لتخزين كل الذاكرة المخصصة في ذاكرة الوصول العشوائي / التبديل في مكان آخر؟ (لكن صورة الإسبات هذه المكتوبة يجب أن تستخدم ضغطًا افتراضيًا مع هدف يبلغ حوالي 40٪).

لم أحاول مثل هذا بنفسي ، ألا يحتفظ الإسبات بملفات المبادلة على القرص أو جهاز (أجهزة) zram في ذاكرة الوصول العشوائي كما لو تم تخصيصها مثل أي برنامج آخر؟ أنت تستأنف حالة النظام ، طالما أن الذاكرة مكتوبة في صورة الإسبات ، فيجب أن تستعيد / تستأنف أجهزة المبادلة المعينة مسبقًا بدلاً من الاضطرار إلى تهيئتها كما لو كان التمهيد الجديد؟ وبالتالي لا ينبغي أن تكون هناك حاجة لمبادلة / تشغيل ما بعد تبديل جهاز مبادلة الإسبات؟

لقد دخلت في حالة السبات فقط باستخدام جهاز مبادلة واحد (بدون zswap أو zram). لست متأكدًا مما يحدث لمبادلة القرص (كما هو الحال في أكثر من جهاز مبادلة واحد موجود) في هذه الحالة (إذا كانت بحاجة إلى التوافق مع صورة الإسبات ، فقد يبدو ذلك زائداً عن الحاجة؟) ، وبالمثل أفترض أن zram سيكون لها ذاكرة مخصصة مكتوبًا على صورة الإسبات مثل أي ذاكرة أخرى مخصصة بواسطة البرنامج ، ولست متأكدًا من كيفية التعامل مع جزء المبادلة ، إذا كانت هناك حاجة إلى كتابة أجهزة مبادلة إضافية في صورة الإسبات ، فأعتقد أن zram وذاكرة التخزين المؤقت لـ zswap في ذاكرة الوصول العشوائي ستفك الضغط ثم استئناف بحاجة إلى إعادة ضغطها.

أنا غير قادر على اختبار السيناريو ATM لمعرفة ما يحدث. ربما ليس من الصعب اختبارها عبر VM؟

تجدر الإشارة إلى أن معظم التوزيعات التي تستخدم systemd يجب أن تؤجل الإسبات إلى systemd-sleep hibernate هذه الأيام afaik؟ منذ 2019-2020 (في الإصدار 239 + على ما أظن؟) لديه القدرة على الاستئناف من السبات دون الحاجة إلى معلمات kernel لتحديد جهاز المبادلة الهدف (القسم فقط في هذه الحالة iirc) ، وسوف يخمن أي جهاز مبادل لاستخدامه ضمنيًا. إذا كان هناك قسم تبديل واحد فقط ، فيجب أن يكون موثوقًا به دون الحاجة إلى تعيين / تحديث معلمات تمهيد kernel resume (و resume_offset حالة استخدام ملف المبادلة).

مرة أخرى ، ليس شيئًا اختبرته حتى الآن للتحقق منه.

مشكلة تتبع المنبع: https://github.com/systemd/systemd/issues/16708