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

Ano ang ibinibigay ng ZFS, at ano ang kailangan nito

Iisa na ngayon ang codebase ng ZFS sa FreeBSD at Linux: OpenZFS. Kaya pareho ang mga feature nito sa dalawang system. Ang server na gumagamit ng ZFS ay may checksummed data, mga snapshot na walang dagdag na gastos hanggang may mabagong data, replication gamit ang zfs send, at compression na isang property lang ang kailangang i-configure. Ang kapalit nito ay memory: likas na kumukuha ng malaking bahagi ng RAM ang ARC (adaptive replacement cache). Sa isang 2 GB o 4 GB VPS (virtual private server), ang memory na ito ay eksaktong kailangan ng application mo.

Sinusuri ng guide na ito ang ZFS sa isang rented VPS na may isa o dalawang virtual disk, hindi sa isang storage box na may apatnapung drive bay. Ang mga feature na nananatiling kapaki-pakinabang sa ganitong setup ang dapat paglaanan ng oras. Dapat mo ring malaman ang mga feature na hindi angkop dito bago ka gumawa ng pool.

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

Kasama na ng FreeBSD sa base system ang ZFS mula pa noong FreeBSD 7.0 noong 2008, noong una bilang experimental feature. Mula noong OpenZFS 2.0 noong December 2020, nagbu-build ang FreeBSD at Linux mula sa iisang source tree, kaya pareho ang gawi 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 incompatible 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 kampihan.

Hindi nag-aalok ang SSD Nodes ng FreeBSD images, kaya sa server na nirentahan dito, ang Linux na bahagi ng guide na ito ang naaangkop. Kung nagpapatakbo ka ng FreeBSD sa ibang lugar, may ZFS ang isang FreeBSD server nang walang module na kailangang i-build at walang kernel upgrade na kailangang lampasan.

Mag-install ng ZFS at gumawa ng pool

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

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

Nagpi-print ang zfs version ng dalawang linya: ang userland version at ang kernel module version. Kapag isang linya lang ang lumabas, hindi nag-load ang module. Nasa universe component ang package, na naka-enable 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 mga package, at bina-build ang module sa machine mo ng DKMS (dynamic kernel module support). Idagdag ang contrib sa Components: line 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 pini-print ang Building initial module for 6.12.0-..., na maaaring tumagal nang ilang minuto. Tandaan ang ibig sabihin nito: bina-build ulit ang module sa bawat kernel upgrade, at kapag nabigo ang build, hindi mai-import ang pool hanggang 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 mga stable device path, dahil ang /dev/vdb ay ibinibigay 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 device mo sa ilalim ng tank. Itinatakda ng ashift=12 ang pinakamaliit na block ng pool sa 4 KiB. Tugma ito sa mga kasalukuyang SSD at hindi na mababago pagkatapos gawin ang pool.

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

Gumagaling lamang ang checksum kapag may redundancy ang pool

May checksum ang bawat block na sinusulat ng ZFS, at vine-verify ito sa bawat pagbasa. Palaging gumagana ang detection. Kailangan naman ng pangalawang kopya para sa repair.

Sa single-disk pool, sinasabi ng ZFS ang katotohanan at doon nagtatapos. Ganito ito iniuulat ng 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

Tinutukoy ang pangalan ng sirang file. Ibabalik sana ng ext4 ang mga byte na iyon nang walang komento, kaya mahalaga na rin ito. Hindi pa rin ito maaayos ng ZFS dahil walang pangalawang kopya sa pool na mapagkukunan ng repair.

Sa mirror, ang parehong read ay kinukuha mula sa maayos na bahagi, isinusulat muli 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 VPS, karaniwang redundant na ang storage ng host, madalas ay RAID 10 sa ilalim ng hypervisor. Pinoprotektahan ka nito laban sa nasirang drive. Hindi nito natutukoy kung kailan mali ang ibinalik na block dahil walang paraan ang array para malaman kung aling kopya ang tama. Alam ito ng ZFS dahil ikinukumpara nito ang data sa checksum na ito mismo ang nagsulat.

Kung mayroon kang isang virtual disk at gusto mo ng kaunting 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 isang sirang block, at wala itong magagawa kapag tuluyang nawala ang buong volume.

Binabasa ng scrub ang lahat ng nasa pool at vine-verify ang mga ito.

sudo zpool scrub tank
zpool status tank

Nagtatapos ang isang healthy pool sa linyang gaya ng scan: scrub repaired 0B in 00:04:11 with 0 errors. I-schedule ito; sapat na ang buwanang pagpapatakbo para sa maliit na pool.

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

Ang mga dataset ang yunit ng policy

