ZFS sa FreeBSD at Linux: Sulit ba ang RAM trade-off?

Ano ang ibinibigay ng ZFS, at ano ang kailangan nito

Iisang codebase na ngayon ang ZFS sa FreeBSD at Linux—OpenZFS—kaya pareho ang mga feature sa dalawang system. Ang server na gumagamit ng ZFS ay may checksummed data, mga snapshot na walang karagdagang gastos hanggang may magbago sa data, replication gamit ang zfs send, at compression na isang property lang ang kailangan. Ang kapalit nito ay memory: kumukuha ang ARC (adaptive replacement cache) ng malaking bahagi ng RAM bilang default. Sa 2 GB o 4 GB na VPS (virtual private server), ang memory na iyon ang eksaktong kailangan ng application mo.

Sinusuri ng guide na ito ang ZFS mula sa isang nirentahang VPS na may isa o dalawang virtual disk, hindi mula sa storage box na may 40 drive bay. Ang mga feature na gumagana pa rin sa ganitong setup ang sulit paglaanan ng oras. Mahalagang malaman ang mga feature na hindi na gumagana nang maayos sa ganitong setup bago ka gumawa ng pool.

OpenZFS sa FreeBSD at Linux: iisang codebase, dalawang paraan ng packaging

Kasama na ng FreeBSD ang ZFS sa base system mula FreeBSD 7.0 noong 2008, noong una bilang experimental feature. Mula OpenZFS 2.0 noong December 2020, iisang source tree ang ginagamit sa pag-build ng FreeBSD at Linux, kaya pareho ang asal ng zfs at zpool sa dalawang platform, at maaaring i-import sa isa ang pool na ginawa sa isa pa.

Licensing ang dahilan kung bakit package ang ZFS sa Linux at bahagi ng base system sa FreeBSD. Nasa ilalim ang OpenZFS ng CDDL (common development and distribution license). Nasa ilalim naman ang Linux kernel ng GPL (general public license) version 2. Itinuturing ng kernel project na hindi compatible ang dalawang license, kaya hindi isinasama ang ZFS code sa mainline Linux, at bawat distribution ang nagpapasya kung paano ito ipapamahagi. Walang ganitong conflict sa FreeBSD, kaya naroon na agad ang ZFS. Iyan ang buong praktikal na paliwanag: isang pagkakaiba sa packaging, at wala kang kailangang panigan.

Hindi nag-aalok ang SSD Nodes ng FreeBSD images, kaya Linux ang bahaging naaangkop sa gabay na ito kapag umupa ka ng server dito. Kung nagpapatakbo ka ng FreeBSD sa ibang lugar, nakakakuha ang isang FreeBSD server ng ZFS nang walang kailangang i-build na module at walang kernel upgrade na kailangang tiyaking magpapatuloy ang paggana.

Mag-install ng ZFS at gumawa ng pool

Sa Ubuntu, kasama ang module sa kernel packages, kaya mga command lang ang kailangan mong i-install.

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

Ang zfs version ay nagpi-print ng dalawang linya: ang userland version at ang kernel module version. Kung isang linya lang ang lumabas, hindi na-load ang module. Nasa universe component ang package, at naka-enable ito bilang default sa Ubuntu server images. Kung hindi ito mahanap ng apt, patakbuhin muna ang sudo add-apt-repository universe.

Sa Debian, nasa contrib component ang packages, at binubuo ng DKMS (dynamic kernel module support) ang module sa iyong machine. Idagdag ang contrib sa linya ng Components: sa /etc/apt/sources.list.d/debian.sources, patakbuhin ang sudo apt update, pagkatapos:

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

Kino-compile ng installation ang module at ipinapakita ang Building initial module for 6.12.0-..., na maaaring tumagal nang ilang minuto. Tandaan ang ibig sabihin nito: bina-build itong muli sa bawat kernel upgrade, at kapag nabigo ang build, hindi mai-import ang pool hanggang sa maayos mo ang problema.

Sa FreeBSD, walang kailangang i-install. I-enable ang service at simulan ito.

