هل يستحق ZFS استخدام ذاكرة RAM على خادمك الافتراضي؟

ما الذي يمنحك إياه ZFS، وما الذي يتطلبه

أصبح نظام ZFS على FreeBSD وLinux الآن قاعدة برمجية واحدة تُعرف بـ OpenZFS، لذا فإن الميزات متطابقة على كلا النظامين. يحصل الخادم الذي يعمل بنظام ZFS على بيانات ذات مجموع اختباري (checksummed)، ولقطات (snapshots) لا تستهلك أي مساحة حتى تتغير البيانات، ونسخ متماثل باستخدام zfs send، وضغط للبيانات يمكن تفعيله عبر تغيير خاصية واحدة. ما يتطلبه النظام هو الذاكرة: حيث يستهلك الـ ARC (ذاكرة التخزين المؤقت التكيفية) حصة كبيرة من ذاكرة الوصول العشوائي (RAM) افتراضياً، وفي خادم افتراضي خاص (VPS) بسعة 2 GB أو 4 GB، تكون هذه الذاكرة هي بالضبط ما يحتاجه تطبيقك.

يقيّم هذا الدليل ZFS من منظور خادم افتراضي خاص (VPS) مستأجر بقرص افتراضي واحد أو اثنين، وليس من منظور خادم تخزين يحتوي على أربعين منفذ أقراص. الميزات التي تظل مفيدة في هذا السياق هي التي تستحق وقتك. أما الأجزاء التي لا تتناسب مع هذا السياق، فمن المفيد معرفتها قبل إنشاء مجموعة التخزين (pool).

OpenZFS على FreeBSD وLinux: قاعدة برمجية واحدة، وقصتا تغليف مختلفتان

تتضمن FreeBSD نظام ZFS ضمن النظام الأساسي منذ إصدار FreeBSD 7.0 في عام 2008، كخاصية تجريبية في البداية. ومنذ إصدار OpenZFS 2.0 في ديسمبر 2020، أصبح كل من FreeBSD وLinux يُبنيان من شجرة المصدر نفسها، لذا فإن zfs وzpool يعملان بالطريقة ذاتها على كلا النظامين، ويمكن استيراد مجموعة التخزين (pool) التي أُنشئت على أحدهما في الآخر.

يعود سبب كون ZFS حزمة برمجية على Linux وجزءاً من النظام الأساسي على FreeBSD إلى الترخيص. يخضع OpenZFS لرخصة CDDL (رخصة التطوير والتوزيع المشتركة). بينما يخضع نواة Linux لرخصة GPL (الرخصة العامة العامة) الإصدار 2. يعتبر مشروع النواة أن الرخصتين غير متوافقتين، لذا لا يُدمج كود ZFS في خط Linux الرئيسي، ويقرر كل توزيع كيف يوفّر هذا النظام. لا تواجه FreeBSD هذا التعارض، لذا فإن ZFS موجود ببساطة. هذه هي القصة العملية الكاملة: اختلاف واحد في التغليف، ولا يوجد ما يستدعي انحيازك لأي طرف.

لا توفر SSD Nodes صوراً لنظام FreeBSD، لذا على الخادم المستأجر هنا، ينطبق الجزء الخاص بـ Linux من هذا الدليل. إذا كنت تشغّل FreeBSD في مكان آخر، فإن خادم FreeBSD يحصل على ZFS دون الحاجة لبناء وحدات برمجية (modules) أو القلق بشأن ترقيات النواة.

تثبيت ZFS وإنشاء مجمع تخزين (Pool)

في Ubuntu، تأتي الوحدة البرمجية (module) ضمن حزم النواة، لذا أنت بحاجة فقط لتثبيت الأوامر.

sudo apt update
sudo apt install -y zfsutils-linux
zfs version

يطبع zfs version سطرين، أحدهما لإصدار أدوات المستخدم والآخر لإصدار وحدة النواة. إذا ظهر سطر واحد فقط، فهذا يعني أن الوحدة لم تُحمّل. توجد الحزمة في مكون universe، وهو مفعّل افتراضياً في صور Ubuntu Server؛ إذا لم يعثر عليه apt، نفّذ sudo add-apt-repository universe أولاً.