Ang dataset ay isang filesystem sa loob ng pool, at mura lang itong gawin, kaya gumawa ng tig-iisang dataset para sa bawat job. Namamana nito ang mga property mula sa pool. Ibig sabihin, isang beses mo lang itatakda ang default at io-override ito kung saan kinakailangan.

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 hindi pinapagana dahil sa pag-iingat, pero baligtad iyon sa dapat gawin. Kaunting CPU lang ang kailangan ng lz4 at binabawasan nito ang bytes na kailangang umabot sa disk. Kaya sa compressible data, kadalasan ay mas mabilis ang reads at writes. Mas mataas ang compression ng zstd kapalit ng mas maraming CPU. Angkop ito sa logs at archives na bihira mong basahin muli. Gamitin ang zfs get compressratio tank para suriin ang aktuwal na nakukuha mong resulta, at tandaan na binibilang lang ng ratio ang data na naisulat matapos itakda ang property.

Ang recordsize ang pinakamalaking block na isinusulat ng isang dataset; 128K ang default. Kapag nagsusulat ang database ng 8 KiB pages sa 128 KiB records, ang isang maliit na write ay nagiging read ng buong record, pagbabago, at panibagong write. Itakda ang recordsize=16K sa database dataset bago i-load ang data, dahil nalalapat lang ang property sa mga bagong naisulat na block.

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

Walang gastos ang snapshots hanggang sa mabago ang data

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

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

Ang laman ng column na USED para sa isang snapshot ay ang space na eksklusibong ginagamit ng snapshot na iyon. Nagsisimula ito sa halos zero at lumalaki kapag binago o dinelete mo ang data, dahil hindi na maaaring i-release ang mga lumang block.

Hindi kailangan ng restore step 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 directory na .zfs kahit sa ls -a hanggang patakbuhin mo ang sudo zfs set snapdir=visible tank/data. Gawin ang snapshot bago mo ito kailanganin, dahil kapag wala nito, maaaring ihulog ka ng isang maling rm -rf sa recovery path ng ext4, na nagsisimula sa pag-unmount ng disk at lalo pang lumalala mula roon.

Itinatapon ng rollback ang lahat ng naisulat mula noong snapshot.

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

Tumatanggi ito kapag may mas bagong snapshots, at winawasak 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 parehong pool ito, sa parehong volume, at sa parehong server. Kapag nag-fail ang volume o na-zpool destroy ito, kasama nitong mawawala ang snapshots at ang data. Pinoprotektahan ka ng snapshots laban sa sarili mong rm at sa maling upgrade. Sinasaklaw nito ang maraming totoong insidente, pero wala itong proteksiyon laban sa anumang mangyari sa pool mismo. Nakalahad ang buong paliwanag dito: kung bakit hindi backup ang VPS snapshot.

Magpadala at tumanggap: replication gamit ang isang command

Ginagawang byte stream ng zfs send ang isang snapshot sa standard output, at ibinabalik ng zfs receive ang stream na iyon bilang dataset. Full send ang unang kopya.

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 nasa receiving side pa rin ang snapshot na pinagmumulan ng ipinapadala mo. Kapag wala ito, hihinto ang receive nang 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 panig, o magsimula 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.

Isa itong tunay na off-site backup na may isang kondisyon. Dapat ZFS pool ang far end, dahil hindi makatatanggap ng stream ang object storage. Kapag S3-compatible storage o plain Linux host ang target mo, gumamit ng tool na sumusuporta rito, at sinasaklaw ng restic backups mula sa isang VPS ang paraang iyon.

Bakit napakaraming RAM ang 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. Binibilang ito bilang memory in use. Ang ZFS box na mukhang halos puno ang memory ay karaniwang may warm cache, at ito ang dahilan ng karamihan sa mga ulat na “kinain ng ZFS ang RAM ko.”

Malaki ang default limit dahil sinadya ito. Itinatakda ng OpenZFS 2.3 ang maximum ARC size sa mas malaki sa RAM minus 1 GiB at 5/8 ng RAM. Ginamit naman ng OpenZFS 2.2 at mas luma ang kalahati ng RAM sa Linux, habang ginagamit na ng FreeBSD ang mas bagong rule. Patakbuhin ang zfs version upang 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 figure na iyon ay batay sa documented default rule na inilapat sa karaniwang instance size, hindi sa mga sukat mula sa isang tumatakbong box. Sa 4 GB instance, pinapayagan ng 2.3 rule ang ARC na 3 GiB. Sa parehong box na gumagamit ng 2.2, hanggang 2 GiB lamang ang ARC. Sa 2 GB instance sa ilalim ng 2.3 rule, pinapayagan pa rin ang 1.25 GiB. Ang application mo ang gagamit ng natitirang memory.

Kunin ang aktuwal na mga numero 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.

Ibinabalik ng ARC ang memory kapag kailangan. Nagpapadala ang kernel ng pressure signal at lumiit ang ARC. Ang problema ay ang timing, dahil ang pressure ang nag-uudyok 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 isang maliit na VPS

Tukuyin muna ang memory na kailangan 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 value ang 512 MiB hanggang 1 GiB na ARC.

Itakda ito habang tumatakbo ang system, sa bytes. Ang halimbawang ito ay 1 GiB.

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

Gawin itong persistent para manatili pagkatapos ng reboot.

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

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

