مدیریت مصرف رم ZFS در سرورهای مجازی VPS

مزایای ZFS و هزینه‌های آن

ZFS در FreeBSD و Linux اکنون از یک کد منبع واحد به نام OpenZFS استفاده می‌کند، بنابراین قابلیت‌های آن در هر دو سیستم یکسان است. سروری که از ZFS استفاده می‌کند، از داده‌های دارای checksum، اسنپ‌شات‌هایی که تا زمان تغییر داده‌ها هیچ هزینه‌ای ندارند، قابلیت تکثیر (replication) با zfs send و فشرده‌سازی که تنها با تغییر یک ویژگی فعال می‌شود، بهره‌مند می‌گردد. هزینه‌ای که ZFS تحمیل می‌کند، حافظه است: ARC (حافظه کش تطبیقی جایگزین) به‌صورت پیش‌فرض بخش بزرگی از RAM را اشغال می‌کند و در یک VPS (سرور مجازی خصوصی) با 2 GB یا 4 GB حافظه، این دقیقاً همان مقداری است که برنامه شما به آن نیاز دارد.

این راهنما ZFS را از دیدگاه یک VPS اجاره‌ای با یک یا دو دیسک مجازی ارزیابی می‌کند، نه یک دستگاه ذخیره‌سازی با چهل جایگاه درایو. قابلیت‌هایی که در این مقیاس کاربردی باقی می‌مانند، ارزش صرف وقت شما را دارند. بخش‌هایی که در این شرایط کارایی ندارند، مواردی هستند که باید پیش از ساختن یک pool از آن‌ها آگاه باشید.

OpenZFS در FreeBSD و Linux: یک کد منبع، دو شیوه بسته‌بندی

سیستم‌عامل FreeBSD از سال 2008 و نسخه 7.0، ZFS را در سیستم پایه خود گنجانده است؛ در ابتدا به عنوان یک قابلیت آزمایشی. از زمان انتشار OpenZFS 2.0 در دسامبر 2020، FreeBSD و Linux از یک درخت منبع واحد برای ساخت استفاده می‌کنند، بنابراین zfs و zpool در هر دو سیستم رفتار یکسانی دارند و pool ایجاد شده در یکی، در دیگری قابل import است.

دلیل اینکه ZFS در Linux به صورت یک بسته (package) ارائه می‌شود اما در FreeBSD بخشی از سیستم پایه است، به مجوز (licensing) بازمی‌گردد. OpenZFS تحت مجوز CDDL (مجوز توسعه و توزیع مشترک) است. هسته Linux تحت مجوز GPL (مجوز عمومی همگانی) نسخه 2 قرار دارد. پروژه هسته، این دو مجوز را ناسازگار می‌داند، بنابراین کد ZFS در شاخه اصلی (mainline) Linux ادغام نمی‌شود و هر توزیع‌کننده تصمیم می‌گیرد که چگونه آن را ارائه دهد. FreeBSD چنین تداخلی ندارد، بنابراین ZFS به سادگی در آن موجود است. این تمام ماجرای عملی است: یک تفاوت در بسته‌بندی، و هیچ موضوعی وجود ندارد که نیاز باشد در مورد آن موضع‌گیری کنید.

سرویس SSD Nodes ایمیج‌های FreeBSD ارائه نمی‌دهد، بنابراین روی سروری که در اینجا اجاره می‌کنید، بخش Linux این راهنما کاربرد دارد. اگر در جای دیگری از FreeBSD استفاده می‌کنید، یک سرور FreeBSD با ZFS ارائه می‌شود که نیازی به ساخت ماژول یا نگرانی بابت ارتقای هسته ندارد.

نصب ZFS و ایجاد یک pool

در Ubuntu، ماژول درون بسته‌های هسته (kernel) قرار دارد، بنابراین شما فقط دستورات را نصب می‌کنید.

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

دستور zfs version دو خط را چاپ می‌کند: نسخه userland و نسخه ماژول هسته. وجود تنها یک خط به این معنی است که ماژول بارگذاری نشده است. این بسته در کامپوننت 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-... را چاپ می‌کند که چند دقیقه زمان می‌برد. به خاطر داشته باشید که این یعنی: هر ارتقای هسته باعث بازسازی آن می‌شود و اگر ساخت ماژول با خطا مواجه شود، تا زمانی که آن را رفع نکنید، pool شما mount نخواهد شد.

