{"id":83582,"date":"2020-06-01T19:42:21","date_gmt":"2020-06-01T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost"},"modified":"2020-06-01T19:42:21","modified_gmt":"2020-06-01T17:42:21","slug":"osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"ZFS alapok: t\u00e1rol\u00f3rendszer \u00e9s teljes\u00edtm\u00e9ny","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"ZFS
\n
\nId\u00e9n tavasszal m\u00e1r megvitattuk n\u00e9h\u00e1ny bevezet\u0151 t\u00e9m\u00e1t, p\u00e9ld\u00e1ul hogyan ellen\u0151rizz\u00fck a merevlemezeink sebess\u00e9g\u00e9t<\/a><\/noindex> \u00e9s mi az a RAID<\/a><\/noindex>. A m\u00e1sodikban m\u00e9g meg is \u00edg\u00e9zt\u00fck, hogy folytatjuk a k\u00fcl\u00f6nb\u00f6z\u0151 t\u00f6bblemezes topol\u00f3gi\u00e1k teljes\u00edtm\u00e9ny\u00e9nek vizsg\u00e1lat\u00e1t ZFS alatt. Ez a k\u00f6vetkez\u0151 gener\u00e1ci\u00f3s f\u00e1jlrendszer, amely \u00e9ppen most terjed el az eg\u00e9sz vil\u00e1gon: a Apple<\/a><\/noindex> t\u00f3l Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nNos, ma a legjobb nap a ZFS megismer\u00e9s\u00e9re, k\u00edv\u00e1ncsi olvas\u00f3k. Csak tudj\u00e1tok, hogy a fejleszt\u0151 OpenZFS-t\u0151l, Matt Arens-t\u0151l sz\u00e1rmaz\u00f3 szer\u00e9ny becsl\u00e9s szerint \u201eez val\u00f3ban bonyolult.\u201d<\/p>\n

De miel\u0151tt eljutn\u00e1nk a sz\u00e1mokhoz \u2013 \u00e9s azok j\u00f6nni fognak, \u00edg\u00e9rem \u2013 a nyolclemezes ZFS konfigur\u00e1ci\u00f3k \u00f6sszes lehet\u0151s\u00e9g\u00e9r\u0151l, besz\u00e9lj\u00fcnk arr\u00f3l, hogyan<\/i> hogyan t\u00e1rolja egy\u00e1ltal\u00e1n a ZFS az adatokat a lemezen.<\/p>\n

Zpool, vdev \u00e9s device<\/h1>\n

\n\"ZFS
\nEz a teljes medence diagram h\u00e1rom seg\u00e9d vdev-et tartalmaz, mindegyik oszt\u00e1lyb\u00f3l egyet, \u00e9s n\u00e9gyet RAIDz2-hoz.<\/i><\/p>\n

\"ZFS
\n\u00c1ltal\u00e1ban nincs ok arra, hogy egy pool-t elt\u00e9r\u0151 t\u00edpus\u00fa \u00e9s m\u00e9ret\u0171 vdev-ekb\u0151l \u00e9p\u00edts\u00fcnk \u2013 de ha szeretn\u00e9d, semmi sem akad\u00e1lyoz meg benne.<\/i><\/p>\n

Ahhoz, hogy val\u00f3ban meg\u00e9rts\u00fck a ZFS f\u00e1jlrendszert, alaposan meg kell vizsg\u00e1lnunk annak t\u00e9nyleges strukt\u00far\u00e1j\u00e1t. El\u0151sz\u00f6r is, a ZFS egyes\u00edti a hagyom\u00e1nyos k\u00f6tetkezel\u00e9si \u00e9s f\u00e1jlrendszeri szinteket. M\u00e1sodszor, tranzakci\u00f3s m\u00e1sol\u00e1st alkalmaz \u00edr\u00e1s k\u00f6zben. Ezek a jellemz\u0151k azt jelentik, hogy a rendszer szerkezetileg nagyon elt\u00e9r a szok\u00e1sos f\u00e1jlrendszerekt\u0151l \u00e9s RAID t\u00f6mb\u00f6kt\u0151l. Az els\u0151 alapvet\u0151 \u00e9p\u00edt\u0151k\u00f6vek a meg\u00e9rt\u00e9shez: ez a t\u00e1rol\u00f3pul (zpool), a virtu\u00e1lis eszk\u00f6z (vdev) \u00e9s a val\u00f3di eszk\u00f6z (device).<\/p>\n

zpool<\/h3>\n

\nA t\u00e1rol\u00f3pul (zpool) a ZFS legfels\u0151 szerkezete. Minden pool tartalmaz egy vagy t\u00f6bb virtu\u00e1lis eszk\u00f6zt. Ezek viszont egy vagy t\u00f6bb val\u00f3di eszk\u00f6zt (device) tartalmaznak. A virtu\u00e1lis pool-ok \u00f6n\u00e1ll\u00f3 blokkok. Egy fizikai sz\u00e1m\u00edt\u00f3g\u00e9p tartalmazhat k\u00e9t vagy t\u00f6bb k\u00fcl\u00f6n pool-t, de mindegyik teljesen f\u00fcggetlen a t\u00f6bbit\u0151l. A pool-ok nem oszthatnak meg virtu\u00e1lis eszk\u00f6z\u00f6ket.<\/p>\n

A ZFS redundancia a virtu\u00e1lis eszk\u00f6z\u00f6k szintj\u00e9n tal\u00e1lhat\u00f3, nem pedig a pool-ok szintj\u00e9n. A pool-ok szintj\u00e9n egy\u00e1ltal\u00e1n nincs redundancia \u2013 ha b\u00e1rmelyik vdev vagy speci\u00e1lis vdev elveszik, akkor vele egy\u00fctt elveszik az eg\u00e9sz pool is.<\/p>\n

A modern storage pool can survive the loss of cache or a virtual device log\u2014although it may lose a small amount of dirty data if it loses the vdev log during a power outage or system crash.<\/p>\n

There is a common misconception that ZFS data stripes are written across the entire pool. This is incorrect. The zpool is not just a fun RAID0; it is rather more complex. JBOD<\/a><\/noindex> with a complex, variable distribution mechanism.<\/p>\n

For the most part, writes are distributed among the available virtual devices based on the free space available, so theoretically they will fill up simultaneously. In later versions of ZFS, current utilization of the vdev is taken into account\u2014if one virtual device is significantly more loaded than another (for example, due to read workload), it will be temporarily skipped for writing despite the highest free space ratio.<\/p>\n