في Debian، توجد الحزم في مكون contrib، ويتم بناء الوحدة على جهازك بواسطة DKMS (دعم وحدة النواة الديناميكي). أضف contrib إلى سطر Components: في ملف /etc/apt/sources.list.d/debian.sources، ثم نفّذ sudo apt update، وبعدها:

sudo apt install -y linux-headers-$(dpkg --print-architecture) zfs-dkms zfsutils-linux

تؤدي عملية التثبيت إلى تجميع الوحدة وطباعة Building initial module for 6.12.0-...، وتستغرق هذه العملية بضع دقائق. تذكر ما يعنيه ذلك: كل ترقية للنواة تتطلب إعادة بناء الوحدة، وأي فشل في البناء سيجعل مجمع التخزين غير متاح (unimported) حتى تعالج المشكلة.

في FreeBSD، لا يوجد شيء لتثبيته. فعّل الخدمة وابدأ تشغيلها.

sysrc zfs_enable=YES
service zfs start

الآن، لننشئ مجمع التخزين. ابحث أولاً عن مسارات الأجهزة الثابتة، لأن /dev/vdb يُمنح بناءً على ترتيب الاكتشاف وقد يتغير عند توصيل وحدة تخزين أخرى.

ls -l /dev/disk/by-id/
sudo zpool create -o ashift=12 tank /dev/disk/by-id/virtio-abc123def456
zpool status tank

يجب أن يطبع zpool status عبارة state: ONLINE مع إدراج جهازك تحت tank. يضبط ashift=12 أصغر كتلة في المجمع على 4 KiB، وهو ما يتوافق مع أقراص SSD الحديثة ولا يمكن تغييره بعد الإنشاء.

تُقلع معظم الصور المستأجرة من نظام ملفات ext4، لذا فإن ZFS هنا سيكون مجمع بيانات على وحدة تخزين ثانية وليس نظام ملفات الجذر. تأكد من أن الجهاز هو المقصود قبل البدء في البناء عليه، لأن التحقق من قرص NVMe الذي استأجرته يستغرق دقيقة واحدة، بينما تستغرق إعادة البناء فترة بعد الظهر كاملة.

لا تعمل مجموعات التحقق (Checksums) على الإصلاح إلا إذا كان التجمع (Pool) يتمتع بالتكرار

تتضمن كل كتلة (Block) يكتبها ZFS مجموع تحقق، ويتم التحقق منه عند كل عملية قراءة. الاكتشاف يعمل دائماً، لكن الإصلاح يتطلب نسخة ثانية.

في التجمع المكون من قرص واحد، يخبرك ZFS بالحقيقة ويتوقف عند هذا الحد. يظهر zpool status -v ذلك على النحو التالي:

status: One or more devices has experienced an error resulting in data
        corruption.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
errors: Permanent errors have been detected in the following files:

        /tank/data/archive.tar

يتم ذكر اسم الملف التالف. كان نظام ext4 سيعيد تلك البايتات دون تعليق، لذا فإن هذا بحد ذاته ذو قيمة. لا يزال ZFS غير قادر على إصلاح الملف، لعدم وجود نسخة ثانية في التجمع يمكن الاستعانة بها للإصلاح.

مع وجود مرآة (Mirror)، يتم تقديم عملية القراءة نفسها من الجانب السليم، وتُعاد كتابة الكتلة التالفة، ويظهر الحدث في عمود CKSUM الخاص بـ zpool status. هذا هو الإصلاح الذاتي، وهو يتطلب جهازين.

sudo zpool create -o ashift=12 tank mirror /dev/disk/by-id/DISK1 /dev/disk/by-id/DISK2

على خادم افتراضي (VPS)، تكون وحدة تخزين المضيف عادةً مكررة بالفعل، وغالباً ما تكون RAID 10 تحت طبقة الـ hypervisor. هذا يحميك من تعطل القرص، لكنه لا يخبرك عندما تعود كتلة ما بشكل خاطئ، لأن المصفوفة لا تملك وسيلة لمعرفة أي نسخة هي الصحيحة. يعرف ZFS ذلك، لأنه يقارن البيانات بمجموع تحقق كتبه بنفسه.

إذا كان لديك قرص افتراضي واحد وترغب في الحصول على بعض القدرة على الإصلاح، فإن sudo zfs set copies=2 tank/important يخزن نسختين من كل كتلة في مجموعة البيانات تلك على القرص نفسه. هذا يضاعف المساحة التي تستخدمها مجموعة البيانات، ويسمح بالنجاة من كتلة تالفة، لكنه لا يفعل شيئاً عند اختفاء وحدة التخزين بالكامل.