در FreeBSD نیازی به نصب چیزی نیست. سرویس را فعال و اجرا کنید.

sysrc zfs_enable=YES
service zfs start

حالا نوبت ایجاد pool است. ابتدا مسیرهای پایدار دستگاه‌ها را بررسی کنید، زیرا /dev/vdb بر اساس ترتیب شناسایی اختصاص می‌یابد و ممکن است با اتصال یک volume جدید تغییر کند.

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 کوچک‌ترین بلاک pool را روی 4 KiB تنظیم می‌کند که با SSDهای امروزی مطابقت دارد و پس از ایجاد pool قابل تغییر نیست.

بیشتر ایمیج‌های اجاره‌ای از یک پارتیشن ریشه ext4 بوت می‌شوند، بنابراین ZFS در اینجا یک pool داده روی volume دوم است و نه فایل‌سیستم ریشه. پیش از ساختن pool، مطمئن شوید که دستگاه همان چیزی است که فکر می‌کنید، زیرا تأیید دیسک NVMe خریداری‌شده یک دقیقه زمان می‌برد، اما بازسازی آن یک بعدازظهر کامل وقت شما را خواهد گرفت.

Checksumها تنها در صورتی تعمیر را انجام می‌دهند که pool دارای افزونگی باشد

هر بلاکی که ZFS می‌نویسد دارای یک checksum است و هر عملیات خواندن، آن را تایید می‌کند. تشخیص خطا همیشه کار می‌کند، اما تعمیر به یک نسخه دوم نیاز دارد.

در یک pool تک‌دیسکی، 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 نمی‌تواند آن را تعمیر کند، زیرا نسخه دومی در pool وجود ندارد که بتوان از روی آن تعمیر را انجام داد.

در حالت mirror، همان عملیات خواندن از سمت سالم انجام می‌شود، بلاک آسیب‌دیده بازنویسی می‌گردد و رویداد در ستون CKSUM از zpool status ظاهر می‌شود. این همان قابلیت خودترمیمی (self-healing) است و به دو دستگاه نیاز دارد.

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

در یک VPS، فضای ذخیره‌سازی میزبان معمولاً از قبل دارای افزونگی است که اغلب به صورت RAID 10 در سطح هایپروایزر پیاده‌سازی می‌شود. این کار از شما در برابر خرابی فیزیکی دیسک محافظت می‌کند، اما به شما نمی‌گوید که چه زمانی یک بلاک به صورت اشتباه بازگردانده شده است، زیرا آرایه راهی برای تشخیص اینکه کدام نسخه صحیح است ندارد. ZFS این موضوع را می‌داند، زیرا داده‌ها را با checksumی که خودش نوشته است مقایسه می‌کند.

اگر یک دیسک مجازی دارید و می‌خواهید قابلیت تعمیر داشته باشید، sudo zfs set copies=2 tank/important دو نسخه از هر بلاک آن dataset را روی همان دیسک ذخیره می‌کند. این کار فضای مصرفی آن dataset را دو برابر می‌کند، در برابر بلاک‌های آسیب‌دیده مقاوم است، اما اگر کل volume از دسترس خارج شود، هیچ کاری از دستش برنمی‌آید.

عملیات scrub تمام داده‌های موجود در pool را می‌خواند و آن‌ها را تایید می‌کند.

sudo zpool scrub tank
zpool status tank

یک pool سالم با خطی مشابه scan: scrub repaired 0B in 00:04:11 with 0 errors به پایان می‌رسد. این عملیات را در زمان‌بندی قرار دهید؛ برای یک pool کوچک، انجام ماهانه آن مناسب است.

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

دیتاست‌ها واحد سیاست‌گذاری هستند