The utilization detection mechanism embedded in modern ZFS write distribution methods can reduce latency and increase throughput during unusually high load periods\u2014but it does not provide a blank check for inadvertently mixing slow HDDs and fast SSDs in one pool. Such an unbalanced pool will still operate at the speed of the slowest device, as if it were entirely composed of such devices.<\/i> vdev<\/p>\n

Each storage pool consists of one or more virtual devices (virtual device, vdev). Each vdev, in turn, includes one or more physical devices. Most virtual devices are used for simple data storage, but there are several auxiliary classes of vdev, including CACHE, LOG, and SPECIAL. Each of these vdev types can have one of five topologies: single device, RAIDz1, RAIDz2, RAIDz3, or mirror.<\/h3>\n

\nA modern storage pool can survive the loss of cache or a virtual device log\u2014although it may lose a small amount of dirty data if it loses the vdev log during a power outage or system crash.<\/p>\n

A RAIDz1, RAIDz2 \u00e9s RAIDz3 a RAID p\u00e1rhuzamos (diagon\u00e1lis) parit\u00e1s speci\u00e1lis v\u00e1ltozatai, amit a r\u00e9gi id\u0151kben emlegettek. A 1, 2 \u00e9s 3 arra utal, h\u00e1ny parit\u00e1s blokk van kijel\u00f6lve minden adathalmazon. A parit\u00e1s nincs k\u00fcl\u00f6n\u00e1ll\u00f3 lemezeken, hanem a RAIDz virtu\u00e1lis eszk\u00f6z\u00f6k f\u00e9lig egyenletesen osztja el a lemezek k\u00f6z\u00f6tt. A RAIDz t\u00f6mb annyi lemezt tud elvesz\u00edteni, amennyi parit\u00e1s blokkja van; ha m\u00e9g egyet elvesz\u00edt, t\u00f6nkremegy \u00e9s mag\u00e1val viszi a t\u00e1rol\u00f3 medenc\u00e9t.<\/p>\n

T\u00fck\u00f6r virtu\u00e1lis eszk\u00f6z\u00f6kben (mirror vdev) minden blokk minden eszk\u00f6z\u00f6n t\u00e1rolva van. Hab\u00e1r a legelterjedtebb a dupla t\u00fck\u00f6r (two-wide), a t\u00fck\u00f6rben b\u00e1rmennyi eszk\u00f6z lehet \u2014 nagyobb telep\u00edt\u00e9sekben a beolvas\u00e1si teljes\u00edtm\u00e9ny \u00e9s az hibahat\u00e9konys\u00e1g n\u00f6vel\u00e9s\u00e9re gyakran alkalmaznak h\u00e1rmas t\u00fckr\u00f6ket. A t\u00fck\u00f6r vdev b\u00e1rmely hiba eset\u00e9n t\u00fal\u00e9l, am\u00edg legal\u00e1bb egy eszk\u00f6z m\u0171k\u00f6dik a vdev-ben.<\/p>\n

Az egyes vdev-ek l\u00e9nyeg\u00e9ben vesz\u00e9lyesek. Ez a virtu\u00e1lis eszk\u00f6z nem b\u00edr el egy hib\u00e1t sem \u2014 \u00e9s ha t\u00e1rol\u00f3k\u00e9nt vagy k\u00fcl\u00f6nleges vdev-k\u00e9nt haszn\u00e1lj\u00e1k, akkor hib\u00e1ja az eg\u00e9sz medence megsemmis\u00fcl\u00e9s\u00e9hez vezet. Itt nagyon, nagyon \u00f3vatosnak kell lenni.<\/p>\n

A CACHE, LOG \u00e9s SPECIAL virtu\u00e1lis eszk\u00f6z\u00f6k b\u00e1rmelyik fent eml\u00edtett topol\u00f3gia szerint l\u00e9trehozhat\u00f3k \u2014 de ne feledje, hogy a SPECIAL virtu\u00e1lis eszk\u00f6z elveszt\u00e9se a medence elveszt\u00e9s\u00e9t jelenti, \u00edgy er\u0151sen aj\u00e1nlott a redund\u00e1ns topol\u00f3gia.<\/p>\n

eszk\u00f6z<\/h3>\n

\nVal\u00f3sz\u00edn\u0171leg ez a legk\u00f6nnyebben \u00e9rthet\u0151 kifejez\u00e9s a ZFS-ben \u2014 ez sz\u00f3 szerint egy v\u00e9letlen hozz\u00e1f\u00e9r\u00e9s\u0171 blokk eszk\u00f6z. Ne feledje, hogy a virtu\u00e1lis eszk\u00f6z\u00f6k k\u00fcl\u00f6nb\u00f6z\u0151 eszk\u00f6z\u00f6kb\u0151l \u00e1llnak, m\u00edg a medence virtu\u00e1lis eszk\u00f6z\u00f6kb\u0151l k\u00e9sz\u00fcl.<\/p>\n

A lemezek \u2014 m\u00e1gneses vagy szil\u00e1rdtest \u2014 a legelterjedtebb blokk eszk\u00f6z\u00f6k, amelyeket a vdev \u00e9p\u00edt\u0151k\u00f6veik\u00e9nt haszn\u00e1lnak. Azonban b\u00e1rmilyen eszk\u00f6z, amely a \/dev k\u00f6nyvt\u00e1rban megtal\u00e1lhat\u00f3, megfelelhet \u2014 teh\u00e1t teljes hardver RAID t\u00f6mb\u00f6k is haszn\u00e1lhat\u00f3k k\u00fcl\u00f6n eszk\u00f6zk\u00e9nt.<\/p>\n

A nyers f\u00e1jl az egyik legfontosabb alternat\u00edv blokk eszk\u00f6z, amib\u0151l vdev \u00e9p\u00edthet\u0151. Tesztmedenc\u00e9kb\u0151l sz\u00e1rmazik sz\u00f3rt f\u00e1jlok<\/a><\/noindex>\u00a0\u2014 ez egy nagyon k\u00e9nyelmes m\u00f3dja a medence parancsainak tesztel\u00e9s\u00e9re \u00e9s annak ellen\u0151rz\u00e9s\u00e9re, hogy mennyi hely \u00e1ll rendelkez\u00e9sre a medenc\u00e9be vagy a virtu\u00e1lis eszk\u00f6zbe az adott topol\u00f3gi\u00e1ban.<\/p>\n

\"ZFS
\nT\u00f6bb m\u00e1sodperc alatt l\u00e9trehozhat egy tesztpultot t\u00f6redezett f\u00e1jlokkal \u2013 de ne felejtse el k\u00e9s\u0151bb elt\u00e1vol\u00edtani az \u00f6sszes pultot \u00e9s annak alkot\u00f3elemeit.<\/i> <\/p>\n