تقوم عملية الفحص (Scrub) بقراءة كل شيء في التجمع والتحقق منه.

sudo zpool scrub tank
zpool status tank

ينتهي التجمع السليم بسطر مثل scan: scrub repaired 0B in 00:04:11 with 0 errors. ضع هذه العملية في جدول زمني؛ الفحص الشهري مناسب للتجمعات الصغيرة.

systemctl list-unit-files 'zfs-scrub*'
sudo systemctl enable --now zfs-scrub-monthly@tank.timer

مجموعات البيانات هي وحدة السياسة

مجموعة البيانات (Dataset) هي نظام ملفات داخل التجمع (Pool)، وإنشاؤها عملية غير مكلفة، لذا أنشئ مجموعة بيانات واحدة لكل مهمة. ترث الخصائص قيمها من التجمع، وهذا يعني أنك تضبط القيمة الافتراضية مرة واحدة وتتجاوزها فقط عند الضرورة.

sudo zfs create tank/data
sudo zfs create tank/pg
sudo zfs set compression=lz4 tank
sudo zfs set atime=off tank
sudo zfs set quota=20G tank/data
sudo zfs set recordsize=16K tank/pg
zfs get -r compression,compressratio,quota tank

الضغط (Compression) هو الخاصية التي يتركها المستخدمون معطلة بدافع الحذر، وهذا تصرف خاطئ. يستهلك lz4 قدراً بسيطاً من المعالج ويقلل عدد البايتات التي يجب أن تصل إلى القرص، لذا فهو يجعل عمليات القراءة والكتابة أسرع عادةً مع البيانات القابلة للضغط. يضغط zstd البيانات بشكل أقوى مقابل استهلاك أكبر للمعالج، وهو ما يناسب السجلات والأرشيفات التي نادراً ما تقرأها. تحقق مما تحصل عليه فعلياً باستخدام zfs get compressratio tank، وتذكر أن نسبة الضغط تحسب فقط البيانات المكتوبة بعد ضبط الخاصية.

recordsize هو أكبر حجم كتلة تكتبه مجموعة البيانات، وهو 128K افتراضياً. قاعدة بيانات تكتب صفحات بحجم 8 KiB في سجلات بحجم 128 KiB تحوّل عملية الكتابة الصغيرة الواحدة إلى قراءة للسجل بالكامل، ثم إجراء تعديل، ثم إعادة كتابته. اضبط recordsize=16K على مجموعة بيانات قاعدة البيانات قبل تحميل البيانات، لأن هذه الخاصية تُطبق على الكتل المكتوبة حديثاً فقط.

quota هي الطريقة التي تمنع بها مجموعة بيانات واحدة من ملء التجمع بالكامل. يصبح تجمع ZFS الذي يقترب من 100% من سعته بطيئاً وصعب التنظيف، لذا اترك مساحة إضافية متعمداً.

لا تكلّف اللقطات (Snapshots) شيئاً حتى تتغير البيانات

لا يقوم ZFS بالكتابة فوق أي كتلة بيانات نشطة أبداً. بل يكتب كتلة جديدة ويحدّث المؤشرات، وهذا هو جوهر مفهوم "الكتابة عند النسخ" (copy-on-write). اللقطة هي مجرد ملاحظة تقول "احتفظ بالكتل التي يشير إليها هذا النطاق من البيانات (dataset) الآن"، لذا فإن أخذ لقطة يتم فوراً وبدون تكلفة.

sudo zfs snapshot tank/data@2026-08-11
zfs list -t snapshot -o name,used,refer -r tank/data

عمود USED الخاص باللقطة يمثل المساحة التي تشغلها تلك اللقطة وحدها. يبدأ هذا العمود بالقرب من الصفر ويزداد كلما قمت بتغيير أو حذف البيانات، لأن الكتل القديمة لا يمكن تحريرها بعد الآن.

استعادة ملف لا تتطلب أي خطوة استعادة (restore) معقدة.

ls /tank/data/.zfs/snapshot/
cp /tank/data/.zfs/snapshot/2026-08-11/notes.txt /tank/data/notes.txt