یک دیتاست، یک سیستم فایل درون pool است و ایجاد آن هزینه‌ای ندارد؛ بنابراین برای هر job یک دیتاست مجزا بسازید. ویژگی‌ها (Properties) از pool به ارث می‌رسند، به این معنی که شما یک مقدار پیش‌فرض را یک‌بار تنظیم می‌کنید و در موارد خاص آن را override می‌کنید. در FreeBSD، جیل‌ها (jails) معمولاً به همین صورت اجرا می‌شوند؛ یعنی یک دیتاست برای هر جیل، تا بتوان از یک جیل به‌صورت مستقل snapshot گرفت یا آن را به وضعیت قبل بازگرداند. این موضوع بخشی از تفاوت‌های اصلی جیل با کانتینر Docker است.

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 مقدار کمی از CPU را مصرف می‌کند و تعداد بایت‌هایی که باید به دیسک برسند را کاهش می‌دهد، بنابراین در داده‌های قابل‌فشرده‌سازی، معمولاً سرعت خواندن و نوشتن را افزایش می‌دهد. zstd با مصرف CPU بیشتر، فشرده‌سازی قوی‌تری انجام می‌دهد که برای لاگ‌ها و آرشیوهایی که به‌ندرت خوانده می‌شوند، مناسب است. با استفاده از zfs get compressratio tank بررسی کنید که در عمل چه نتیجه‌ای می‌گیرید و به یاد داشته باشید که نسبت فشرده‌سازی فقط شامل داده‌هایی می‌شود که پس از تنظیم این ویژگی نوشته شده‌اند.

recordsize بزرگ‌ترین بلاکی است که یک دیتاست می‌نویسد و مقدار پیش‌فرض آن 128K است. دیتابیسی که صفحات 8 KiB را در رکوردهای 128 KiB می‌نویسد، یک نوشتن کوچک را به خواندن کل رکورد، اعمال تغییر و نوشتن مجدد تبدیل می‌کند. پیش از بارگذاری داده‌ها، recordsize=16K را روی دیتاست دیتابیس تنظیم کنید، زیرا این ویژگی فقط برای بلاک‌های جدید اعمال می‌شود.

quota روشی است که از پر شدن pool توسط یک دیتاست جلوگیری می‌کند. یک ZFS pool که نزدیک به 100% پر شده باشد، کند می‌شود و پاک‌سازی آن دشوار خواهد بود؛ بنابراین همیشه مقداری فضای خالی (headroom) به‌صورت عمدی در نظر بگیرید.

هزینه اسنپ‌شات‌ها تا زمانی که داده‌ها تغییر نکنند، صفر است

سیستم فایل ZFS هرگز یک بلوک فعال را بازنویسی نمی‌کند. این سیستم یک بلوک جدید می‌نویسد و اشاره‌گرها را به‌روزرسانی می‌کند؛ این همان معنای copy-on-write است. اسنپ‌شات در واقع یک یادداشت است که می‌گوید: «بلوک‌هایی که این دیتاست در حال حاضر به آن‌ها اشاره می‌کند را حفظ کن»، بنابراین ایجاد آن آنی و رایگان است.

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 می‌کشاند که با unmount کردن دیسک شروع شده و شرایط از آنجا بدتر می‌شود.

عملیات Rollback هر چیزی که پس از اسنپ‌شات نوشته شده باشد را دور می‌ریزد.

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

اگر اسنپ‌شات‌های جدیدتری وجود داشته باشد، سیستم از انجام عملیات خودداری می‌کند و -r آن اسنپ‌شات‌های جدیدتر را برای ادامه کار از بین می‌برد. پیش از فشردن کلید Enter، نام دیتاست را دو بار بررسی کنید.

اسنپ‌شات یک نسخه پشتیبان (backup) نیست. اسنپ‌شات در همان pool، روی همان volume و روی همان سرور قرار دارد. خرابی یک volume یا یک zpool destroy، اسنپ‌شات‌ها را همراه با داده‌ها از بین می‌برد. اسنپ‌شات‌ها از شما در برابر rm خودتان و ارتقاهای ناموفق محافظت می‌کنند که بسیاری از حوادث واقعی را پوشش می‌دهد، اما در برابر مشکلاتی که برای خودِ pool رخ می‌دهد، هیچ محافظتی ارائه نمی‌دهند. استدلال کامل در اینجا آمده است: چرا اسنپ‌شات VPS یک نسخه پشتیبان نیست.

ارسال و دریافت: همانندسازی با یک دستور

zfs send یک اسنپ‌شات را به جریانی از بایت‌ها در خروجی استاندارد تبدیل می‌کند و zfs receive آن جریان را دوباره به یک دیتاست برمی‌گرداند. اولین کپی، یک ارسال کامل (full send) است.

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.