Tegy\u00fck fel, hogy nyolc lemezre szeretne kiszolg\u00e1l\u00f3t telep\u00edteni, \u00e9s 10 TB (~9300 GiB) lemezeket tervez haszn\u00e1lni \u2013 de nem biztos abban, hogy melyik topol\u00f3gia felel meg legjobban az ig\u00e9nyeinek. A fenti p\u00e9ld\u00e1ban n\u00e9h\u00e1ny m\u00e1sodperc alatt \u00e9p\u00edt\u00fcnk fel egy tesztpultot t\u00f6redezett f\u00e1jlokkal \u2013 \u00e9s most m\u00e1r tudjuk, hogy a nyolc 10 TB-os lemezb\u0151l \u00e1ll\u00f3 RAIDz2 vdev 50 TiB hasznos kapacit\u00e1st biztos\u00edt.<\/p>\n

Egy m\u00e1sik k\u00fcl\u00f6nleges eszk\u00f6zoszt\u00e1ly a SPARE (tartal\u00e9k). A hot-swap eszk\u00f6z\u00f6k, ellent\u00e9tben a norm\u00e1l eszk\u00f6z\u00f6kkel, az eg\u00e9sz pulthoz tartoznak, nem egy virtu\u00e1lis eszk\u00f6zh\u00f6z. Ha egy vdev a pultban meghib\u00e1sodik, \u00e9s a tartal\u00e9k eszk\u00f6z csatlakozik a pulthoz \u00e9s el\u00e9rhet\u0151, akkor automatikusan csatlakozik a s\u00e9r\u00fclt vdevhez.<\/p>\n

A s\u00e9r\u00fclt vdevhez val\u00f3 csatlakoz\u00e1s ut\u00e1n a tartal\u00e9k eszk\u00f6z elkezdi megkapni azokat a m\u00e1solatokat vagy rekonstrukci\u00f3kat, amelyeknek az elt\u0171nt eszk\u00f6z\u00f6n kell lenni\u00fck. A hagyom\u00e1nyos RAID-ben ez helyre\u00e1ll\u00edt\u00e1snak (rebuilding) nevezik, a ZFS-ben pedig a \"t\u00f6bblet helyre\u00e1ll\u00edt\u00e1s\u00e1nak\" (resilvering).<\/p>\n

Fontos megjegyezni, hogy a tartal\u00e9k eszk\u00f6z\u00f6k nem helyettes\u00edtik v\u00e9glegesen a meghib\u00e1sodott eszk\u00f6z\u00f6ket. Ez csup\u00e1n ideiglenes helyettes\u00edt\u00e9s a vdev degrad\u00e1ci\u00f3j\u00e1nak cs\u00f6kkent\u00e9s\u00e9re. Miut\u00e1n az adminisztr\u00e1tor kicser\u00e9li a meghib\u00e1sodott vdev eszk\u00f6zt, a t\u00f6bblet helyre\u00e1ll\u00edt\u00e1sa ennek a tart\u00f3s eszk\u00f6znek a kereszt\u00fcl t\u00f6rt\u00e9nik, a SPARE lev\u00e1lik a vdev-r\u0151l \u00e9s visszat\u00e9r a tartal\u00e9k munk\u00e1hoz az eg\u00e9sz pult sz\u00e1m\u00e1ra.<\/p>\n

Adatk\u00e9szletek, blokkok \u00e9s szektorok<\/h1>\n

\nA k\u00f6vetkez\u0151 \u00e9p\u00edt\u0151elemek, amelyeket meg kell \u00e9rten\u00fcnk a ZFS-en v\u00e9gzett utaz\u00e1sunk sor\u00e1n, nem annyira a hardverhez, hanem ink\u00e1bb arra vonatkoznak, hogyan vannak szervezve \u00e9s t\u00e1rolva maguk az adatok. Itt n\u00e9h\u00e1ny szintet kihagyunk \u2013 mint p\u00e9ld\u00e1ul a metaslab \u2013 hogy elker\u00fclj\u00fck a r\u00e9szletek t\u00falh\u00e1g\u00e1s\u00e1t, meg\u0151rizve az \u00e1ltal\u00e1nos szerkezet meg\u00e9rt\u00e9s\u00e9t.<\/p>\n

Adatk\u00e9szlet (dataset)<\/h3>\n

\n\"ZFS
\nAmikor el\u0151sz\u00f6r l\u00e9trehozzuk az adatk\u00e9szletet, az \u00f6sszes el\u00e9rhet\u0151 pultter\u00fcletet megjelen\u00edti. Ezut\u00e1n be\u00e1ll\u00edtjuk a kv\u00f3t\u00e1t \u2013 \u00e9s megv\u00e1ltoztatjuk a csatol\u00e1si pontot. Var\u00e1zslat!<\/i> <\/p>\n

\"ZFS
\nA Zvol nagyr\u00e9szt csak egy adatk\u00e9szlet, amely mentes a f\u00e1jlrendszer r\u00e9teg\u00e9t\u0151l, amelyet itt egy teljesen norm\u00e1lis ext4 f\u00e1jlrendszerrel helyettes\u00edt\u00fcnk.<\/i> <\/p>\n

A ZFS dataset is roughly analogous to a standard mounted file system. Like a regular file system, at first glance, it seems like 'just another folder.' However, just like regular mounted file systems, each ZFS dataset has its own set of underlying properties.<\/p>\n

First and foremost, a dataset can have an assigned quota. If you set zfs set quota=100G poolname\/datasetname<\/code>, you will not be able to write to the mounted folder \/poolname\/datasetname<\/code> more than 100 GiB.<\/p>\n

Did you notice the presence\u2014and absence\u2014of slashes at the beginning of each line? Each dataset has its own place in both the ZFS hierarchy and the system mount hierarchy. There is no leading slash in the ZFS hierarchy\u2014you begin with the pool name and then the path from one dataset to the next. For example, pool\/parent\/child<\/code> for a dataset named child<\/code> under the parent dataset parent<\/code> in a pool with a creative name pool<\/code>.<\/p>\n

By default, the mount point of the dataset will be equivalent to its name in the ZFS hierarchy, with a leading slash\u2014the pool named pool<\/code> will be mounted as \/pool<\/code>, the dataset parent<\/code> is mounted at \/pool\/parent<\/code>, and the child dataset child<\/code> is mounted at \/pool\/parent\/child<\/code>. However, the system mount point of the dataset can be changed.<\/p>\n

If we specify zfs set mountpoint=\/lol pool\/parent\/child<\/code>, the dataset pool\/parent\/child<\/code> will be mounted in the system as \/lol<\/code>.<\/p>\n