دليل .zfs مخفي حتى عن ls -a إلى أن تقوم بتشغيل sudo zfs set snapdir=visible tank/data. خذ اللقطة قبل أن تحتاج إليها، لأنه بدونها سيؤدي أمر rm -rf خاطئ إلى دفعك نحو مسار استعادة ext4، الذي يبدأ بإلغاء تحميل القرص (unmounting) ويزداد تعقيداً من هناك.

التراجع (Rollback) يتخلص من كل ما كُتب منذ أخذ اللقطة.

sudo zfs rollback tank/data@2026-08-11

يرفض النظام التراجع إذا كانت هناك لقطات أحدث، ويقوم -r بتدمير تلك اللقطات الأحدث للمتابعة. اقرأ اسم النطاق (dataset) مرتين قبل الضغط على مفتاح الإدخال.

اللقطة ليست نسخة احتياطية. فهي تعيش في نفس التجمع (pool)، وعلى نفس وحدة التخزين (volume)، وعلى نفس الخادم. فشل وحدة التخزين أو تعرضها لـ zpool destroy سيؤدي إلى ضياع اللقطات مع البيانات. تحميك اللقطات من أخطائك الشخصية (rm) ومن التحديثات السيئة، وهو ما يغطي الكثير من الحوادث الواقعية، لكنها لا تحميك من أي شيء يحدث للتجمع نفسه. التفاصيل الكاملة موضحة هنا: لماذا لقطة VPS ليست نسخة احتياطية.

الإرسال والاستقبال: النسخ المتماثل في أمر واحد

يحوّل zfs send اللقطة (snapshot) إلى تدفق بيانات (byte stream) على المخرج القياسي، بينما يعيد zfs receive تحويل ذلك التدفق إلى مجموعة بيانات (dataset). النسخة الأولى تكون إرسالاً كاملاً.

sudo zfs snapshot tank/data@daily-2026-08-11
sudo zfs send tank/data@daily-2026-08-11 | ssh backup.example.com "sudo zfs recv -F backup/data"

بعد ذلك، أرسل فقط ما تغير بين لقطتين.

sudo zfs snapshot tank/data@daily-2026-08-12
sudo zfs send -i tank/data@daily-2026-08-11 tank/data@daily-2026-08-12 | ssh backup.example.com "sudo zfs recv backup/data"

يجب أن يحتفظ الطرف المستقبل باللقطة التي ترسل منها. عندما لا يمتلكها، يتوقف الاستقبال مع cannot receive incremental stream: most recent snapshot of backup/data does not match incremental source، لأن ZFS لا تملك أساساً لتطبيق الفرق عليه. أرسل من لقطة يمتلكها الطرفان، أو ابدأ من جديد بإرسال كامل.

امنح الصلاحيات على الهدف بدلاً من استخدام root عن بُعد: sudo zfs allow -u backupuser create,mount,receive backup/data.

هذا هو النسخ الاحتياطي الفعلي خارج الموقع بشرط واحد. يجب أن يكون الطرف البعيد عبارة عن تجمع ZFS (ZFS pool)، لأن تخزين الكائنات (object storage) لا يمكنه استقبال تدفق بيانات. عندما يكون هدفك تخزيناً متوافقاً مع S3 أو مضيف Linux عادياً، استخدم أداة تتواصل معه، ويغطي نسخ restic الاحتياطية من خادم VPS هذا المسار.

لماذا يستهلك ZFS الكثير من ذاكرة الوصول العشوائي (RAM)؟ الـ ARC

الـ ARC (ذاكرة التخزين المؤقت التكيفية للاستبدال) هي ذاكرة التخزين المؤقت للقراءة في ZFS. توجد هذه الذاكرة في ذاكرة النواة (kernel memory) بدلاً من ذاكرة التخزين المؤقت العادية لصفحات Linux، لذا لا يبلغ free -h عنها ضمن خانة buff/cache. تظهر هذه الذاكرة كذاكرة مستخدمة. الخادم الذي يعمل بنظام ZFS ويبدو ممتلئ الذاكرة هو في الغالب خادم يمتلك ذاكرة تخزين مؤقت نشطة، وهذا يفسر معظم تقارير "ZFS استهلك ذاكرتي".

