اختيار نظام الملفات لخوادم الذكاء الاصطناعي: XFS وZFS وext4، ولماذا لا يُعدّ Btrfs من بينها؟

إذا أنفقت للتو 40 ألف يورو على وحدات معالجة الرسومات، فإن نظام الملفات الذي ستخزن عليه بياناتك يستحق أكثر من مجرد خمس دقائق من التفكير. يقوم مُثبِّت أوبونتو بتثبيت نظام ext4 تلقائيًا على كل شيء؛ وهذا هو الحل الأمثل للعديد من تطبيقات الذكاء الاصطناعي، ولكنه ليس كذلك في بعض الحالات. اختر نظام ملفات خاطئًا لحجم بيانات يبلغ 50 تيرابايت، وستفقد معدل نقل البيانات، أو ستفقد بياناتك، أو ستشاهد برنامج DataLoader الخاص بك يتوقف عن العمل بسبب عنق زجاجة في البيانات الوصفية.

يتناول هذا الموضوع تحديد نظام الملفات المناسب لموقعه على خادم الذكاء الاصطناعي من فئة Kentino (4-8 وحدات معالجة رسومية، قرص تمهيد NVMe، قرص تخزين مؤقت NVMe، طبقة تخزين أبطأ). نظام التشغيل: Ubuntu 22.04 / 24.04، نواة 6.x.

نسخة قصيرة

نسخة من فقرة واحدة: ext4 لنظام التشغيل، وXFS للتخزين المؤقت السريع، وZFS حيث تكون سلامة البيانات أهم من آخر 10% من الإنتاجية، ولا يوجد Btrfs في بيئة الإنتاج.

ext4 — الإعداد الافتراضي الممل الذي يكون صحيحًا في الغالب

كان نظام الملفات ext4 هو النظام الافتراضي في أنظمة أوبونتو، وديبيان، وفيدورا، وRHEL لأكثر من عقد من الزمان. وهو نظام معروف جيدًا، ويمكن استعادته باستخدام fsck16 تيرابايت لكل ملف، 1 إكسابايت لكل وحدة تخزين. لا شيء مثير للاهتمام - وهذا هو الهدف.

استخدم نظام الملفات ext4 للجذر (كل قرص USB حي لنظام Ubuntu يعرف كيفية إصلاح هذه المشكلة؛ لكن عددًا أقل بكثير يعرف كيفية استيراد zpool)، لـ /homeوكذلك بالنسبة لمخازن صور الأجهزة الافتراضية على نطاق صغير إلى متوسط.

أين يتوقف نظام الملفات ext4 عن كونه صحيحًا: منافذ إدخال/إخراج متوازية واسعة (تقوم سجلاتها بتسلسل تحديثات البيانات الوصفية - عشرون عامل DataLoader على وحدة تخزين ext4 واحدة، عنق زجاجة على السجل قبل وقت طويل من تشبع NVMe)؛ ملفات ضخمة واحدة (تمت معالجتها، لكن تخصيص الامتداد أقل ملاءمة من XFS للملفات المتسلسلة التي يزيد حجمها عن 100 جيجابايت - أجزاء التدريب، ونقاط التفتيش، ومجموعات الفيديو)؛ لقطات (لا يوجد شيء أصليًا؛ تعمل لقطات LVM الرقيقة ولكنها غير عملية).

mkfs.ext4 -L root /dev/nvme0n1p2

إذا وجدت نفسك تقوم بضبط نظام الملفات ext4 بشكل غير تقليدي لحمل عمل الذكاء الاصطناعي، فقد اخترت نظام الملفات الخاطئ.

نظام ملفات XFS — الحل الأمثل للبيانات المؤقتة وبيانات التدريب

كان نظام الملفات XFS نظام ملفات من شركة SGI مخصصًا لعمليات الإدخال/الإخراج التسلسلية عالية الإنتاجية على المصفوفات الكبيرة. ويتوافق هذا الإرث مع أحمال عمل الذكاء الاصطناعي بشكل شبه مثالي: ملفات كبيرة (أجزاء التدريب، ملفات Parquet، ملفات tar لمجموعات بيانات الويب، نقاط التحقق)، وقراءات تسلسلية، والعديد من القراء المتوازيين، والقدرة على تحمل "إعادة توليد البيانات عند حدوث حمل العمل".