In addition to datasets, we must mention volumes (zvols). A volume is roughly analogous to a dataset, except it does not actually have a file system\u2014it is simply a block device. For example, you can create zvol<\/code> a n\u00e9vvel mypool\/myzvol<\/code>, then format it with the ext4 file system and then mount this file system\u2014now you have an ext4 file system but with all the safety features of ZFS! This may seem silly on one machine, but makes much more sense as a backend when exporting an iSCSI device.<\/p>\n

Egys\u00e9gek<\/h3>\n

\n\"ZFS
\nA file is represented by one or more blocks. Each block is stored on one virtual device. The block size is typically equal to the parameter recordsize<\/b>, but can be reduced to 2^ashift<\/b>, if it contains metadata or a small file.<\/i><\/p>\n

\"ZFS
\nWe are indeed not joking about the huge performance penalties if you set ashift too small. val\u00f3ban<\/b> Nem tr\u00e9f\u00e1lunk a teljes\u00edtm\u00e9ny jelent\u0151s cs\u00f6kken\u00e9s\u00e9vel, ha t\u00fal kicsi az ashift.<\/i><\/p>\n

A ZFS pool stores all data, including metadata, in blocks. The maximum block size for each dataset is defined by the property recordsize<\/code> (record size). The record size can be changed, but this will not affect the size or location of any blocks that have already been written to the dataset\u2014it only applies to new blocks as they are written.<\/p>\n

Unless otherwise specified, the current default record size is 128 KiB. This is somewhat of a trade-off, where the performance will not be ideal but not terrible in most cases. Recordsize<\/code> can be set to any value from 4K to 1M (with additional settings recordsize<\/code> it can be set even larger, but this is rarely a good idea).<\/p>\n

Any block references data from only one file\u2014you cannot fit two different files into one block. Each file is made up of one or more blocks, depending on the size. If the file size is less than the record size, it will be stored in a smaller block\u2014for example, a block with a 2 KiB file will occupy only one 4 KiB sector on the disk.<\/p>\n

Zvols do not have the property recordsize<\/code>\u00a0\u2014instead, they have an equivalent property volblocksize.<\/code>.<\/p>\n

Sectors<\/h3>\n

\nThe last, most basic building block is the sector. This is the smallest physical unit that can be written or read from the underlying device. For decades, most disks used 512-byte sectors. Recently, most disks are set to 4 KiB sectors, and in some cases\u2014especially SSDs\u20148 KiB sectors or even larger.<\/p>\n

ZFS has a property that allows you to manually set the sector size. This property ashift<\/code>. It's somewhat confusing that ashift is a power of two. For example, ashift=9<\/code> indicates a sector size of 2^9, or 512 bytes.<\/p>\n

A ZFS a m\u0171veletek sor\u00e1n r\u00e9szletes inform\u00e1ci\u00f3t k\u00e9r a m\u0171k\u00f6d\u00e9si rendszert\u0151l minden egyes blokkeszk\u00f6zr\u0151l, amikor az \u00faj vdev-re ker\u00fcl hozz\u00e1ad\u00e1sra, \u00e9s elm\u00e9letileg automatikusan helyesen \u00e1ll\u00edtja be az ashift \u00e9rt\u00e9k\u00e9t ezen inform\u00e1ci\u00f3k alapj\u00e1n. Sajnos sok meghajt\u00f3 hazudik a szektor m\u00e9ret\u00e9r\u0151l, hogy meg\u0151rizze a Windows XP-vel val\u00f3 kompatibilit\u00e1st (amely nem volt k\u00e9pes meg\u00e9rteni a k\u00fcl\u00f6nb\u00f6z\u0151 szektor m\u00e9reteket).<\/p>\n

Ez\u00e9rt a ZFS rendszergazd\u00e1inak er\u0151sen aj\u00e1nlott tudniuk eszk\u00f6zeik val\u00f3di szektor m\u00e9ret\u00e9t \u00e9s k\u00e9zzel be\u00e1ll\u00edtani ashift<\/code>. Ha az ashift t\u00fal kicsi, az rendk\u00edv\u00fcli m\u00e9rt\u00e9kben megn\u00f6veli az \u00edr\u00e1si\/olvas\u00e1si m\u0171veletek sz\u00e1m\u00e1t. \u00cdgy p\u00e9ld\u00e1ul egy 512 b\u00e1jtos \"szektor\" \u00edr\u00e1sa egy val\u00f3s 4 KiB szektorba azt jelenti, hogy el\u0151sz\u00f6r az els\u0151 \"szektort\" kell \u00edrni, majd olvasni egy 4 KiB szektort, m\u00f3dos\u00edtani azt a m\u00e1sodik 512 b\u00e1jtos \"szektorral\", majd vissza kell \u00edrni az \u00faj 4 KiB szektorba, \u00e9s \u00edgy tov\u00e1bb minden \u00edr\u00e1sn\u00e1l.<\/p>\n

A val\u00f3s vil\u00e1gban ez a b\u00fcntet\u00e9s s\u00falyosan \u00e9rinti a Samsung EVO SSD-ket, amelyekre kell, hogy \u00e9rv\u00e9nyes legyen ashift=13<\/code>, de ezek az SSD-k hazudnak a szektor m\u00e9ret\u00fckr\u0151l, ez\u00e9rt alap\u00e9rtelmez\u00e9s szerint be van \u00e1ll\u00edtva ashift=9<\/code>. Ha a tapasztalt rendszergazda nem m\u00f3dos\u00edtja ezt a be\u00e1ll\u00edt\u00e1st, akkor ez az SSD lassabban<\/i> fog m\u0171k\u00f6dni, mint a hagyom\u00e1nyos m\u00e1gneses HDD.<\/p>\n

\u00d6sszehasonl\u00edt\u00e1sk\u00e9ppen, a t\u00fal nagy m\u00e9ret eset\u00e9n ashift<\/code> gyakorlatilag nincs b\u00fcntet\u00e9s. Val\u00f3di teljes\u00edtm\u00e9nycs\u00f6kken\u00e9s nincs, \u00e9s a kihaszn\u00e1latlan ter\u00fclet v\u00e9gtelen\u00fcl kicsi (vagy nulla, ha t\u00f6m\u00f6r\u00edt\u00e9s be van kapcsolva). Ez\u00e9rt er\u0151sen javasoljuk, hogy m\u00e9g azoknak a meghajt\u00f3knak is, amelyek val\u00f3ban 512 b\u00e1jtos szektorokat haszn\u00e1lnak, \u00e1ll\u00edts\u00e1k be ashift=12<\/code> vagy ak\u00e1r ashift=13<\/code>, hogy magabiztosan tekintsenek a j\u00f6v\u0151be.<\/p>\n