sysrc zfs_enable=YES
service zfs start

Ngayon, gawin ang pool. Tingnan muna ang stable device paths, dahil ibinibigay ang /dev/vdb batay sa detection order at maaaring magbago kapag nag-attach ka ng isa pang volume.

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

Dapat mag-print ang zpool status ng state: ONLINE, at dapat nakalista ang iyong device sa ilalim ng tank. Itinatakda ng ashift=12 sa 4 KiB ang pinakamaliit na block ng pool. Tugma ito sa mga kasalukuyang SSD at hindi na mababago pagkatapos ng paggawa.

Karamihan sa mga rented image ay nagbo-boot mula sa ext4 root, kaya ang ZFS dito ay data pool sa pangalawang volume, hindi ang root filesystem. Suriing mabuti kung ang device ay ang inaasahan mo bago mo ito gamitin, dahil isang minuto lang ang pagkumpirma sa NVMe disk na ipinagbili sa iyo, samantalang isang buong hapon ang maaaring kailanganin sa rebuild.

Mga checksum ay nakakapag-repair lamang kapag may redundancy ang pool

May checksum ang bawat block na isinusulat ng ZFS, at bini-verify ito sa bawat pagbasa. Palaging gumagana ang pag-detect. Kailangan naman ng pangalawang kopya para sa pag-repair.

Sa single-disk pool, sinasabi ng ZFS ang aktuwal na problema at hanggang doon lamang. Iniuulat ito ng zpool status -v nang ganito:

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

Tinutukoy ang pangalan ng sirang file. Ibabalik sana ng ext4 ang mga byte na iyon nang walang anumang abiso, kaya mahalaga na agad itong natukoy. Hindi pa rin ito maaayos ng ZFS dahil walang pangalawang kopya sa pool na mapagkukunan ng tamang data.

Sa mirror, ibinibigay ang parehong read mula sa maayos na kopya, muling isinusulat ang sirang block, at lumilitaw ang event sa CKSUM column ng zpool status. Ito ang self-healing, at kailangan nito ng dalawang device.

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

Sa isang VPS, karaniwang redundant na ang storage ng host, madalas sa pamamagitan ng RAID 10 sa ilalim ng hypervisor. Pinoprotektahan ka nito laban sa tuluyang pagkasira ng drive. Hindi nito sinasabi kung may block na bumalik na mali, dahil walang paraan ang array para malaman kung aling kopya ang tama. Alam ito ng ZFS dahil ikinukumpara nito ang data sa checksum na sarili nitong isinulat.

Kung iisa lamang ang virtual disk mo at gusto mo ng kakayahang mag-repair, nag-iimbak ang sudo zfs set copies=2 tank/important ng dalawang kopya ng bawat block ng dataset na iyon sa parehong disk. Dinodoble nito ang space na ginagamit ng dataset, nakakaligtas ito sa sirang block, at wala itong magagawa kapag tuluyang nawala ang buong volume.

Binabasa ng scrub ang lahat ng laman ng pool at bina-verify ang mga ito.

sudo zpool scrub tank
zpool status tank

Ang isang healthy na pool ay nagtatapos sa linyang gaya ng scan: scrub repaired 0B in 00:04:11 with 0 errors. Isama ito sa schedule; sapat na ang buwanang pagtakbo para sa maliit na pool.

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

Ang mga dataset ang unit ng policy

Ang dataset ay isang filesystem sa loob ng pool, at mura itong likhain, kaya gumawa ng tig-iisang dataset para sa bawat job. Nag-i-inherit ang mga property mula sa pool, kaya isang beses mo lang itinatakda ang default at ino-override ito kung saan kinakailangan. Sa FreeBSD, ganito karaniwang pinapatakbo ang mga jail: isang dataset para sa bawat jail, para ma-snapshot at ma-roll back nang hiwalay ang isang jail. Bahagi ito ng mga naghihiwalay sa jail at Docker container.

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