الحد الافتراضي سخي عن قصد. يضبط OpenZFS 2.3 الحد الأقصى لحجم ARC على القيمة الأكبر بين (حجم RAM ناقص 1 GiB) أو (5/8 من حجم RAM). كان OpenZFS 2.2 والإصدارات الأقدم يستخدمون نصف حجم RAM على Linux، بينما كان FreeBSD يستخدم القاعدة الأحدث بالفعل. نفّذ zfs version لمعرفة القاعدة المطبقة لديك.

[
  {
    "label": "2 GB VPS",
    "openzfs_2_2_linux_gib": 1,
    "openzfs_2_3_gib": 1.25
  },
  {
    "label": "4 GB VPS",
    "openzfs_2_2_linux_gib": 2,
    "openzfs_2_3_gib": 3
  },
  {
    "label": "8 GB VPS",
    "openzfs_2_2_linux_gib": 4,
    "openzfs_2_3_gib": 7
  },
  {
    "label": "16 GB VPS",
    "openzfs_2_2_linux_gib": 8,
    "openzfs_2_3_gib": 15
  }
]

هذه الأرقام هي القاعدة الافتراضية الموثقة المطبقة على أحجام الخوادم الشائعة، وليست قياسات من خادم قيد التشغيل. على خادم بحجم 4 GB، تسمح قاعدة الإصدار 2.3 بـ ARC بحجم 3 GiB. بينما يتوقف الخادم نفسه على الإصدار 2.2 عند 2 GiB. أما الخادم بحجم 2 GB فيسمح بموجب قاعدة 2.3 بـ 1.25 GiB. تحصل تطبيقاتك على ما تبقى من الذاكرة.

اقرأ الأرقام الفعلية من خادمك بدلاً من الاعتماد على الجدول:

grep -E '^(size|c_max) ' /proc/spl/kstat/zfs/arcstats
arc_summary | head -n 20

العمود الثالث يمثل البايتات. c_max هو الحد الأقصى المطبق حالياً، وsize هو ما تشغله الـ ARC في الوقت الراهن.

تُعيد الـ ARC الذاكرة عند الحاجة. تُرسل النواة إشارات ضغط (pressure) فتنكمش الـ ARC. تكمن المشكلة في التوقيت، لأن الانكماش مدفوع بوجود ذلك الضغط، لذا قد تواجه عملية تطلب مئات MiB دفعة واحدة قاتل الذاكرة (OOM killer) بينما لا تزال الـ ARC في طور التحرير. على خادم بحجم 2 GB يشغل قاعدة بيانات وخادم ويب، هذا ليس حدثاً نادراً. يذكر دليل OpenZFS الشيء نفسه بخصوص التغييرات اليدوية: خفض الحد "لن يتسبب في انكماش الـ ARC دون وجود ضغط ذاكرة يحفز هذا الانكماش".

كيفية تحديد سقف لـ ARC على خادم VPS صغير

حدد أولاً حجم الذاكرة التي يحتاجها عبء العمل. اجمع احتياجات قاعدة البيانات والتطبيق، واترك هامشاً لنظام التشغيل، وخصص الباقي لـ ARC. في خادم بسعة 4 GB يشغّل Postgres وتطبيق ويب واحداً، يُعد تخصيص ما بين 512 MiB إلى 1 GiB لـ ARC نقطة بداية منطقية.

طبّق الإعداد فوراً، بالقيمة بالبايت. هذا المثال يخصص 1 GiB.

echo 1073741824 | sudo tee /sys/module/zfs/parameters/zfs_arc_max

اجعل الإعداد مستمراً بعد إعادة التشغيل.

echo 'options zfs zfs_arc_max=1073741824' | sudo tee /etc/modprobe.d/zfs.conf
sudo update-initramfs -u

خطوة initramfs مهمة لأن الوحدة قد تُحمّل من initramfs قبل تحميل نظام ملفات الجذر، مما يعني أنها لن تقرأ الملف الذي أنشأته للتو. بعد إعادة التشغيل، تحقق من القيمة باستخدام السطر c_max من arcstats.

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

على FreeBSD، يقع هذا الحد ضمن sysctl تحت vfs.zfs.arc. نفّذ sysctl vfs.zfs.arc لرؤية القيم الحالية والاسم الدقيق الذي يستخدمه إصدارك، ثم اكتب القيمة القصوى في /boot/loader.conf.