A ashift<\/code> az egyes virtu\u00e1lis eszk\u00f6z\u00f6k vdev-re van be\u00e1ll\u00edtva, nem pedig a t\u00e1rol\u00f3ra, ahogy sokan t\u00e9vesen gondolj\u00e1k \u2014 \u00e9s a be\u00e1ll\u00edt\u00e1s ut\u00e1n nem v\u00e1ltoztathat\u00f3 meg. Ha v\u00e9letlen\u00fcl hib\u00e1t v\u00e9t a \u00faj vdev t\u00e1rol\u00f3ra t\u00f6rt\u00e9n\u0151 hozz\u00e1ad\u00e1sa sor\u00e1n, akkor v\u00e9glegesen fert\u0151zte el ezt a t\u00e1rol\u00f3t egy alacsony teljes\u00edtm\u00e9ny\u0171 eszk\u00f6zzel, \u00e9s \u00e1ltal\u00e1ban nincs m\u00e1s megold\u00e1s, mint megsemmis\u00edteni a t\u00e1rol\u00f3t, \u00e9s minden \u00fajra kezdeni. M\u00e9g a vdev t\u00f6rl\u00e9se sem ment meg a hib\u00e1s be\u00e1ll\u00edt\u00e1st\u00f3l.<\/i>\u00cdr\u00e1s k\u00f6zben m\u00e1sol\u00f3 mechanizmus ashift<\/code> Ha egy szok\u00e1sos f\u00e1jlrendszernek \u00fajra kell \u00edrnia az adatokat \u2014 m\u00f3dos\u00edtja minden blokkot, ahol az megtal\u00e1lhat\u00f3. ashift<\/code>!<\/p>\n

\u00cdr\u00e1s k\u00f6zbeni m\u00e1sol\u00e1s mechanizmusa.<\/h3>\n

\n\"ZFS
\nHa egy hagyom\u00e1nyos f\u00e1jlrendszernek \u00fajra kell \u00edrnia az adatokat - akkor ott, ahol vannak, m\u00f3dos\u00edtja minden blokkot.<\/i><\/p>\n

\"ZFS
\nA f\u00e1jlrendszer \u00edr\u00e1s k\u00f6zbeni m\u00e1sol\u00e1sa \u00faj verzi\u00f3t \u00edr a blokkra, majd feloldja a r\u00e9gi verzi\u00f3t.<\/i><\/p>\n

\"ZFS
\nAbsztrakt \u00e9rtelemben, ha figyelmen k\u00edv\u00fcl hagyjuk a blokkok val\u00f3di fizikai elhelyezked\u00e9s\u00e9t, adataink \"kom\u00e9t\u00e1ja\" leegyszer\u0171s\u00f6dik \"adatf\u00e9regg\u00e9\", amely balr\u00f3l jobbra mozog a rendelkez\u00e9sre \u00e1ll\u00f3 t\u00e9rk\u00e9p\u00e9n.<\/i><\/p>\n

\"ZFS
\nMost j\u00f3 k\u00e9pet kaphatunk arr\u00f3l, hogyan m\u0171k\u00f6dnek az \u00edr\u00e1s k\u00f6zbeni pillanatk\u00e9pek \u2013 minden blokk t\u00f6bb pillanatk\u00e9phez is tartozhat, \u00e9s megmarad, am\u00edg az \u00f6sszes kapcsol\u00f3d\u00f3 pillanatk\u00e9pet el nem t\u00e1vol\u00edtj\u00e1k.<\/i><\/p>\n

Az \u00edr\u00e1s k\u00f6zbeni m\u00e1sol\u00e1s mechanizmusa (Copy on Write, CoW) a ZFS csod\u00e1latos rendszer\u00e9nek alapvet\u0151 alapja. Az alap\u00f6tlet egyszer\u0171 \u2013 ha megk\u00e9rdezi a hagyom\u00e1nyos f\u00e1jlrendszert, hogy m\u00f3dos\u00edtson egy f\u00e1jlt, ez pontosan azt teszi, amit k\u00e9r. Ha azonban \u00edr\u00e1s k\u00f6zbeni m\u00e1sol\u00e1sra k\u00e9r egy f\u00e1jlrendszert, \u0151 azt mondja: 'rendben' \u2013 de hazudik \u00d6nnek.<\/p>\n

Ehelyett az \u00edr\u00e1s k\u00f6zbeni m\u00e1sol\u00e1ssal dolgoz\u00f3 f\u00e1jlrendszer \u00faj verzi\u00f3t \u00edr a m\u00f3dos\u00edtott blokkhoz, majd friss\u00edti a f\u00e1jl metadat\u00e1j\u00e1t, hogy megszak\u00edtsa a kapcsolatot a r\u00e9gi blokkal, \u00e9s \u00f6sszekapcsolja a leg\u00fajabb v\u00e9grehajtott blokkra.<\/p>\n

A r\u00e9gi blokk lev\u00e1laszt\u00e1sa \u00e9s az \u00faj \u00f6sszekapcsol\u00e1sa egyetlen m\u0171veletk\u00e9nt val\u00f3sul meg, ez\u00e9rt azt nem lehet megszak\u00edtani \u2013 ha \u00e1ramtalan\u00edtja, miut\u00e1n ez megt\u00f6rt\u00e9nt, \u00faj verzi\u00f3ja lesz a f\u00e1jlnak, ha pedig kor\u00e1bban, akkor a r\u00e9gi verzi\u00f3t kapja meg. Mindk\u00e9t esetben nem ker\u00fcl konfliktus a f\u00e1jlrendszeren bel\u00fcl.<\/p>\n

A ZFS \u00edr\u00e1s k\u00f6zbeni m\u00e1sol\u00e1sa nemcsak a f\u00e1jlrendszeren, hanem a lemezkezel\u00e9s szintj\u00e9n is zajlik. Ez azt jelenti, hogy a ZFS nem szenved a \"zsugorod\u00e1si r\u00e9s\"-t\u0151l (RAID hiba<\/a><\/noindex>) \u2013 ez egy olyan jelens\u00e9g, amikor a s\u00e1v csak r\u00e9szlegesen \u00edr\u00f3dik, miel\u0151tt a rendszer \u00f6sszeomlik, \u00e9s a t\u00f6mb megs\u00e9r\u00fcl a rendszer \u00fajraind\u00edt\u00e1sa ut\u00e1n. Itt a s\u00e1v atomikusan \u00edr\u00f3dik, a vdev mindig k\u00f6vetkezetes, \u00e9s Bob a nagyb\u00e1ty\u00e1d<\/a><\/noindex>.<\/p>\n

ZIL: a ZFS sz\u00e1nd\u00e9knapl\u00f3ja<\/h3>\n