ما يفعله نظام الملفات XFS ولا يفعله نظام الملفات ext4: مجموعات التخصيص — ينقسم المجلد إلى 4-32 مجموعة مستقلة تقرأ وتكتب بالتوازي دون قفل سجل عالمي، وهو بالضبط ما يريده برنامج تحميل البيانات متعدد العمال؛ تخصيص مسبق متأخر وتخميني لذلك تحصل عمليات الكتابة المتسلسلة الكبيرة على امتدادات متجاورة؛ لا يوجد حد عملي لحجم الملف (8 EB)؛ و xfs_growfs للحصول على تمديد موثوق به بسطر واحد بعد نمو RAID.

ما لا يفعله: لا لقطات أصلية، ولا مجموعات التحقق من بيانات الملفات (البيانات الوصفية محمية بواسطة CRC منذ عام 2014)، ولا تقليص - فقط تكبير.

معقول mkfs.xfs بالنسبة لوحدة تخزين مؤقتة NVMe RAID0 بحجم 8×، وكتلة بحجم 64 كيلوبايت:

# su = stripe unit = chunk size; sw = number of data disks
mkfs.xfs -f -d su=64k,sw=8 -l size=512m -L scratch /dev/md0

# largeio + swalloc: behave for >1 MB I/O
# allocsize=1g: preallocate aggressively for big sequential writes
# noatime: save a write per read under heavy DataLoader load
mount -o noatime,largeio,swalloc,allocsize=1g /dev/md0 /scratch

noatime و largeio الأهم هو أن نظام الملفات XFS على الملفات الصغيرة مقبول ولكنه ليس نقطة قوته - بالنسبة لمئات الملايين من الصور التي يقل حجمها عن 16 كيلوبايت، أعد تجميعها في webdataset / parquet / lmdb بدلاً من أنظمة ملفات التبديل (انظر أدناه).

نظام الملفات ZFS - الحل الأمثل عندما تكون سلامة البيانات، أو اللقطات، أو الضغط أمورًا بالغة الأهمية

نظام ZFS هو نظام ملفات، ومدير وحدات تخزين، وطبقة RAID برمجية في نظام واحد:

• التحقق من المجموع الاختباري من البداية إلى النهاية. تم اكتشاف تلف في البيانات أثناء القراءة، وتم تصحيحه تلقائيًا باستخدام تقنية التكرار. بالنسبة لمجموعة بيانات بحجم 50 تيرابايت مخزنة على قرص صلب تقليدي لمدة عامين، يُعد هذا الأمر مهمًا؛ أما بالنسبة لبيانات مؤقتة على قرص NVMe لمدة ستة أسابيع، فلا يُعدّ ذلك مهمًا.
• اللقطات والنسخ. ذري، نسخ عند الكتابة، مجاني فعلياً. أخذ لقطة قبل التشغيل، إنشاء نسخة مستنسخة، التراجع - سير العمل الذي صُمم نظام الملفات ZFS من أجله.
• ضغط مدمج. lz4 الوضع الافتراضي مُفعّل؛ zstd للحصول على نسب أفضل. بالنسبة للنصوص / JSON / Parquet، عادةً ما يكون الضغط الزيادات إنتاجية فعالة لأن تكلفة وحدة المعالجة المركزية أقل من تكلفة عمليات الإدخال/الإخراج الموفرة.
• ARC — ذاكرة تخزين مؤقتة للقراءة خاصة بها تعتمد على ذاكرة الوصول العشوائي، منفصلة عن ذاكرة التخزين المؤقتة للصفحات في نظام لينكس. بندقية القدم الشهيرة.
• RAID-Z الأصلي — لا يوجد mdadm.

ما لا يُجيد فعله في مجال الذكاء الاصطناعي: يستهلك ذاكرة الوصول العشوائي (يبلغ حجم ذاكرة التخزين المؤقت الافتراضية حوالي 50٪ من ذاكرة النظام - على خادم بسعة 512 جيجابايت، فإن 256 جيجابايت منها لا يمتلكها النواة فجأة، وتتعرض مهام التدريب التي تتوقع ذاكرة تخزين مؤقت للصفحات أو صفحات ضخمة للقتل بسبب نفاد الذاكرة؛ قم بتحديد حجم ذاكرة التخزين المؤقت)؛ ليست الأسرع بالنسبة للقراءات التسلسلية الخام (يتفوق نظام الملفات XFS المحسن جيدًا على NVMe RAID0 على ZFS بنسبة 15-30٪ - حيث أن التحقق من المجموع و COW يكلف دورات حقيقية)؛ يتجاهل O_DIRECT (جميع عمليات الإدخال/الإخراج تتم عبر ARC حسب التصميم - مناسب لمعظم أحمال العمل، وهو أمر غير متوافق تمامًا مع GPUDirect Storage).

ضبط ARC - المقبض الوحيد الذي يجب عليك ضبطه