قاعدتان إضافيتان للذاكرة في الخوادم الصغيرة. أبقِ خاصية إلغاء التكرار (deduplication) معطلة، لأن جدول إلغاء التكرار يستهلك الذاكرة، والقاعدة العامة المعروفة هي تخصيص 1 إلى 3 GB من ذاكرة الوصول العشوائي لكل TB من البيانات الفريدة. ولا تضع ملف التبديل (swap) على zvol (جهاز كتلي مقتطع من التجمع)، لأن التبديل عبر نظام ملفات يحاول تحرير الذاكرة قد يؤدي إلى توقف النظام بالكامل (deadlock). احتفظ بملف التبديل على قسم عادي أو ملف تبديل خارج التجمع.

متى يكون استخدام ext4 أو XFS مع restic خياراً أفضل

يُثبت ZFS كفاءته على الخوادم التي تمتلك ذاكرة إضافية ووحدة تخزين ثانية. بخلاف ذلك، يتفوق نظام ملفات بسيط مع أداة نسخ احتياطي حقيقية. اختر ext4 أو XFS في الحالات التالية:

• إذا كانت سعة ذاكرة الوصول العشوائي (RAM) في الخادم 2 جيجابايت أو 4 جيجابايت، وكان عبء العمل يتطلب كامل هذه السعة.
• إذا كان لديك قرص افتراضي واحد ولا توجد نسخة ثانية، حيث سيوفر لك ZFS ميزة اكتشاف الأخطاء دون القدرة على إصلاحها.
• إذا كانت وجهة النسخ الاحتياطي هي تخزين كائني (object storage) أو مضيف Linux عادي، حيث لا يوجد شيء هناك يمكنه استقبال تدفق zfs send.
• إذا كنت تستخدم Debian مع DKMS ولا يمكنك تحمل تكلفة ترقية النواة التي قد تؤدي إلى عدم بناء الوحدة (module) بشكل صحيح.
• إذا كنت بحاجة إلى ZFS على نظام ملفات الجذر (root filesystem) وكانت صور النظام التي يوفرها مزود الخدمة تدعم ext4 فقط.

احتفظ بـ ZFS إذا كان لديك وحدة بيانات منفصلة، وذاكرة وصول عشوائي كافية (8 جيجابايت فما فوق تعتبر مريحة)، وخطة تستفيد من اللقطات (snapshots) وzfs send بدلاً من مجرد تفعيلها. بالنسبة لكل شيء آخر، فإن استخدام ext4 مع restic لكتابة نسخ احتياطية مشفرة ومزالة التكرار (deduplicated) إلى وحدة تخزين لا يتحكم فيها الخادم يغطي معظم المتطلبات دون استهلاك ذاكرة إضافية.

أنماط الفشل والرسائل التي ستراها

اختفاء التجمع (pool) بعد إعادة التشغيل. يطبع zpool status الرسالة no pools available. تقرأ خدمة الاستيراد الملف /etc/zfs/zpool.cache، لذا فإن أي تجمع غير موجود في هذا الملف لن يتم استيراده عند الإقلاع. يسرد sudo zpool import التجمعات القابلة للاستيراد، ويقوم sudo zpool import tank باستعادتها، بينما يجعلها sudo zpool set cachefile=/etc/zfs/zpool.cache tank دائمة. التجمع الذي لم يتم تصديره بشكل سليم من نظام آخر يبلغ عن cannot import 'tank': pool may be in use from other system، ويقوم sudo zpool import -f tank بتجاوز ذلك بمجرد التأكد من عدم وجود مضيف آخر يستخدمه.

modprobe: FATAL: Module zfs not found in directory /lib/modules/6.12.0-... على Debian بعد ترقية النواة. لم يقم DKMS بالبناء للنواة الجديدة، وعادة ما يكون السبب هو عدم تثبيت الترويسات (headers) المطابقة. يعرض dkms status ما تم بناؤه لكل نواة. يقوم sudo apt install -y linux-headers-$(uname -r) ثم sudo dkms autoinstall بإعادة البناء، ويعيد sudo zpool import tank التجمع للعمل.

التجمع ممتلئ رغم حذف الملفات. تبقى البيانات المحذوفة على القرص طالما أن هناك لقطة (snapshot) تشير إليها، لذا يختلف du و df في النتائج. يقسم zfs list -o space -r tank الاستخدام إلى USEDDS و USEDSNAP، ووجود قيمة كبيرة في USEDSNAP هو السبب. احذف اللقطات القديمة باستخدام sudo zfs destroy tank/data@2026-06-01 وستستعيد المساحة.