Ang compression ang property na madalas iniiwan ng mga tao dahil sa pag-iingat, pero baligtad ang tamang approach. lz4 ay kaunti lang ang kinakain na CPU at binabawasan nito ang mga byte na kailangang maisulat sa disk, kaya sa compressible data ay karaniwan nitong pinapabilis ang reads at writes. zstd ay mas matindi ang compression kapalit ng mas maraming CPU, kaya angkop ito sa mga log at archive na bihira mong basahin muli. Gamitin ang zfs get compressratio tank para tingnan kung ano talaga ang nakukuha mo, at tandaan na ang ratio ay para lamang sa data na naisulat matapos itakda ang property.

recordsize ang pinakamalaking block na sinusulatan ng isang dataset, na 128K bilang default. Kapag nagsusulat ang database ng 8 KiB page sa mga record na 128 KiB, ang isang maliit na write ay nagiging pagbasa sa buong record, pagbabago rito, at muling pagsulat. Itakda ang recordsize=16K sa dataset ng database bago i-load ang data, dahil nalalapat lamang ang property sa mga bagong sinusulat na block.

quota ang ginagamit para pigilan ang isang dataset na mapuno ang pool. Kapag halos 100% full ang isang ZFS pool, bumabagal ito at nagiging mahirap linisin, kaya sadyang mag-iwan ng sapat na headroom.

Walang gastos ang snapshots hangga’t walang nagbabagong data

Hindi kailanman ino-overwrite ng ZFS ang live block. Nagsusulat ito ng bagong block at ina-update ang mga pointer; ito ang ibig sabihin ng copy-on-write. Ang snapshot ay tala na nagsasabing “panatilihin ang mga block na tinutukoy ng dataset na ito sa kasalukuyan,” kaya instant at walang gastos ang paggawa nito.

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

Ang USED column ng snapshot ay ang space na hawak lamang ng snapshot na iyon. Nagsisimula ito sa halos zero at lumalaki habang binabago o dine-delete mo ang data, dahil hindi na maaaring i-release ang mga lumang block.

Walang restore step na kailangan para maibalik ang isang file.

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

Nakatago ang .zfs directory kahit sa ls -a hanggang patakbuhin mo ang sudo zfs set snapdir=visible tank/data. Gawin ang snapshot bago mo ito kailanganin, dahil kung wala nito, isang maling rm -rf ang magdadala sa iyo sa recovery path ng ext4, na nagsisimula sa pag-unmount ng disk at lalong nagiging kumplikado pagkatapos nito.

Itinatapon ng rollback ang lahat ng naisulat mula nang gawin ang snapshot.

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

Tumatanggi ito kapag may mga mas bagong snapshot, at sinisira ng -r ang mga mas bagong snapshot na iyon upang magpatuloy. Basahin nang dalawang beses ang pangalan ng dataset bago mo pindutin ang enter.

Hindi backup ang snapshot. Nasa iisang pool ito, sa iisang volume, at sa iisang server. Ang pumalyang volume o isang zpool destroy ay kasama ring mawawala ang mga snapshot pati ang data. Pinoprotektahan ka ng snapshots laban sa sarili mong rm at laban sa maling upgrade, na sumasaklaw sa maraming totoong insidente. Wala silang proteksiyon laban sa anumang mangyari mismo sa pool. Nakasaad ang buong paliwanag dito: kung bakit hindi backup ang VPS snapshot.

Ipadala at tumanggap: replication sa isang command

Ginagawang byte stream ng zfs send ang isang snapshot sa standard output, at ginagawang dataset naman ng zfs receive ang stream na iyon. Full send ang unang copy.

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"

Pagkatapos nito, ipadala lamang ang mga pagbabagong naganap sa pagitan ng dalawang snapshot.

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"

Dapat mayroon pa rin sa receiving side ang snapshot na pinagmumulan ng ipinapadala mo. Kapag wala ito, hihinto ang receive na may cannot receive incremental stream: most recent snapshot of backup/data does not match incremental source, dahil walang base ang ZFS na paglalapatan ng pagkakaiba. Magpadala mula sa snapshot na nasa magkabilang side, o magsimulang muli gamit ang full send.