عند تثبيت نظام Ubuntu + ZFS جديد على جهاز بسعة 512 جيجابايت، يخصص ZFS مساحة 256 جيجابايت لـ ARC. اضبط zfs_arc_max أثناء التثبيت، وليس بعد أول عملية نفاد للذاكرة.

# Cap ARC at 64 GB. Bytes, not GB. 64 * 1024^3 = 68719476736
echo "options zfs zfs_arc_max=68719476736" | sudo tee /etc/modprobe.d/zfs.conf
echo 68719476736 | sudo tee /sys/module/zfs/parameters/zfs_arc_max   # apply now
sudo update-initramfs -u                                             # persist

قاعدة عامة: حدد سقف ARC عند 10-20% من ذاكرة الوصول العشوائي للنظام على خادم الذكاء الاصطناعي. يُستخدم الحجم الكلاسيكي "2 جيجابايت أساسي + 1 جيجابايت لكل تيرابايت" لصناديق التخزين؛ أما على خادم الذكاء الاصطناعي، فإن معظم ذاكرة الوصول العشوائي (RAM) محجوزة لأوزان النموذج، والتنشيطات، وذاكرة التخزين المؤقت لصفحات الإطار.

تصميم ZFS منطقي لطبقة بيانات خادم الذكاء الاصطناعي

# 8 × 16 TB SAS in two RAID-Z2 vdevs (6+2 each) — two vdevs give 2× IOPS
zpool create -o ashift=12 \
  -O compression=zstd -O atime=off -O xattr=sa -O recordsize=1M \
  data \
  raidz2 /dev/sd[a-h] \
  raidz2 /dev/sd[i-p]

# Datasets sized for their workload
zfs create -o recordsize=1M   data/datasets       # large training shards
zfs create -o recordsize=128k data/checkpoints    # mixed size
zfs create -o recordsize=16k  data/metadata       # small files (json, yaml)

zfs snapshot data/datasets@pre-run-2026-05-14
zfs rollback data/datasets@pre-run-2026-05-14

ashift=12 = 4 كيلوبايت من الكتل — إذا حدث خطأ في هذا عند إنشاء المجموعة، فلن تتمكن من إصلاحه دون تدمير المجموعة. recordsize=1M بالنسبة لأحمال العمل ذات الملفات الكبيرة (الحجم الافتراضي 128 كيلوبايت صغير جدًا بالنسبة للأجزاء متعددة الجيجابايت). xattr=sa يخزن xattrs بشكل مضمن، وهو أسرع بكثير من الوضع الافتراضي.

نظام ملفات Btrfs - يُنصح عمومًا بتجنبه في بيئات الإنتاج الخاصة بالذكاء الاصطناعي

يتمتع نظام ملفات Btrfs بنفس مجموعة الميزات الأساسية لنظام ZFS - النسخ عند الكتابة (COW)، واللقطات، ومجاميع التحقق، وRAID المدمج. نظريًا، يبدو جيدًا؛ لكن عمليًا، لا ننصح باستخدامه على خوادم Kentino. فنظاما RAID 5 و6 يعانيان من أخطاء معروفة تؤدي إلى فقدان البيانات، ويشير المشروع نفسه إلى أنهما غير جاهزين للاستخدام في بيئات الإنتاج (نظاما RAID 1 و10 مستقران، بينما أوضاع التكافؤ غير مستقرة)؛ ويتدهور الأداء بشكل كبير مع نمط التجزئة الذي تنتجه أحمال عمل الذكاء الاصطناعي (نقاط التحقق من التدرج، وذاكرة التخزين المؤقت)؛ وينخفض ​​أداء اللقطات بشكل حاد بعد بضع مئات من اللقطات، وهو ما يصل إليه سير العمل لكل تجربة في غضون ثلاثة أشهر؛ كما أن أدواته أقل نضجًا من ZFS أو XFS فيما يتعلق بالنسخ المتماثل والمراقبة وجدولة التنظيف. إنه مناسب لأجهزة الكمبيوتر المحمولة. أما بالنسبة لخادم متعدد وحدات معالجة الرسومات (GPU) مع عشرات التيرابايت من بيانات التدريب، فننصح باختيار XFS أو ZFS.

تخطيطات RAID - ما الذي يجب إقران نظام الملفات به

في محركات الأقراص ذات سعة 16 تيرابايت فأكثر، قد تستغرق عملية إعادة بناء قرص واحد من 24 إلى 72 ساعة، واحتمالية حدوث عطل ثانٍ في نفس دفعة الأقراص خلال هذه الفترة ليست ضئيلة. لم يعد نظام التكافؤ الأحادي الخيار الآمن الافتراضي. استخدم Z2/RAID6 أو النسخ المتطابق.