May 2 caveat na direktang binanggit 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 mo ang value.

Sa FreeBSD, sysctl sa ilalim ng vfs.zfs.arc ang kumokontrol sa parehong 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 2 karagdagang memory rule para sa maliit na server. Iwanang naka-off ang deduplication dahil nasa memory ang dedup table. Ang karaniwang rule of thumb ay 1 hanggang 3 GB ng RAM bawat TB ng unique data. Huwag ding maglagay ng swap sa isang zvol, isang block device na hinango mula sa pool. Maaaring ma-deadlock ang machine kapag nag-swap sa filesystem na kasalukuyang nagtatangkang magpalaya ng memory. Panatilihin ang swap sa isang plain partition o swap file na nasa labas ng pool.

Kapag mas angkop ang ext4 o XFS kasama ng restic

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

• May 2 GB o 4 GB na RAM ang instance at kailangan ng workload ang buong kapasidad nito.
• Iisa lang ang virtual disk at walang second copy, kaya detection lang ang maibibigay ng ZFS at wala itong mapagkukunan para sa repair.
• Object storage o plain Linux host ang backup target mo, kaya walang makakatanggap doon ng zfs send stream.
• Nagpapatakbo ka ng Debian gamit ang 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 lang 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 lang ang mga ito. Para sa lahat ng iba pang sitwasyon, sapat na para sa karamihan ng parehong pangangailangan ang ext4 na gumagamit ng restic upang magsulat ng encrypted at deduplicated backups sa storage na hindi kontrolado ng server, nang hindi kumokonsumo ng memory.

Mga failure mode at ang mga string na makikita mo

Nawala ang pool matapos ang reboot. Nagpi-print ang zpool status ng 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 pinananatili itong awtomatiko ng sudo zpool set cachefile=/etc/zfs/zpool.cache tank. Nag-uulat ng cannot import 'tank': pool may be in use from other system ang pool na hindi maayos na na-export mula sa ibang system, at ino-override iyon ng sudo zpool import -f tank kapag nakatitiyak kang wala itong ibang host.

modprobe: FATAL: Module zfs not found in directory /lib/modules/6.12.0-... sa Debian matapos ang 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, nire-rebuild ito ng sudo apt install -y linux-headers-$(uname -r) at sudo dkms autoinstall, at ibinabalik ng sudo zpool import tank ang pool.

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

Tumataas ang CKSUM count sa zpool status. May ibinalik na sirang data ang nasa ilalim ng ZFS. Sa mirror, warning ang count at na-repair ang block. Sa single-disk pool, nawawala ang file; tinutukoy ito ng zpool status -v, at ire-restore mo ang file na iyon 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 napupunta sa disk. Sa puntong ito, mas mahusay para 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 mahalagang tanong ay kung gaano karaming RAM ang matitira para sa iyong application. Kapag walang tuning, pinapalaki ng OpenZFS 2.3 ang ARC hanggang sa mas malaki sa RAM minus 1 GiB at 5/8 ng RAM. Kaya maaaring ilaan ng isang 4 GB na server ang 3 GiB sa cache. Itakda ang zfs_arc_max sa halagang kaya ng iyong workload, pagkatapos ay kumpirmahin ito sa pagbasa sa linyang c_max mula sa /proc/spl/kstat/zfs/arcstats.

Backup ba ang ZFS snapshot?

Hindi. Nananatili ang snapshot sa parehong pool ng data. Nakaliligtas ito sa isang sirang rm at sa nabigong upgrade, ngunit nawawala 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 pamamagitan ng 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 nang ilabas ang OpenZFS 2.0 noong December 2020. Pareho rin ang mga command at on-disk format, at maaaring ilipat ang mga pool sa pagitan ng mga ito. Ang kaibahan ay nasa packaging. Kasama ang ZFS sa base system ng FreeBSD. Sa Linux, bawat distribution ang nagpapasya: ginagawa ng Ubuntu ang module bilang bahagi ng kernel packages nito, samantalang ginagawa ito ng Debian sa iyong machine gamit ang DKMS. Dahil dito, maaaring mawalan ka ng module pagkatapos ng kernel upgrade hanggang sa matagumpay itong ma-rebuild.

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

Nakikita ng ZFS ang corruption at tinutukoy nito ang file, ngunit hindi nito ito maaayos dahil kailangan ng repair ang pangalawang kopya ng block. Ang zfs set copies=2 sa isang dataset ay nagbibigay ng pangalawang kopyang iyon sa dobleng space. Sapat ito para sa sirang block, ngunit hindi para sa nawawalang volume. Ang mirror sa dalawang volume ang aktuwal na nakapag-aayos ng ganitong problema.

Pinapabagal ba ng compression ang server?

Karaniwang pinapabilis 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 disk I/O na natitipid nito. Itakda ang compression=lz4 sa root ng pool upang mamana ito ng bawat dataset, pagkatapos ay suriin ang zfs get compressratio tank kapag naisulat na ang aktuwal na data.