Magbigay ng mga karapatan sa target sa halip na gumamit ng remote root: sudo zfs allow -u backupuser create,mount,receive backup/data.

Itinuturing itong totoong off-site backup, ngunit may isang kondisyon. Dapat ZFS pool ang nasa kabilang dulo, dahil hindi makakatanggap ng stream ang object storage. Kung S3-compatible storage o plain Linux host ang target mo, gumamit ng tool na may suporta rito; saklaw ng restic backups mula sa VPS ang ganitong setup.

Bakit napakalaki ng RAM na ginagamit ng ZFS? Ang ARC

Ang ARC (adaptive replacement cache) ang read cache ng ZFS. Nasa kernel memory ito sa halip na nasa karaniwang Linux page cache, kaya hindi ito iniuulat ng free -h sa ilalim ng buff/cache. Itinuturing itong memory in use. Ang ZFS box na mukhang halos puno ay karaniwang may warm cache, at ito ang dahilan ng karamihan sa mga ulat na “kinain ng ZFS ang RAM ko.”

Maluwag ang default limit nito ayon sa disenyo. Itinatakda ng OpenZFS 2.3 ang maximum ARC size sa mas malaki sa RAM minus 1 GiB at 5/8 ng RAM. Sa OpenZFS 2.2 at mas nauna, kalahati ng RAM ang ginagamit sa Linux, samantalang ginagamit na ng FreeBSD ang bagong rule. Patakbuhin ang zfs version para makita kung alin ang naaangkop sa iyo.

[
  {
    "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
  }
]

Ang mga halagang ito ay batay sa dokumentadong default rule na inilapat sa karaniwang instance size, hindi sa mga sukat mula sa tumatakbong box. Sa 4 GB instance, pinapahintulutan ng 2.3 rule ang ARC na 3 GiB. Sa parehong box gamit ang 2.2, hanggang 2 GiB lamang ang ARC. Sa 2 GB instance, pinapahintulutan pa rin ng 2.3 rule ang 1.25 GiB. Ang application mo ang gagamit ng natitirang memory.

Kunin ang aktuwal na mga value mula sa sarili mong server sa halip na umasa sa table:

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

Bytes ang nasa ikatlong column. Ang c_max ang kasalukuyang ceiling, at ang size ang kasalukuyang laman ng ARC.

Nagbabalik naman ng memory ang ARC. Nagpapadala ng pressure signal ang kernel at lumiliit ang ARC. Ang problema ay ang timing, dahil pressure ang nagtutulak sa pagliit nito. Dahil dito, maaaring maabutan ng OOM (out of memory) killer ang isang process na sabay-sabay humihingi ng ilang daang MiB habang naglalabas pa ng memory ang ARC. Sa 2 GB box na nagpapatakbo ng database at web server, hindi ito bihirang mangyari. Ganito rin ang sinasabi ng OpenZFS manual tungkol sa mga manual na pagbabago: ang pagbaba ng limit “ay hindi magpapaliit sa ARC kung walang memory pressure na mag-uudyok sa pagliit nito.”

Paano limitahan ang ARC sa maliit na VPS

Tukuyin muna ang memory requirement ng workload. Pagsama-samahin ang kailangan ng database at application, maglaan ng margin para sa operating system, at ibigay ang natitira sa ARC. Sa isang 4 GB instance na nagpapatakbo ng Postgres at isang web application, makatuwirang panimulang halaga ang 512 MiB hanggang 1 GiB para sa ARC.

I-set ito habang tumatakbo ang system, gamit ang bytes. Ang halimbawang ito ay 1 GiB.

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

Para manatili ang setting pagkatapos ng reboot, idagdag ito sa boot configuration.

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

Mahalaga ang initramfs step dahil maaaring ma-load ang module mula sa initramfs bago ma-mount ang root filesystem. Ibig sabihin, hindi nito mababasa ang file na isinulat mo. Pagkatapos ng reboot, kumpirmahin ito gamit ang c_max line mula sa arcstats.