الملفات الصغيرة مقابل الملفات الكبيرة

السؤال الذي يوقع الناس في حيرة أكبر من أي خيار لنظام الملفات: كيف يتصرف نظام الملفات الخاص بك مع 50 مليون صورة بحجم 4 كيلوبايت في شجرة دليل؟ الإجابة لكل نظام ملفات هنا: بشكل سيء.

تستهلك بيانات التعريف لكل ملف (العقدة، وعنوان المجلد، والطوابع الزمنية، والسمات الموسعة) ما بين 200 و500 بايت بغض النظر عن حجم الملف - إذ تستهلك 50 مليون ملف صغير ما بين 10 و25 جيجابايت من بيانات التعريف قبل تخزين بايت واحد من بيانات البكسل. ويؤدي نمط الفتح/القراءة/الإغلاق إلى استهلاك بيانات التعريف بشكل كبير، مما يعيق عمل برامج تحميل البيانات.

الحل ليس في نظام الملفات. لا تقم بتخزين الملفات الصغيرة كملفات. قم بتعبئة البيانات في ملفات webdataset / tar / parquet / lmdb / hdf5 / safetensors وقم ببثها بشكل متسلسل — PyTorch WebDataset يتوقع كل من NVIDIA DALI هذا. عندها يرى نظام الملفات عددًا صغيرًا من الملفات الكبيرة، وهو ما يجيده كل نظام ملفات هنا. إذا كنت مضطرًا للاحتفاظ بملفات فردية بكميات كبيرة، فإن ZFS مع recordsize=16k و xattr=sa هو الخيار الأقل سوءًا، لكن الحل الحقيقي هو إعادة التعبئة.

الإدخال/الإخراج المباشر، وذاكرة التخزين المؤقت للصفحات، و O_DIRECT

يعتمد PyTorch على ذاكرة التخزين المؤقت للصفحات في نظام Linux لمعالجة دورات البيانات المتكررة - الدورة الأولى من القرص، والدورات من الثانية إلى N من ذاكرة الوصول العشوائي. تستخدم بعض أحمال العمل O_DIRECT لتجاوز ذاكرة التخزين المؤقت لعمليات القراءة الكبيرة التي يتم فيها الوصول إلى البيانات مرة واحدة فقط. أما تقنية GPUDirect Storage من NVIDIA فتتجاوز ذلك، حيث تقوم بتوصيل البيانات مباشرةً من NVMe إلى وحدة معالجة الرسومات (GPU) عبر DMA.

ext4 و XFS يدعمان O_DIRECT بشكل صحيح — إدخال/إخراج مباشر متوافق، بدون ذاكرة تخزين مؤقتة للصفحات. يتجاهل ZFS O_DIRECT (جميع عمليات الإدخال/الإخراج تتم عبر ذاكرة التخزين المؤقت ARC، حسب التصميم): مناسب لمعظم أحمال العمل، ولكنه غير متوافق تمامًا مع وحدة تخزين GPUDirect. المحاذاة مهمة - يجب أن تتوافق المخزن المؤقت والإزاحة مع حجم كتلة الجهاز (عادةً 4 كيلوبايت).

إذا كنت تخطط لاستخدام وحدة تخزين GPUDirect لتغذية جهاز يحتوي على 8 وحدات معالجة رسومية بكامل عرض النطاق الترددي، /data يجب أن يكون نظام الملفات XFS على وحدة تخزين NVMe. إذا كنت لا تعرف ما هو GPUDirect Storage وكان التدريب يعتمد بشكل كبير على قدرة الحوسبة، فلن تحتاجه بعد.

مسارات متعددة NVMe