این یک نسخه پشتیبان واقعی خارج از سایت (off-site) است، با یک شرط. مقصد نهایی باید یک ZFS pool باشد، زیرا object storage نمی‌تواند یک جریان (stream) را دریافت کند. هنگامی که مقصد شما یک فضای ذخیره‌سازی سازگار با S3 یا یک میزبان لینوکسی معمولی است، از ابزاری استفاده کنید که با آن ارتباط برقرار می‌کند، و پشتیبان‌گیری restic از یک VPS این مسیر را پوشش می‌دهد.

چرا ZFS از رم زیادی استفاده می‌کند؟ ARC

حافظه ARC (مخفف adaptive replacement cache) کش خواندن ZFS است. این حافظه به‌جای قرارگیری در page cache معمولی لینوکس، در حافظه هسته (kernel memory) جای می‌گیرد، بنابراین free -h آن را تحت عنوان buff/cache گزارش نمی‌کند. این مقدار به‌عنوان حافظه در حال استفاده (in use) خوانده می‌شود. سروری که از ZFS استفاده می‌کند و رم آن تقریباً پر به نظر می‌رسد، معمولاً سروری با کش گرم (warm cache) است و همین موضوع دلیل اکثر گزارش‌های «ZFS رم مرا بلعید» است.

محدودیت پیش‌فرض عمداً سخاوتمندانه در نظر گرفته شده است. در OpenZFS 2.3، حداکثر اندازه ARC برابر است با مقدار بزرگ‌تر بین «رم منهای 1 GiB» و «5/8 رم». در OpenZFS 2.2 و نسخه‌های قدیمی‌تر در لینوکس، نیمی از رم استفاده می‌شد، در حالی که 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
  }
]

این ارقام، قانون پیش‌فرض مستندشده برای اندازه‌های رایج نمونه‌ها (instances) هستند، نه اندازه‌گیری‌های واقعی از یک سرور در حال اجرا. در یک نمونه 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 حافظه را پس می‌دهد. هسته فشار حافظه را اعلام می‌کند و ARC کوچک می‌شود. مشکل در زمان‌بندی است، زیرا کوچک شدن توسط همان فشار ایجاد می‌شود؛ بنابراین فرآیندی که ناگهان چندین صد MiB حافظه درخواست می‌کند، ممکن است پیش از آنکه ARC حافظه را آزاد کند، با OOM (مخفف out of memory) killer مواجه شود. در یک سرور 2 GB که یک دیتابیس و یک وب‌سرور را اجرا می‌کند، این اتفاق نادری نیست. دفترچه راهنمای OpenZFS در مورد تغییرات دستی نیز همین نکته را بیان می‌کند: کاهش محدودیت «بدون وجود فشار حافظه برای تحریک کوچک‌سازی، باعث کوچک شدن ARC نخواهد شد».

نحوه محدود کردن ARC در یک VPS کوچک

ابتدا میزان حافظه مورد نیاز برای workload خود را تعیین کنید. مجموع حافظه مورد نیاز دیتابیس و اپلیکیشن را محاسبه کنید، مقداری را برای سیستم‌عامل کنار بگذارید و باقی‌مانده را به ARC اختصاص دهید. در یک نمونه 4 GB که Postgres و یک اپلیکیشن وب روی آن اجرا می‌شود، اختصاص 512 MiB تا 1 GiB به ARC نقطه شروع معقولی است.

این مقدار را به صورت زنده و بر حسب بایت تنظیم کنید. این دستور برای 1 GiB است.

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

تنظیمات را برای پس از reboot ماندگار کنید.

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

مرحله initramfs اهمیت دارد، زیرا ماژول ممکن است پیش از mount شدن فایل‌سیستم ریشه از initramfs بارگذاری شود؛ این یعنی فایلی که ایجاد کردید هرگز خوانده نخواهد شد. پس از reboot، با استفاده از خط c_max از arcstats آن را تایید کنید.

دو نکته مهم در خود راهنما ذکر شده است. شما نمی‌توانید مقدار را در حین اجرای سیستم به 0 برگردانید، بنابراین برای لغو این تنظیم باید فایل را ویرایش کرده و سیستم را reboot کنید. همچنین کاهش این عدد باعث کوچک شدن فوری ARC بزرگ نمی‌شود.