May dalawang caveat mismo sa manual. Hindi mo maibabalik ang value sa 0 habang tumatakbo ang system. Para i-undo ito, i-edit ang file at mag-reboot. Hindi rin agad liliit ang malaking ARC kapag binawasan ang value.

Sa FreeBSD, sysctl sa ilalim ng vfs.zfs.arc ang kaparehong limit. Patakbuhin ang sysctl vfs.zfs.arc upang makita ang kasalukuyang values at ang eksaktong pangalan na ginagamit ng iyong version. Pagkatapos, isulat ang maximum sa /boot/loader.conf.

May dalawa pang memory rule para sa maliit na server. Iwanang naka-off ang deduplication dahil nasa memory ang dedup table. Ang karaniwang inilalathalang rule of thumb ay 1 hanggang 3 GB ng RAM bawat TB ng unique data. Huwag ding maglagay ng swap sa zvol (block device na kinuhang bahagi ng pool). Maaaring mag-deadlock ang machine kapag nag-swap ito sa filesystem na sinusubukang magpalaya ng memory. Panatilihin ang swap sa plain partition o swap file na nasa labas ng pool.

Kapag ext4 o XFS at restic ang mas angkop na solusyon

Sulit ang ZFS sa server na may ekstrang memory at pangalawang volume. Kung wala ang mga ito, mas mabuti ang plain filesystem na may maaasahang backup tool. Piliin ang ext4 o XFS kapag:

• May 2 GB o 4 GB na RAM ang instance at kailangan ito ng workload nang buo.
• Iisa lang ang virtual disk at walang pangalawang kopya, kaya makaka-detect ang ZFS ng problema pero hindi ito maaayos.
• Object storage o plain Linux host ang backup target mo, kaya walang makakatanggap doon ng zfs send stream.
• Gumagamit ka ng Debian na may DKMS at hindi mo kayang magkaroon ng kernel upgrade na mag-iiwan sa module na hindi na-build.
• Kailangan mo ng ZFS sa root filesystem at ext4 lamang ang iniaalok ng mga image ng provider.

Panatilihin ang ZFS kapag mayroon kang hiwalay na data volume, sapat na ekstrang RAM (komportable ang 8 GB pataas), at planong aktuwal na gumagamit ng snapshots at zfs send sa halip na i-enable lamang ang mga ito. Para sa iba pang sitwasyon, sapat na sa karamihan ng parehong pangangailangan ang ext4 na gumagamit ng restic upang sumulat ng encrypted at deduplicated backups sa storage na hindi kontrolado ng server, nang hindi nangangailangan ng memory.

Mga failure mode at mga string na makikita mo

Nawala ang pool matapos ang reboot. Ipinapakita ng zpool status ang no pools available. Binabasa ng import service ang /etc/zfs/zpool.cache, kaya hindi kailanman nai-import sa boot ang pool na wala sa file na iyon. Inililista ng sudo zpool import kung ano ang maaaring i-import, ibinabalik ito ng sudo zpool import tank, at pinapanatili ito ng sudo zpool set cachefile=/etc/zfs/zpool.cache tank. Nag-uulat ang pool na hindi malinis na na-export mula sa ibang system ng cannot import 'tank': pool may be in use from other system, at ino-override ito ng sudo zpool import -f tank kapag nakatiyak kang wala itong kaparehong pool sa ibang host.

modprobe: FATAL: Module zfs not found in directory /lib/modules/6.12.0-... sa Debian pagkatapos ng kernel upgrade. Hindi nag-build ang DKMS para sa bagong kernel, karaniwan dahil hindi naka-install ang katugmang headers. Ipinapakita ng dkms status kung ano ang na-build para sa bawat kernel. Pagkatapos, sudo apt install -y linux-headers-$(uname -r) ang sudo dkms autoinstall para muling i-build ito, at ibinabalik ng sudo zpool import tank ang pool.