تزايد عدادات CKSUM في zpool status. هناك طبقة تحت ZFS أعادت بيانات تالفة. في حالة الـ mirror، يعتبر العداد تحذيراً وقد تم إصلاح الكتلة. في التجمع المكون من قرص واحد، يكون الملف مفقوداً، ويحدد zpool status -v اسمه، وعليك استعادة هذا الملف من نسخة احتياطية لا توجد في هذا التجمع.

الخادم بطيء ويستخدم الـ swap. حدد سقفاً لـ ARC كما هو موضح أعلاه، ثم شغّل arc_summary وراقب نسبة النجاح (hit ratio). إذا كان حجم ARC صغيراً جداً بحيث لا يستوعب مجموعة العمل، فهذا يعني أن كل عملية قراءة تذهب إلى القرص، وهي النقطة التي يكون فيها نظام ملفات عادي يستخدم ذاكرة التخزين المؤقت للصفحات (page cache) أفضل لك.

FAQ

ما مقدار ذاكرة الوصول العشوائي (RAM) التي يحتاجها ZFS على خادم افتراضي (VPS)؟

يعمل ZFS على خادم بذاكرة 2 GB. السؤال الحقيقي هو ما الذي يتبقى لتطبيقك. بدون ضبط، يسمح OpenZFS 2.3 لـ ARC بالنمو إلى القيمة الأكبر بين (إجمالي الذاكرة ناقص 1 GiB) و(5/8 من إجمالي الذاكرة)، لذا يمكن لخادم بذاكرة 4 GB تخصيص 3 GiB للذاكرة المؤقتة. اضبط zfs_arc_max على قيمة يمكن لحمل العمل الخاص بك الاستغناء عنها، ثم أكّد ذلك بقراءة السطر c_max من /proc/spl/kstat/zfs/arcstats.

هل تُعد لقطة ZFS (Snapshot) نسخة احتياطية؟

لا. تعيش اللقطة في نفس مجمع التخزين (pool) الخاص بالبيانات. هي تحميك من rm الخاطئ أو فشل الترقية، لكنها تضيع بضياع المجمع أو الخادم. حوّلها إلى نسخة احتياطية عبر إرسالها إلى جهاز آخر باستخدام zfs send، أو عبر تشغيل أداة نسخ احتياطي تكتب إلى وحدة تخزين لا يتحكم فيها هذا الخادم.

هل يعمل ZFS بنفس الطريقة على FreeBSD و Linux؟

نفس قاعدة الكود منذ OpenZFS 2.0 في ديسمبر 2020، ونفس الأوامر، ونفس تنسيق القرص، ويمكن نقل المجمعات بينهما. الفرق يكمن في التغليف. توفر FreeBSD نظام ZFS ضمن النظام الأساسي. أما في Linux، فكل توزيعة تقرر طريقتها: تبني Ubuntu الوحدة (module) ضمن حزم النواة الخاصة بها، بينما تبنيها Debian على جهازك باستخدام DKMS، لذا قد تتركك ترقية النواة بدون وحدة حتى تكتمل عملية إعادة البناء بنجاح.

هل يستطيع ZFS إصلاح التلف على خادم افتراضي بقرص واحد؟

يكتشف ZFS التلف ويحدد الملف المتضرر، لكنه لا يستطيع إصلاحه لأن الإصلاح يتطلب نسخة ثانية من الكتلة (block). يمنحك zfs set copies=2 على مجموعة البيانات (dataset) تلك النسخة الثانية مقابل ضعف المساحة، وهو ما يعالج الكتلة التالفة ولكن ليس فقدان وحدة التخزين بالكامل. الحل الذي يعالج التلف فعلياً هو استخدام مرآة (mirror) عبر وحدتي تخزين.

هل يؤدي الضغط إلى إبطاء الخادم؟

عادةً ما يجعل lz4 الخادم أسرع. الكتل المضغوطة تعني كتابة وقراءة بايتات أقل، وتكلفة المعالج لكل كتلة ضئيلة مقارنةً بالمساحة التي يوفرها على القرص. اضبط compression=lz4 في جذر المجمع (pool root) لترثه كل مجموعات البيانات، ثم تحقق من zfs get compressratio tank بمجرد كتابة بيانات فعلية.