يُعرض منفذا NVMe U.2 / E1.S المزدوجان كمسارين PCIe لكل منهما. يدعم برنامج تشغيل NVMe في نظام Linux تعدد المسارات بشكل أصلي (nvme_core.multipath=Y(وهو الوضع الافتراضي في أنظمة التشغيل الحديثة)، مما يوفر تجاوز الأعطال وموازنة الأحمال بالتناوب. غير مرئي على مستوى نظام الملفات، ولكنه مهم لتجاوز الأعطال (بدونه، يؤدي فشل المسار/محول المضيف إلى اختفاء القرص وتعطل نظام الملفات) وعرض النطاق الترددي (يصل محرك أقراص U.2 متعدد المسارات إلى حوالي 14 جيجابايت/ثانية مقابل 7 جيجابايت/ثانية لمسار واحد).

cat /sys/module/nvme_core/parameters/multipath   # expect: Y
nvme list-subsys

بالنسبة لأجهزة الكمبيوتر الشخصية المزودة بوحدات تخزين M.2 NVMe (مثل أجهزة سطح المكتب من فئة 5090)، لا يُعد تعدد المسارات ذا أهمية، إذ يكفي مسار واحد. أما بالنسبة لأجهزة EPYC ذات 8 وحدات معالجة رسومية، والتي تستخدم وحدات تخزين U.2 / E1.S المخصصة للمؤسسات في لوحة خلفية ثنائية المتحكم، فيُفضل تركه مُفعلاً.

تكاليف التحقق من المجموع الاختباري

على خادم EPYC ذي 64 نواة، يكون التأثير غير ملحوظ. أما على خادم Xeon ذي 16 نواة تحت ضغط مستمر، فقد يستهلك نظام ZFS ما بين 5 و10% من قدرة وحدة المعالجة المركزية الفعلية - ويعتمد مدى أهمية ذلك على ما إذا كان التدريب يعتمد على وحدة المعالجة المركزية في مرحلة المعالجة المسبقة (غالباً ما يكون كذلك في مجال الرؤية الحاسوبية) أو على وحدة معالجة الرسومات (غالباً ما يكون كذلك في نماذج التعلم العميق الكبيرة).

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

نظام ملفات الشبكة (NFS) لمجموعات البيانات المشتركة عبر عقد المجموعة

بمجرد امتلاكك لأكثر من خادم، يصبح مكان تخزين البيانات مثيرًا للاهتمام. ثلاثة أنماط:

1. انسخ إلى كل عقدة. بسيط، لكنه يهدر السعة. مناسب لحجم أقل من 1 تيرابايت وعدد عقد لا يتجاوز 4.
2. نظام ملفات الشبكة (NFS) من خادم تخزين مخصص. نسخة أساسية واحدة. الشبكة هي عنق الزجاجة - الحد الأدنى 25 جيجابت إيثرنت، و100 جيجابت إيثرنت للتدريب متعدد العقد.
3. نظام الملفات المتوازي (BeeGFS، Lustre، WekaFS). قدرة رفع أكبر، ومقاييس تتجاوز حدود ما يفشل فيه نظام NFS.

بالنسبة لـ 1-4 عقد، يُعدّ NFS الخيار الأمثل. الخادم: XFS على RAID10 NVMe، مُصدّر عبر NFSv4. العميل: مُثبّت باستخدام nconnect=8 للتوازي عبر اتصالات TCP.

# Server /etc/exports
/data/shared 10.0.10.0/24(rw,async,no_subtree_check,no_root_squash)

# Client
mount -t nfs -o vers=4.2,nconnect=8,proto=tcp,rsize=1048576,wsize=1048576 \
  storage01:/data/shared /mnt/shared

NFS عبر 100 جيجابت إيثرنت مع nconnect=8 يوفر معدل نقل بيانات مستدام يتراوح بين 8 و10 جيجابايت/ثانية، وهو ما يكفي لتشغيل 16 وحدة معالجة رسومية في عمليات التدريب النموذجية للرؤية الحاسوبية أو التعلم العميق للتعلم. أما ما عدا ذلك، فنظام ملفات BeeGFS / Lustre موضوع لمقال آخر.

مثال كامل: معالج EPYC ثماني وحدات معالجة رسومية، 24 وحدة تخزين NVMe + 8 وحدات تخزين SAS

2× 480 GB NVMe  (boot)     → md RAID1   → ext4 → /
8× 7.68 TB NVMe (scratch)  → md RAID0   → XFS  → /scratch
8× 7.68 TB NVMe (data)     → md RAID10  → XFS  → /data
8× 16 TB SAS    (archive)  → 2× RAID-Z2 → ZFS  → /archive

ZFS ARC: 64 GB of 512 GB RAM. NVMe multipath: on. NFS export: /data over 100 GbE.

mkfs.ext4 -L root /dev/md0
mkfs.xfs -f -d su=64k,sw=8 -l size=512m -L scratch /dev/md1
mkfs.xfs -f -d su=64k,sw=4 -l size=512m -L data    /dev/md2

zpool create -o ashift=12 \
  -O compression=zstd -O atime=off -O xattr=sa -O recordsize=1M \
  archive raidz2 /dev/sd[a-h]

echo "options zfs zfs_arc_max=68719476736" > /etc/modprobe.d/zfs.conf
update-initramfs -u

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

---

هذا جزء من ويكي كينتينو، وهي سلسلة مرجعية حول الحوسبة والتخزين في مجال الذكاء الاصطناعي، والأنظمة التي تربط بينهما. نرحب بالتعليقات والتصويبات على info@kentino.com.