در FreeBSD همین محدودیت یک sysctl تحت vfs.zfs.arc است. دستور sysctl vfs.zfs.arc را اجرا کنید تا مقادیر فعلی و نام دقیق مورد استفاده در نسخه خود را ببینید، سپس مقدار حداکثر را در /boot/loader.conf بنویسید.

دو قانون حافظه دیگر برای یک سرور کوچک: deduplication را غیرفعال نگه دارید، زیرا جدول dedup در حافظه قرار می‌گیرد و قاعده کلی منتشر شده، اختصاص 1 تا 3 GB رم به ازای هر TB داده منحصربه‌فرد است. همچنین swap را روی zvol (یک block device که از pool جدا شده) قرار ندهید، زیرا swap کردن از طریق فایل‌سیستمی که در حال تلاش برای آزاد کردن حافظه است، می‌تواند باعث deadlock شدن ماشین شود. swap را روی یک partition معمولی یا یک swap file خارج از pool نگه دارید.

چه زمانی ext4 یا XFS به همراه restic گزینه بهتری است

ZFS در سروری که حافظه رم مازاد و یک درایو دوم دارد، ارزش خود را نشان می‌دهد. در غیر این صورت، استفاده از یک فایل‌سیستم ساده به همراه یک ابزار پشتیبان‌گیری واقعی، انتخاب بهتری است. در موارد زیر ext4 یا XFS را انتخاب کنید:

• نمونه سرور شما 2 گیگابایت یا 4 گیگابایت رم دارد و بار کاری تمام آن را اشغال می‌کند.
• تنها یک دیسک مجازی دارید و نسخه دومی وجود ندارد؛ بنابراین ZFS فقط خرابی را تشخیص می‌دهد اما نمی‌تواند آن را تعمیر کند.
• مقصد پشتیبان‌گیری شما object storage یا یک میزبان لینوکسی ساده است و هیچ‌کدام نمی‌توانند جریان zfs send را دریافت کنند.
• از Debian با DKMS استفاده می‌کنید و نمی‌توانید ریسک ارتقای کرنلی را بپذیرید که باعث عدم کامپایل ماژول شود.
• نیاز دارید ZFS روی فایل‌سیستم ریشه باشد، اما ایمیج‌های ارائه‌شده توسط سرویس‌دهنده فقط ext4 هستند.

زمانی ZFS را حفظ کنید که یک درایو داده مجزا، رم کافی (8 گیگابایت و بالاتر مناسب است) و برنامه‌ای برای استفاده از snapshots و zfs send داشته باشید، نه اینکه صرفاً آن‌ها را فعال کرده باشید. برای سایر موارد، استفاده از ext4 به همراه restic برای نوشتن پشتیبان‌های رمزنگاری‌شده و deduplicate‌شده در فضایی که تحت کنترل سرور نیست، تقریباً همان مزایا را بدون مصرف حافظه رم ارائه می‌دهد.

حالت‌های شکست و پیام‌های مرتبط

استخر پس از راه‌اندازی مجدد ناپدید می‌شود. دستور zpool status خروجی no pools available را نمایش می‌دهد. سرویس import فایل /etc/zfs/zpool.cache را می‌خواند، بنابراین استخری که در این فایل ذکر نشده باشد، هرگز در زمان بوت وارد نمی‌شود. دستور sudo zpool import موارد قابل import را لیست می‌کند، sudo zpool import tank آن را بازمی‌گرداند و sudo zpool set cachefile=/etc/zfs/zpool.cache tank باعث ماندگاری آن می‌شود. استخری که به‌درستی از سیستم دیگری export نشده باشد، خطای 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 برای هسته جدید ساخته نشده است، که معمولاً به دلیل نصب نبودن هدرهای منطبق با هسته است. دستور 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 پاسخ شماست. snapshotهای قدیمی را با sudo zfs destroy tank/data@2026-06-01 حذف کنید تا فضا آزاد شود.

افزایش تعداد CKSUM در zpool status. چیزی در لایه‌های زیرین ZFS داده‌های نادرست بازگردانده است. در یک mirror، این تعداد یک هشدار است و بلاک مربوطه تعمیر شده است. در یک استخر تک‌دیسکی، فایل از دست رفته است، zpool status -v نام آن را مشخص می‌کند و شما باید آن فایل خاص را از نسخه‌ پشتیبانی که در این استخر قرار ندارد، بازیابی کنید.