\n\"ZFS
\nA ZFS rendszer a szinkron \u00edr\u00e1sokat k\u00fcl\u00f6n m\u00f3don kezeli \u2013 ideiglenesen, de azonnal meg\u0151rzi azokat a ZIL-be, miel\u0151tt k\u00e9s\u0151bb v\u00e9gleg bejegyezn\u00e9 azokat az aszinkron \u00edr\u00e1sokkal egy\u00fctt.<\/i><\/p>\n

\"ZFS
\n\u00c1ltal\u00e1ban a ZIL-en \u00edrt adatokat soha t\u00f6bb\u00e9 nem olvass\u00e1k vissza. De ez lehets\u00e9ges rendszerhiba ut\u00e1n.<\/i><\/p>\n

\"ZFS
\nA SLOG, vagyis m\u00e1sodlagos LOG-eszk\u00f6z, egy speci\u00e1lis - \u00e9s lehet\u0151leg nagyon gyors - vdev, ahol a ZIL k\u00fcl\u00f6n gy\u0171jthet\u0151 a f\u0151 t\u00e1rol\u00f3t\u00f3l.<\/i><\/p>\n

\"ZFS
\nHiba ut\u00e1n az \u00f6sszes piszkos adat a ZIL-ben vissza\u00e1ll\u00edt\u00e1sra ker\u00fcl - ebben az esetben a ZIL a SLOG-on van, \u00edgy pontosan onnan t\u00f6rt\u00e9nik a vissza\u00e1ll\u00edt\u00e1s.<\/i><\/p>\n

K\u00e9t f\u0151 kateg\u00f3ri\u00e1ja van a fel\u00edr\u00e1si m\u0171veleteknek - szinkron (sync) \u00e9s aszinkron (async). A legt\u00f6bb munkaterhel\u00e9s eset\u00e9n a fel\u00edr\u00e1si m\u0171veletek t\u00falnyom\u00f3 t\u00f6bbs\u00e9ge aszinkron - a f\u00e1jlrendszer lehet\u0151v\u00e9 teszi azok aggreg\u00e1l\u00e1s\u00e1t \u00e9s csomagokba val\u00f3 kiad\u00e1s\u00e1t, cs\u00f6kkentve a t\u00f6redezetts\u00e9get \u00e9s jelent\u0151sen n\u00f6velve a s\u00e1vsz\u00e9less\u00e9get.<\/p>\n

A szinkron fel\u00edr\u00e1sok teljesen m\u00e1s k\u00e9rd\u00e9s. Amikor egy alkalmaz\u00e1s szinkron fel\u00edr\u00e1st k\u00e9r, azt mondja a f\u00e1jlrendszernek: \"Ezt r\u00f6gz\u00edtened kell az energi\u00e1t nem ig\u00e9nyl\u0151 mem\u00f3ri\u00e1ban, \u00e9s addig nem csin\u00e1lhatok semmi m\u00e1st\". Ez\u00e9rt a szinkron fel\u00edr\u00e1sokat azonnal r\u00f6gz\u00edteni kell a lemezen - \u00e9s ha ez n\u00f6veli a t\u00f6redezetts\u00e9get vagy cs\u00f6kkenti a s\u00e1vsz\u00e9less\u00e9get, akkor az \u00edgy van. most azonnal<\/i>A ZFS elt\u00e9r\u0151en kezeli a szinkron fel\u00edr\u00e1sokat, mint a szok\u00e1sos f\u00e1jlrendszerek - ahelyett, hogy azonnal a norm\u00e1l t\u00e1rol\u00f3ba \u00edrn\u00e1 \u0151ket, a ZFS egy speci\u00e1lis t\u00e1rol\u00e1si ter\u00fcleten r\u00f6gz\u00edti \u0151ket, amely a ZFS Sz\u00e1nd\u00e9knapl\u00f3 (ZFS Intent Log, vagy ZIL) n\u00e9ven ismert. A tr\u00fckk az, hogy ezek a fel\u00edr\u00e1sok<\/p>\n

a mem\u00f3ri\u00e1ban maradnak, aggreg\u00e1lva a norm\u00e1l aszinkron fel\u00edr\u00e1si k\u00e9relmekkel, hogy k\u00e9s\u0151bb a t\u00e1rol\u00f3ra norm\u00e1lis TXG-k\u00e9nt (tranzakci\u00f3csoportok, Transaction Groups) le\u00edrhat\u00f3k legyenek. szint\u00e9n<\/i> Norm\u00e1l m\u0171k\u00f6d\u00e9s eset\u00e9n a ZIL folyamatosan \u00edr\u00f3dik \u00e9s soha nem olvass\u00e1k vissza. Amikor n\u00e9h\u00e1ny pillanaton bel\u00fcl a ZIL-b\u0151l sz\u00e1rmaz\u00f3 fel\u00edr\u00e1sok a f\u0151 t\u00e1rol\u00f3ban norm\u00e1lis TXG-k\u00e9nt ker\u00fclnek r\u00f6gz\u00edt\u00e9sre a mem\u00f3ri\u00e1b\u00f3l, a ZIL-t\u0151l elt\u00e1vol\u00edtj\u00e1k \u0151ket. Az egyetlen alkalom, amikor valamit olvasnak a ZIL-b\u0151l, az a medence import\u00e1l\u00e1sakor t\u00f6rt\u00e9nik.<\/p>\n

Ha ZFS hiba l\u00e9p fel - oper\u00e1ci\u00f3s rendszer hiba vagy \u00e1ramsz\u00fcnet - amikor a ZIL-ben adatok tal\u00e1lhat\u00f3k, ezek az adatok a k\u00f6vetkez\u0151 medence import\u00e1l\u00e1sakor (p\u00e9ld\u00e1ul a v\u00e9szhelyzeti rendszer \u00fajraind\u00edt\u00e1sakor) olvas\u00e1sra ker\u00fclnek. Minden, ami a ZIL-ben van, olvas\u00e1sra ker\u00fcl, csoportos\u00edtva TXG-k\u00e9, r\u00f6gz\u00edtve a f\u0151 t\u00e1rol\u00f3ban, majd elt\u00e1vol\u00edtva a ZIL-b\u0151l az import\u00e1l\u00e1s folyamat\u00e1ban.<\/p>\n

