انتخاب فایلسیستم یکی از تصمیم‌هایی است که معمولاً در لحظهٔ نصب سیستم‌عامل و بدون فکر گرفته می‌شود؛ نصب‌کنندهٔ Ubuntu به‌طور پیش‌فرض ext4 می‌سازد و AlmaLinux و Rocky Linux به‌طور پیش‌فرض XFS. اما همین انتخاب ساده، سال‌ها بعد تعیین میکند که آیا می‌توانید پارتیشن را کوچک کنید، دیتابیس شما زیر بار همزمان چه رفتاری دارد و چند میلیون فایل کوچک هاست اشتراکی تا کجا جا می‌شوند. در این مقاله تفاوت‌های واقعی ext4 و XFS را از نظر معماری، محدودیت‌ها، عملکرد برای MySQL و PostgreSQL و نگهداری روزمره بررسی می‌کنیم تا برای سرور بعدی خود آگاهانه تصمیم بگیرید.
فایلسیستم چه نقشی در سرور دارد و چرا تغییر بعدی آن پرهزینه است
فایلسیستم لایه‌ای است که بین برنامه‌ها و دستگاه بلاکی (دیسک، پارتیشن یا Logical Volume) قرار می‌گیرد و وظیفهٔ آن نگاشت نام فایل‌ها به بلاک‌های فیزیکی، مدیریت متادیتا (مالک، دسترسی، زمان‌ها) و تضمین سازگاری داده بعد از قطع برق یا کرش است. هر دو گزینهٔ ما ژورنال‌دار هستند؛ یعنی قبل از اعمال تغییر در ساختار، آن را در ژورنال ثبت می‌کنند تا پس از خرابی بتوان حالت سازگار را بازسازی کرد.
چرا نمی‌توان بعداً به‌سادگی آن را عوض کرد
تبدیل مستقیم ext4 به XFS یا برعکس وجود ندارد. تنها راه، ساخت فایلسیستم جدید روی یک دیسک دیگر و کپی کامل دادهها با rsync یا بازیابی از بکاپ است که برای سروری با چند ترابایت داده و صدها سایت فعال، به معنای ساعت‌ها Downtime یا یک پروژهٔ مهاجرت تمام‌عیار است. به همین دلیل بهتر است تصمیم را پیش از تحویل سرور بگیرید، نه بعد از آن.
ext4: فایلسیستم پیش‌فرض و محافظه‌کار لینوکس
ext4 ادامهٔ خانوادهٔ ext2/ext3 است و از سال ۲۰۰۸ در کرنل اصلی قرار دارد. فلسفهٔ آن سازگاری عقب‌رو و پایداری است و تقریباً هر مدیر سروری با ابزارهای آن آشناست.
نقاط قوت ext4
مهم‌ترین مزیت عملی ext4 امکان کوچک کردن پارتیشن است؛ با resize2fs می‌توانید (به‌صورت آفلاین) فضای یک Volume را کم کنید و به Volume دیگری بدهید. ویژگی fast_commit که از کرنل 5.10 اضافه شد، تأخیر fsync را برای بارهای کاری دیتابیس کاهش میدهد. پشتیبانی از حالت‌های مختلف ژورنال (data=ordered پیش‌فرض، data=journal برای حداکثر ایمنی) و قابلیت رمزنگاری fscrypt نیز از مزایای آن است. همچنین حذف دایرکتوری‌هایی با صدها هزار فایل کوچک روی ext4 معمولاً سریعتر از XFS انجام می‌شود.
محدودیت‌های ext4
تعداد inodeها در لحظهٔ ساخت با mkfs ثابت می‌شود و بعداً قابل افزایش نیست؛ اگر سرور هاست اشتراکی شما با پیش‌فرض‌ها ساخته شده باشد، ممکن است با وجود فضای خالی، با خطای «No space left on device» ناشی از اتمام inode روبه‌رو شوید. ext4 همچنین از reflink (کپی بدون تکرار داده) پشتیبانی نمی‌کند.
XFS: ساخته‌شده برای فایلهای بزرگ و همروندی بالا
XFS در دههٔ ۱۹۹۰ توسط SGI برای فایلهای ویدئویی عظیم طراحی شد و از RHEL 7 به بعد فایلسیستم پیش‌فرض خانوادهٔ Red Hat است.
معماری Allocation Group
XFS دیسک را به چند Allocation Group مستقل تقسیم میکند که هر کدام ساختار داده و قفل‌های خود را دارند. نتیجه این است که چند نخ (thread) می‌توانند همزمان و بدون انتظار برای یکدیگر فایل بسازند یا بنویسند؛ دقیقاً همان الگویی که در دیتابیس‌های پرتراکنش و سرورهایی با ده‌ها هسته دیده می‌شود. inodeها به‌صورت پویا تخصیص می‌یابند و عملاً هرگز تمام نمی‌شوند (محدودیت پیش‌فرض imaxpct برابر ۲۵ درصد فضای کل است). از کرنل 4.9 به بعد XFS از reflink پشتیبانی میکند و دستور cp --reflink=always یک فایل چند گیگابایتی را ظرف یک لحظه کپی میکند، بدون آن‌که فضای اضافی اشغال شود.
محدودیت‌ها: کوچکسازی و فایلهای کوچک
بزرگ‌ترین نقطه‌ضعف XFS این است که قابل کوچک شدن نیست؛ xfs_growfs فقط رشد میدهد. اگر روی LVM یک Volume را بیش از حد بزرگ ساخته باشید، راهی جز بکاپ و ساخت مجدد ندارید. همچنین XFS فقط متادیتا را ژورنال میکند و حالتی معادل data=journal ندارد. در بارهای کاری با میلیون‌ها فایل بسیار کوچک (کش‌های PHP، ایمیل‌های Maildir) تفاوت عملکرد در حذف و پیمایش دایرکتوری به نفع ext4 است، هرچند در نسخه‌های اخیر این فاصله کمتر شده است.
مقایسهٔ فنی ext4 و XFS در یک نگاه
| ویژگی | ext4 | XFS |
|---|---|---|
| حداکثر اندازهٔ فایلسیستم | 1 EiB | 8 EiB |
| حداکثر اندازهٔ یک فایل | 16 TiB (بلاک 4K) | 8 EiB |
| کوچک کردن (shrink) | بله، آفلاین با resize2fs | خیر |
| بزرگ کردن آنلاین | بله | بله (xfs_growfs) |
| تعداد inode | ثابت در زمان mkfs | پویا |
| reflink / کپی بدون تکرار | خیر | بله |
| ژورنال داده | بله (data=journal) | فقط متادیتا |
| ابزار بررسی | e2fsck (زمان‌بر روی حجم بالا) | xfs_repair (موازی و سریع) |
| پیش‌فرض در | Ubuntu، Debian | AlmaLinux، Rocky، RHEL |
کدام فایلسیستم برای دیتابیس بهتر است؟
پاسخ کوتاه: هر دو پشتیبانی رسمی دارند و در اکثر سرورها گلوگاه، فایلسیستم نیست بلکه دیسک و کوئری‌هاست؛ اما تفاوت‌هایی در مقیاس بزرگ خود را نشان میدهد.
MySQL و MariaDB
InnoDB با innodb_flush_method=O_DIRECT بافر کش سیستم‌عامل را دور می‌زند و مستقیماً با فایلسیستم کار میکند. در این حالت معماری چند Allocation Group در XFS به نوشتن همزمان روی چندین فایل جدول (با innodb_file_per_table) کمک میکند و مستندات Percona نیز برای سرورهای با همروندی بالا XFS را ترجیح میدهند. برای یک فروشگاه متوسط با چند گیگابایت داده، تفاوت قابل اندازهگیری نیست.
PostgreSQL
PostgreSQL به‌شدت به fsync متکی است و بر خلاف InnoDB، از page cache سیستم‌عامل استفاده میکند. تجربهٔ جامعهٔ PostgreSQL نشان میدهد ext4 با fast_commit و XFS عملکرد بسیار نزدیکی دارند؛ نکتهٔ مهم‌تر، قرار دادن دایرکتوری pg_wal روی یک Volume جداگانه و استفاده از گزینهٔ noatime است.
گزینههای mount که برای دیتابیس اهمیت دارند
گزینهٔ noatime از نوشتن زمان آخرین دسترسی در هر خواندن جلوگیری میکند و در هر دو فایلسیستم باید فعال باشد. در XFS گزینهٔ logbsize=256k اندازهٔ بافر ژورنال را بزرگ میکند و برای متادیتای پرتغییر مفید است. گزینهٔ nobarrier که زمانی برای سرعت پیشنهاد می‌شد، از کرنل 4.19 حذف شده و استفاده از آن در فایل /etc/fstab باعث شکست mount می‌شود. TRIM را نیز به‌جای گزینهٔ discard با سرویس fstrim.timer انجام دهید.
کدام برای هاست اشتراکی و وب‌سرور مناسب‌تر است؟
inode و صدها هزار فایل کوچک
یک سرور هاست اشتراکی به‌راحتی چند میلیون فایل دارد: هستهٔ وردپرس هر سایت حدود دو هزار فایل است و ایمیل‌ها و کش‌ها فایلهای ریز بی‌شماری می‌سازند. اگر ext4 را با نسبت پیش‌فرض (یک inode به ازای هر 16 کیلوبایت) ساخته باشید، معمولاً کافی است؛ اما برای پارتیشن /home یا /var/mail بهتر است هنگام ساخت از -T news یا -i 8192 استفاده کنید تا تعداد inode دو برابر شود. در XFS این نگرانی اساساً وجود ندارد.
تعامل با LVM و اسنپ‌شات
اگر از LVM استفاده می‌کنید و قصد دارید بعدها فضای Volumeها را جابه‌جا کنید، ext4 انعطاف بیشتری میدهد چون می‌تواند کوچک شود. در مقابل اگر فضای دیسک فقط رشد میکند (رایج‌ترین حالت در سرور اختصاصی ایران که با دیسکهای بزرگ تحویل می‌شود)، XFS با xfs_growfs بدون unmount و ظرف چند لحظه بزرگ می‌شود. هر دو فایلسیستم با اسنپ‌شات LVM سازگارند، اما برای mount کردن اسنپ‌شات XFS باید گزینهٔ nouuid را بدهید، چون UUID تکراری را رد میکند.
ساخت، mount و رشد: دستورات عملی
ساخت و تنظیم ext4
mkfs.ext4 -L data -i 8192 /dev/vg0/data
tune2fs -l /dev/vg0/data | grep -i 'inode count'
mount -o noatime /dev/vg0/data /data
resize2fs /dev/vg0/data # رشد آنلاین پس از lvextendبرای کوچک کردن، ابتدا umount، سپس e2fsck -f و resize2fs و در نهایت lvreduce را اجرا کنید؛ ترتیب برعکس، دادهها را نابود میکند.
ساخت و تنظیم XFS
mkfs.xfs -L data /dev/vg0/data
xfs_info /data
mount -o noatime,logbsize=256k /dev/vg0/data /data
xfs_growfs /data # رشد آنلاین، بدون unmountنکات فایل fstab
در هر حالت به‌جای مسیر دستگاه از UUID استفاده کنید (blkid آن را نشان میدهد) تا با تغییر ترتیب دیسک‌ها بوت شکست نخورد. در ستون آخر fstab، برای XFS عدد صفر بگذارید چون بررسی دوره‌ای ندارد و برای ext4 نیز نسخه‌های اخیر e2fsprogs بررسی زمان‌مند را غیرفعال کرده‌اند. گزینهٔ nofail را برای دیسکهای غیرسیستمی اضافه کنید تا در صورت نبود دیسک، بوت متوقف نشود. روی سرور مجازی نیز همین قواعد برقرار است؛ فقط دیسک را ابتدا از پنل بزرگ کنید، سپس پارتیشن را با growpart و بعد فایلسیستم را رشد دهید.
جمع‌بندی
برای اکثر سرورهای وب و هاست اشتراکی، هر دو فایلسیستم انتخاب درستی هستند و تفاوت عملکرد روزمره ناچیز است. اگر دیسک شما فقط رشد میکند، تعداد فایل‌ها نامشخص است یا دیتابیس با همروندی بالا دارید، XFS انتخاب مطمئن‌تری است. اگر به کوچک کردن Volumeها، ژورنال کامل داده یا کار با ابزارهای قدیمی‌تر نیاز دارید، ext4 را انتخاب کنید. در هر دو حالت noatime را فعال کنید، TRIM را زمان‌بندی کنید و از UUID در fstab استفاده کنید.
سوالات متداول
آیا میتوان ext4 را بدون از دست دادن داده به XFS تبدیل کرد؟
خیر. هیچ ابزار تبدیل درجایی وجود ندارد. باید فایلسیستم جدید را روی دیسک دیگری بسازید، دادهها را با rsync -aHAX منتقل کنید و سپس نقطهٔ mount را عوض کنید.
XFS برای سرور مجازی کمحجم هم مناسب است؟
بله. XFS روی دیسکهای 20 تا 40 گیگابایتی هم بدون مشکل کار میکند و سربار حافظهٔ محسوسی ندارد. تنها محدودیت، ناممکن بودن کوچکسازی است که در سرور مجازی معمولاً نیازی به آن نیست.
چگونه بفهمم سرور من از کدام فایلسیستم استفاده میکند؟
دستور df -Th نوع فایلسیستم هر نقطهٔ mount را در ستون Type نشان میدهد. برای جزئیات بیشتر، lsblk -f یا findmnt گزینههای mount فعلی و UUID را هم نمایش میدهند.
آیا XFS سریعتر از ext4 است؟
در نوشتن موازی روی فایلهای بزرگ و در سرورهای چندهستهای، XFS معمولاً برتری دارد؛ در حذف و پیمایش انبوه فایلهای کوچک، ext4 اغلب جلوتر است. برای وبسایتهای معمولی تفاوت در حد خطای اندازهگیری است.
با پر شدن inode در ext4 چه کنیم؟
ابتدا با df -i تأیید کنید که مشکل inode است. سپس فایلهای ریز بیمصرف (کش، session، لاگهای قدیمی) را حذف کنید. راهحل دائمی، ساخت مجدد فایلسیستم با نسبت inode بالاتر یا مهاجرت به XFS است، چون تعداد inode در ext4 بعد از ساخت قابل تغییر نیست.