Puno ang pool pero dinelete mo na ang mga file. Nananatili sa disk ang dinelete na data habang may snapshot na tumutukoy rito, kaya hindi nagtutugma ang du at df. Hinahati ng zfs list -o space -r tank ang paggamit sa USEDDS at USEDSNAP, at ang malaking USEDSNAP ang nagpapaliwanag dito. I-destroy ang mga lumang snapshot gamit ang sudo zfs destroy tank/data@2026-06-01 upang bumalik ang espasyo.

Tumataas ang mga CKSUM count sa zpool status. May component sa ibaba ng ZFS na nagbalik ng maling data. Sa mirror, babala lamang ang count at na-repair ang block. Sa single-disk pool, nawawala ang file; tinutukoy ito ng zpool status -v, at ibinabalik mo ang file mula sa backup na wala sa pool na ito.

Mabagal ang server at gumagamit ng swap. Limitahan ang ARC gaya ng nasa itaas, pagkatapos ay patakbuhin ang arc_summary at tingnan ang hit ratio. Kapag masyadong maliit ang ARC para maglaman ng working set, bawat read ay pumupunta sa disk. Sa puntong ito, mas makapaglilingkod sa iyo ang isang plain filesystem na gumagamit ng page cache.

FAQ

Gaano karaming RAM ang kailangan ng ZFS sa isang VPS?

Tumatakbo ang ZFS sa isang 2 GB instance. Ang tunay na tanong ay kung gaano karami ang matitira para sa iyong application. Kapag walang tuning, hinahayaan ng OpenZFS 2.3 na lumaki ang ARC hanggang sa mas malaki sa RAM minus 1 GiB at 5/8 ng RAM, kaya maaaring maglaan ang isang 4 GB na machine ng 3 GiB para sa cache. Itakda ang zfs_arc_max sa halagang kaya ng iyong workload, pagkatapos ay kumpirmahin ito sa pamamagitan ng pagbasa sa linya ng c_max mula sa /proc/spl/kstat/zfs/arcstats.

Backup ba ang isang ZFS snapshot?

Hindi. Nananatili ang snapshot sa parehong pool na kinalalagyan ng data. Nakaliligtas ito sa sirang rm at nabigong upgrade, ngunit mawawala rin ito kapag nawala ang pool o ang instance. Gawin itong backup sa pamamagitan ng pagpapadala nito sa ibang machine gamit ang zfs send, o sa pagpapatakbo ng backup tool na nagsusulat sa storage na hindi kontrolado ng server na ito.

Pareho ba ang paggana ng ZFS sa FreeBSD at Linux?

Pareho ang codebase mula noong OpenZFS 2.0 noong December 2020, pareho ang mga command, pareho ang on-disk format, at maaaring ilipat ang mga pool sa pagitan ng mga ito. Ang pagkakaiba ay nasa packaging. Kasama ang ZFS sa base system ng FreeBSD. Sa Linux, bawat distribution ang nagpapasya: bina-build ng Ubuntu ang module sa kernel packages nito, habang bina-build ito ng Debian sa iyong machine gamit ang DKMS. Dahil dito, maaaring mawalan ka ng module pagkatapos ng kernel upgrade hanggang sa matagumpay na makumpleto ang rebuild.

Maaayos ba ng ZFS ang corruption sa isang VPS na may isang disk?

Natutukoy nito ang corruption at tinutukoy ang file, ngunit hindi nito ito maaayos dahil kailangan ng repair ng pangalawang kopya ng block. Binibigyan ka ng zfs set copies=2 sa isang dataset ng pangalawang kopyang iyon kapalit ng dobleng space. Nalulutas nito ang problema sa isang sirang block, ngunit hindi ang pagkawala ng volume. Ang mirror sa dalawang volume ang aktuwal na nakapaglulunas sa problema.

Pinapabagal ba ng compression ang server?

Karaniwang pinabibilis ito ng lz4. Mas kaunting bytes ang sinusulat at binabasa kapag compressed ang mga block, at maliit ang CPU cost ng bawat block kumpara sa oras ng disk na natitipid nito. Itakda ang compression=lz4 sa pool root upang mamana ito ng bawat dataset, pagkatapos ay suriin ang zfs get compressratio tank kapag naisulat na ang aktuwal na data.