Ha a ZFS le\u00e1ll - p\u00e9ld\u00e1ul oper\u00e1ci\u00f3s rendszer hiba vagy \u00e1ramsz\u00fcnet k\u00f6vetkezik be, mik\u00f6zben a ZIL-ben adatok tal\u00e1lhat\u00f3k, ezek az adatok a k\u00f6vetkez\u0151 medence import\u00e1l\u00e1sakor ker\u00fclnek beolvas\u00e1sra (p\u00e9ld\u00e1ul a v\u00e9szhelyzetben \u00fajraind\u00edtott rendszer eset\u00e9n). Minden, ami a ZIL-ben van, be lesz olvasva, TXG csoportokba lesz \u00f6sszegy\u0171jtve, r\u00f6gz\u00edtve a f\u0151 t\u00e1rol\u00f3ban, majd lev\u00e1lasztva a ZIL-r\u0151l az import\u00e1l\u00e1s folyamat\u00e1ban.<\/p>\n

Az vdev seg\u00e9doszt\u00e1lyok egyik\u00e9t LOG-nak vagy SLOG-nak h\u00edvj\u00e1k, a m\u00e1sodlagos LOG-eszk\u00f6zt. Ennek a feladata egy k\u00fcl\u00f6n vdev biztos\u00edt\u00e1sa a pool sz\u00e1m\u00e1ra, amely lehet\u0151leg sokkal gyorsabb, \u00e9s rendk\u00edv\u00fcl magas \u00edr\u00e1si ellen\u00e1ll\u00e1ssal b\u00edr, a ZIL t\u00e1rol\u00e1s\u00e1ra, ahelyett, hogy a ZIL-t a f\u0151 vdev t\u00e1roln\u00e1. A ZIL ugyan\u00fagy viselkedik, f\u00fcggetlen\u00fcl a t\u00e1rol\u00e1s hely\u00e9t\u0151l, de ha a vdev LOG-j\u00e1nak rendk\u00edv\u00fcl magas az \u00edr\u00e1si teljes\u00edtm\u00e9nye, akkor a szinkron \u00edr\u00e1sok gyorsabban fognak t\u00f6rt\u00e9nni.<\/p>\n

A vdev LOG hozz\u00e1ad\u00e1sa a poolhoz semmilyen m\u00f3don nem tudja<\/b> jav\u00edtani az aszinkron \u00edr\u00e1s teljes\u00edtm\u00e9ny\u00e9t - m\u00e9g akkor is, ha minden \u00edr\u00e1st k\u00e9nyszer\u00edtetten v\u00e9grehajtasz a ZIL-en, a zfs set sync=always<\/code>, akkor is a f\u0151 t\u00e1rol\u00f3hoz a TXG-ben, ugyanolyan m\u00f3don \u00e9s ugyanabban a temp\u00f3ban fognak k\u00f6t\u0151dni, mint napl\u00f3 n\u00e9lk\u00fcl. Az egyetlen k\u00f6zvetlen teljes\u00edtm\u00e9nyn\u00f6veked\u00e9s a szinkron \u00edr\u00e1s k\u00e9s\u00e9se (mivel a nagyobb napl\u00f3sebess\u00e9g felgyors\u00edtja a m\u0171veletek v\u00e9grehajt\u00e1s\u00e1t. sync<\/code>).<\/p>\n

Azonban egy olyan k\u00f6rnyezetben, amely m\u00e1r sok szinkron \u00edr\u00e1st ig\u00e9nyel, a vdev LOG k\u00f6zvetett m\u00f3don felgyors\u00edthatja az aszinkron \u00edr\u00e1st \u00e9s a gyors\u00edt\u00f3t\u00e1r n\u00e9lk\u00fcli olvas\u00e1st. A ZIL \u00edr\u00e1sainak egy k\u00fcl\u00f6n vdev LOG-ba val\u00f3 kiad\u00e1sa kevesebb versenyt jelent a f\u0151 t\u00e1rol\u00f3 IOPS-j\u00e1\u00e9rt, ami bizonyos m\u00e9rt\u00e9kig n\u00f6veli minden olvas\u00e1si \u00e9s \u00edr\u00e1si m\u0171velet teljes\u00edtm\u00e9ny\u00e9t.<\/p>\n

F\u00e9nyk\u00e9pek<\/h3>\n

\nA m\u00e1sol\u00e1s \u00edr\u00e1sa mechanizmusa szint\u00e9n sz\u00fcks\u00e9ges alapja az atomikus ZFS pillanatfelv\u00e9teleknek \u00e9s az inkrement\u00e1lis aszinkron replik\u00e1ci\u00f3nak. Egy akt\u00edv f\u00e1jlrendszerben egy mutat\u00f3fa tal\u00e1lhat\u00f3, amely az aktu\u00e1lis adatokkal rendelkez\u0151 \u00f6sszes \u00edr\u00e1st jel\u00f6li - amikor pillanatfelv\u00e9telt k\u00e9sz\u00edtesz, csup\u00e1n ennek a mutat\u00f3f\u00e1nak a m\u00e1solat\u00e1t k\u00e9sz\u00edted el.<\/p>\n

Amikor egy akt\u00edv f\u00e1jlrendszerben egy \u00edr\u00e1st fel\u00fcl\u00edrnak, a ZFS el\u0151sz\u00f6r az \u00faj blokk verzi\u00f3j\u00e1t az nem haszn\u00e1lt t\u00e9rs\u00e9gbe \u00edrja. Ezut\u00e1n lev\u00e1lasztja a blokk r\u00e9gi verzi\u00f3j\u00e1t az aktu\u00e1lis f\u00e1jlrendszerr\u0151l. De ha egy pillanatfelv\u00e9tel hivatkozik a r\u00e9gi blokkra, az v\u00e1ltozatlan marad. A r\u00e9gi blokk t\u00e9nylegesen nem lesz helyre\u00e1ll\u00edtva szabad t\u00e9rk\u00e9nt, am\u00edg az \u00f6sszes olyan pillanatfelv\u00e9tel, amely hivatkozik erre a blokkra, el nem pusztul!<\/p>\n

Replik\u00e1ci\u00f3<\/h3>\n

\n\"ZFS
\nA Steam k\u00f6nyvt\u00e1ram 2015-ben 158 GiB helyet foglalt el, \u00e9s 126 927 f\u00e1jlt tartalmazott. Ez el\u00e9g k\u00f6zel \u00e1ll a rsync optim\u00e1lis helyzet\u00e9hez - a ZFS h\u00e1l\u00f3zaton val\u00f3 replik\u00e1l\u00e1sa \"csup\u00e1n\" 750%-kal volt gyorsabb.<\/i><\/p>\n

\"ZFS
\nUgyanabban a h\u00e1l\u00f3zatban egy 40 GiB m\u00e9ret\u0171 Windows 7 virtu\u00e1lis g\u00e9p k\u00e9pf\u00e1jlj\u00e1nak replik\u00e1l\u00e1sa - teljesen m\u00e1s t\u00f6rt\u00e9net. A ZFS replik\u00e1ci\u00f3 289-szer gyorsabb, mint az rsync - vagy \"csak\" 161-szer gyorsabb, ha el\u00e9g j\u00f3nak tartja mag\u00e1t ahhoz, hogy az rsync-t a --inplace kapcsol\u00f3val h\u00edvja meg.<\/i><\/p>\n