سرور کند است و از swap استفاده می‌کند. سقف ARC را همان‌طور که در بالا گفته شد محدود کنید، سپس arc_summary را اجرا کرده و نسبت hit را بررسی کنید. اگر ARC برای نگهداری working set بسیار کوچک باشد، هر عملیات خواندن به دیسک ارجاع داده می‌شود؛ در این نقطه، یک فایل‌سیستم معمولی که از page cache استفاده می‌کند، عملکرد بهتری به شما ارائه خواهد داد.

FAQ

مقدار رم مورد نیاز ZFS روی یک VPS چقدر است؟

ZFS روی یک نمونه 2 گیگابایتی اجرا می‌شود. پرسش اصلی این است که چه مقدار رم برای برنامه شما باقی می‌ماند. بدون بهینه‌سازی، OpenZFS 2.3 اجازه می‌دهد ARC تا مقدار بزرگ‌تر از (رم منهای 1 گیگابایت) و (5/8 رم) رشد کند؛ بنابراین یک سرور 4 گیگابایتی می‌تواند 3 گیگابایت را به کش اختصاص دهد. مقدار zfs_arc_max را روی عددی تنظیم کنید که بار کاری شما توانایی تخصیص آن را دارد، سپس با خواندن خط c_max از /proc/spl/kstat/zfs/arcstats آن را تأیید کنید.

آیا اسنپ‌شات ZFS یک نسخه پشتیبان (Backup) است؟

خیر. اسنپ‌شات در همان pool داده‌ها زندگی می‌کند. اسنپ‌شات در برابر rm معیوب و ارتقای ناموفق سالم می‌ماند، اما با از بین رفتن pool یا سرور، آن هم از بین می‌رود. برای تبدیل آن به نسخه پشتیبان، آن را با استفاده از zfs send به ماشین دیگری ارسال کنید یا از ابزار پشتیبان‌گیری استفاده کنید که داده‌ها را روی فضای ذخیره‌سازی خارج از کنترل این سرور می‌نویسد.

آیا عملکرد ZFS در FreeBSD و Linux یکسان است؟

از زمان انتشار OpenZFS 2.0 در دسامبر 2020، codebase، دستورات و فرمت روی دیسک یکسان هستند و poolها بین این دو سیستم‌عامل قابل جابجایی‌اند. تفاوت در بسته‌بندی است. FreeBSD سیستم ZFS را در base system خود ارائه می‌دهد. در لینوکس، هر توزیع تصمیم‌گیری می‌کند: Ubuntu ماژول را درون بسته‌های هسته (kernel) خود می‌سازد، در حالی که Debian آن را با استفاده از DKMS روی ماشین شما کامپایل می‌کند؛ بنابراین ارتقای هسته ممکن است تا زمان موفقیت‌آمیز بودن بازسازی (rebuild)، شما را بدون ماژول باقی بگذارد.

آیا ZFS می‌تواند خرابی داده را در یک VPS با یک دیسک تعمیر کند؟

ZFS خرابی را تشخیص داده و نام فایل را اعلام می‌کند، اما نمی‌تواند آن را تعمیر کند، زیرا تعمیر نیازمند یک کپی دوم از بلاک است. تنظیم zfs set copies=2 روی یک dataset، آن کپی دوم را با دو برابر فضای مصرفی در اختیار شما قرار می‌دهد که خرابی بلاک را مدیریت می‌کند، اما در صورت از دست رفتن کل volume کمکی نمی‌کند. راهکار واقعی برای ترمیم داده‌ها، استفاده از mirror روی دو volume مجزا است.

آیا فشرده‌سازی باعث کندی سرور می‌شود؟

lz4 معمولاً باعث افزایش سرعت می‌شود. بلاک‌های فشرده به معنای نوشتن و خواندن بایت‌های کمتر است و هزینه پردازشی (CPU) برای هر بلاک در مقایسه با فضای دیسکی که ذخیره می‌شود، ناچیز است. مقدار compression=lz4 را در ریشه pool تنظیم کنید تا همه datasetها آن را به ارث ببرند، سپس پس از نوشتن داده‌های واقعی، zfs get compressratio tank را بررسی کنید.