\"ZFS
\nAmikor a virtu\u00e1lis g\u00e9p k\u00e9pe m\u00e9retez\u0151dik, az rsync probl\u00e9m\u00e1i is vele egy\u00fctt n\u00f6vekednek. Az 1,9 TiB nem t\u00fal nagy a modern virtu\u00e1lis g\u00e9p k\u00e9pe sz\u00e1m\u00e1ra - de el\u00e9g nagy ahhoz, hogy a ZFS replik\u00e1ci\u00f3 1148-szor gyorsabb legyen, mint az rsync, m\u00e9g az rsync --inplace param\u00e9ter\u00e9vel is.<\/i><\/p>\n

Once you understand how snapshots work, it won't be difficult to grasp the essence of replication. Since a snapshot is just a tree of pointers to records, it follows that if we create a zfs send<\/code> snapshot, we are also sending this tree and all associated records. When we transmit this zfs send<\/code> be. zfs receive<\/code> to the target object, it records both the actual block content and the tree of pointers referencing the blocks into the target dataset.<\/p>\n

It gets even more interesting on the second zfs send<\/code>. Now we have two systems, each containing poolname\/datasetname@1<\/code>, and you take a new snapshot poolname\/datasetname@2<\/code>. So in the source pool, you have datasetname@1<\/code> \u00e9s datasetname@2<\/code>, while in the target pool, there is only the first snapshot for now. datasetname@1<\/code>.<\/p>\n

Since we have a common snapshot between the source and target, we can perform an datasetname@1<\/code>incremental on top of it. When we tell the system<\/i> zfs send<\/code> zfs send -i poolname\/datasetname@1 poolname\/datasetname@2 , it compares the two pointer trees. Any pointers that exist only in<\/code>, obviously point to new blocks\u2014so we will need the content of those blocks. @2<\/code>On the remote system, handling the incremental<\/p>\n

is just as simple. First, we write all new records included in the stream send<\/code> , and then we add pointers to these blocks. Voila, we have send<\/code>in the new system! @2<\/code> Asynchronous incremental ZFS replication is a huge improvement over earlier non-snapshot-based methods like rsync. In both cases, only changed data is transmitted\u2014but rsync must first<\/p>\n

read all data from both sides to check the checksum and compare it. In contrast, ZFS replication reads nothing but pointer trees\u2014and any blocks that are not represented in the common snapshot. elolvashat\u00f3<\/i> Az \u00f6sszes adat mindk\u00e9t oldalr\u00f3l ellen\u0151rizve a sz\u00e1mot \u00e9s \u00f6sszehasonl\u00edtva azt. Ezzel szemben a ZFS replik\u00e1ci\u00f3 nem olvas el semmit, csak a mutat\u00f3f\u00e1kat - \u00e9s b\u00e1rmilyen blokkot, amely nem szerepel a k\u00f6z\u00f6s pillanatk\u00e9pen.<\/p>\n

Be\u00e9p\u00edtett t\u00f6m\u00f6r\u00edt\u00e9s<\/h3>\n

\nA fel\u00edr\u00e1si m\u00e1sol\u00e1si mechanizmus szint\u00e9n egyszer\u0171s\u00edti a be\u00e9p\u00edtett t\u00f6m\u00f6r\u00edt\u00e9si rendszert. Hagyom\u00e1nyos f\u00e1jlrendszerekben a t\u00f6m\u00f6r\u00edt\u00e9s probl\u00e9m\u00e1s \u2014 a m\u00f3dos\u00edtott adatok r\u00e9gi \u00e9s \u00faj verzi\u00f3ja ugyanabban a ter\u00fcleten tal\u00e1lhat\u00f3.<\/p>\n

Ha megn\u00e9z\u00fcnk egy adaterekly\u00e9t egy f\u00e1jl k\u00f6zep\u00e9n, amely a 0x00000000-b\u00f3l indul\u00f3 megab\u00e1jt null\u00e1kb\u00f3l \u00e1ll \u2014 ezt k\u00f6nnyen t\u00f6m\u00f6r\u00edthetj\u00fck egy lemezen tal\u00e1lhat\u00f3 szektorra. De mi t\u00f6rt\u00e9nik, ha ezt a megab\u00e1jt null\u00e1t nem t\u00f6m\u00f6r\u00edthet\u0151 adatokra, p\u00e9ld\u00e1ul JPEG-re vagy pszeud\u00f3v\u00e9letlenszer\u0171 zajra cser\u00e9lj\u00fck? Hirtelen ennek a megab\u00e1jt adatonak nem egy, hanem 256 szektorra lesz sz\u00fcks\u00e9ge 4 KiB-onk\u00e9nt, ugyanakkor ezen a ter\u00fcleten csak egy szektor van fenntartva a lemezen.<\/p>\n

A ZFS-nek nincs ilyen probl\u00e9m\u00e1ja, mivel a m\u00f3dos\u00edtott bejegyz\u00e9sek mindig felhaszn\u00e1latlan ter\u00fcletre \u00edr\u00f3dnak \u2014 az eredeti blokk csak egy 4 KiB-os szektort foglal el, az \u00faj bejegyz\u00e9s pedig 256-ot, de ez nem probl\u00e9ma \u2014 a f\u00e1jl \"k\u00f6zep\u00e9b\u0151l\" nemr\u00e9g m\u00f3dos\u00edtott szakasz felhaszn\u00e1latlan ter\u00fcletre ker\u00fclne, f\u00fcggetlen\u00fcl att\u00f3l, hogy megv\u00e1ltozott-e a m\u00e9rete vagy sem, teh\u00e1t ez a ZFS sz\u00e1m\u00e1ra teljesen norm\u00e1lis helyzet.<\/p>\n

A ZFS be\u00e9p\u00edtett t\u00f6m\u00f6r\u00edt\u00e9se alap\u00e9rtelmez\u00e9s szerint ki van kapcsolva, \u00e9s a rendszer cser\u00e9lhet\u0151 algoritmusokat k\u00edn\u00e1l \u2014 ezek k\u00f6z\u00fcl jelenleg az LZ4, gzip (1-9), LZJB \u00e9s ZLE \u00e1ll rendelkez\u00e9sre.<\/p>\n

If the file is large enough and requires multiple blocks, then all records with that file will have a size recordsize<\/code>\u00a0\u2014including the last record, the main part of which may turn out to be unused space.<\/a><\/noindex>.<\/p>\n