និទាឃរដូវនេះ យើងបានពិភាក្សាអំពីប្រធានបទណែនាំមួយចំនួនរួចមកហើយ ឧទាហរណ៍៖ របៀបពិនិត្យមើលល្បឿននៃដ្រាយរបស់អ្នក។ и តើអ្វីទៅជា RAID. នៅក្នុងទីពីរនៃពួកគេ យើងថែមទាំងបានសន្យាថានឹងបន្តការសិក្សាអំពីដំណើរការនៃពហុឌីសជាច្រើននៅក្នុង ZFS ។ នេះគឺជាប្រព័ន្ធឯកសារជំនាន់ក្រោយដែលឥឡូវនេះកំពុងត្រូវបានអនុវត្តនៅគ្រប់ទីកន្លែង៖ ពី ផ្លែប៉ោម រហូតដល់ទៅ គូប៊ុនទូ.

ជាការប្រសើរណាស់, ថ្ងៃនេះគឺជាថ្ងៃដ៏ល្អបំផុតដើម្បីស្គាល់ ZFS, អ្នកអានដែលចង់ដឹងចង់ឃើញ។ គ្រាន់តែដឹងថានៅក្នុងគំនិតដ៏រាបទាបរបស់អ្នកអភិវឌ្ឍន៍ OpenZFS លោក Matt Ahrens "វាពិតជាលំបាកណាស់" ។

ប៉ុន្តែមុនពេលដែលយើងឈានដល់លេខ - ហើយពួកគេនឹងខ្ញុំសន្យា - សម្រាប់ជម្រើសទាំងអស់សម្រាប់ការកំណត់រចនាសម្ព័ន្ធ ZFS ចំនួនប្រាំបី យើងត្រូវនិយាយអំពី របៀប ជាទូទៅ ZFS រក្សាទុកទិន្នន័យនៅលើថាស។

Zpool, vdev និងឧបករណ៍

ដ្យាក្រាមអាងពេញលេញនេះរួមមាន vdevs ជំនួយបី ថ្នាក់នីមួយៗ និងបួនសម្រាប់ RAIDz2

ជាធម្មតាវាគ្មានហេតុផលដើម្បីបង្កើតក្រុមនៃប្រភេទ និងទំហំ vdev ដែលមិនផ្គូផ្គងនោះទេ ប៉ុន្តែគ្មានអ្វីរារាំងអ្នកពីការធ្វើដូច្នេះប្រសិនបើអ្នកចង់បាន។

ដើម្បីយល់ច្បាស់អំពីប្រព័ន្ធឯកសារ ZFS អ្នកត្រូវពិនិត្យមើលយ៉ាងដិតដល់នូវរចនាសម្ព័ន្ធជាក់ស្តែងរបស់វា។ ទីមួយ ZFS បង្រួបបង្រួមកម្រិតប្រពៃណីនៃកម្រិតសំឡេង និងការគ្រប់គ្រងប្រព័ន្ធឯកសារ។ ទីពីរ វាប្រើយន្តការចម្លងលើការសរសេរប្រតិបត្តិការ។ លក្ខណៈពិសេសទាំងនេះមានន័យថាប្រព័ន្ធមានរចនាសម្ព័ន្ធខុសពីប្រព័ន្ធឯកសារធម្មតា និងអារេ RAID ។ សំណុំដំបូងនៃប្លុកអគារជាមូលដ្ឋានដែលត្រូវយល់គឺ អាងស្តុកទុក (zpool) ឧបករណ៍និម្មិត (vdev) និងឧបករណ៍ពិត (ឧបករណ៍) ។

zpool

អាងផ្ទុក zpool គឺជារចនាសម្ព័ន្ធ ZFS កំពូលបំផុត។ អាងនីមួយៗមានឧបករណ៍និម្មិតមួយ ឬច្រើន។ នៅក្នុងវេន ពួកវានីមួយៗមានឧបករណ៍ពិតមួយ ឬច្រើន (ឧបករណ៍)។ អាងនិម្មិតគឺជាប្លុកដែលមានដោយខ្លួនឯង។ កុំព្យូទ័រ​រូបវ័ន្ត​មួយ​អាច​មាន​អាង​ពីរ​ឬ​ច្រើន​ដាច់​ដោយ​ឡែក​ពី​គ្នា ប៉ុន្តែ​កុំព្យូទ័រ​នីមួយៗ​គឺ​ឯករាជ្យ​ទាំង​ស្រុង​ពី​ឧបករណ៍​ផ្សេង​ទៀត។ អាងមិនអាចចែករំលែកឧបករណ៍និម្មិតបានទេ។

ភាពច្របូកច្របល់នៃ ZFS គឺនៅកម្រិតឧបករណ៍និម្មិត មិនមែននៅកម្រិតអាងនោះទេ។ មិនមានការលែងត្រូវការតទៅទៀតនៅកម្រិតអាងទេ - ប្រសិនបើដ្រាយវ៍ឌីវឬវីឌីវីពិសេសណាមួយត្រូវបានបាត់បង់នោះអាងទាំងមូលនឹងបាត់បង់ជាមួយវា។

ឧបករណ៍ផ្ទុកទំនើបអាចរស់រានមានជីវិតពីការបាត់បង់ឃ្លាំងសម្ងាត់ ឬកំណត់ហេតុឧបករណ៍និម្មិត - ទោះបីជាពួកគេអាចបាត់បង់ទិន្នន័យកខ្វក់តិចតួចក៏ដោយ ប្រសិនបើពួកគេបាត់បង់កំណត់ហេតុ vdev កំឡុងពេលដាច់ចរន្តអគ្គិសនី ឬគាំងប្រព័ន្ធ។

មានការយល់ខុសជាទូទៅដែល ZFS "ឆ្នូតទិន្នន័យ" ត្រូវបានសរសេរនៅទូទាំងអាងទាំងមូល។ នេះ​គឺ​ជា​ការ​មិន​ពិត​ទេ។ Zpool មិនមែនជា RAID0 គួរឱ្យអស់សំណើចទាល់តែសោះ វាជាការគួរឱ្យអស់សំណើច ជេប៊ី ជាមួយនឹងយន្តការចែកចាយអថេរស្មុគស្មាញ។

សម្រាប់ផ្នែកភាគច្រើន កំណត់ត្រាត្រូវបានចែកចាយក្នុងចំណោមឧបករណ៍និម្មិតដែលមាន យោងទៅតាមទំហំទំនេរដែលមាន ដូច្នេះតាមទ្រឹស្តី ពួកវាទាំងអស់នឹងត្រូវបានបំពេញក្នុងពេលតែមួយ។ នៅក្នុងកំណែក្រោយរបស់ ZFS ការប្រើប្រាស់ vdev បច្ចុប្បន្ន (ការប្រើប្រាស់) ត្រូវបានគេយកមកពិចារណា - ប្រសិនបើឧបករណ៍និម្មិតមួយមានភាពមមាញឹកខ្លាំងជាងឧបករណ៍ផ្សេងទៀត (ឧទាហរណ៍ ដោយសារការផ្ទុកការអាន) វានឹងត្រូវបានរំលងជាបណ្តោះអាសន្នសម្រាប់ការសរសេរ ទោះបីជាមានការឥតគិតថ្លៃខ្ពស់បំផុតក៏ដោយ។ សមាមាត្រលំហ។

យន្តការរាវរកការប្រើប្រាស់ដែលបានបង្កើតឡើងនៅក្នុងវិធីសាស្រ្តបែងចែកការសរសេរ ZFS ទំនើបអាចកាត់បន្ថយភាពយឺតយ៉ាវ និងបង្កើនការបញ្ជូនក្នុងអំឡុងពេលនៃការផ្ទុកខ្ពស់ខុសពីធម្មតា - ប៉ុន្តែវាមិនមែនទេ។ បាយឆា លើការលាយបញ្ចូលគ្នាដោយអចេតនានៃ HDDs យឺត និង SSDs ដែលមានល្បឿនលឿននៅក្នុងអាងមួយ។ អាងមិនស្មើគ្នាបែបនេះនឹងនៅតែដំណើរការក្នុងល្បឿននៃឧបករណ៍យឺតបំផុត ពោលគឺដូចជាវាត្រូវបានផ្សំឡើងទាំងស្រុងពីឧបករណ៍បែបនេះ។

vdev

កន្លែងផ្ទុកនីមួយៗមានឧបករណ៍និម្មិតមួយ ឬច្រើន (ឧបករណ៍និម្មិត vdev)។ នៅក្នុងវេន vdev នីមួយៗមានឧបករណ៍ពិតមួយ ឬច្រើន។ ឧបករណ៍និម្មិតភាគច្រើនត្រូវបានប្រើសម្រាប់ការផ្ទុកទិន្នន័យសាមញ្ញ ប៉ុន្តែមានថ្នាក់ជំនួយ vdev ជាច្រើនរួមមាន CACHE, LOG, និង SPECIAL ។ ប្រភេទ vdev នីមួយៗ​អាច​មាន​ជម្រើស​មួយ​ក្នុង​ចំណោម 1 topologies: ឧបករណ៍តែមួយ (ឧបករណ៍តែមួយ) RAIDz2, RAIDz3, RAIDzXNUMX ឬកញ្ចក់ (កញ្ចក់)។

RAIDz1, RAIDz2 និង RAIDz3 គឺ​ជា​ប្រភេទ​ពិសេស​នៃ​អ្វី​ដែល​មនុស្ស​សម័យ​ដើម​ហៅ​ថា RAID ស្មើ​ទ្វេ (អង្កត់ទ្រូង)។ 1, 2 និង 3 សំដៅលើចំនួនប្លុក parity ត្រូវបានបែងចែកសម្រាប់បន្ទះទិន្នន័យនីមួយៗ។ ជំនួសឱ្យថាសដាច់ដោយឡែកសម្រាប់ភាពស្មើគ្នា ឧបករណ៍និម្មិត RAIDz ចែកចាយភាពស្មើគ្នានេះពាក់កណ្តាលស្មើៗគ្នានៅទូទាំងថាស។ អារេ RAIDz អាចបាត់បង់ថាសច្រើនដូចដែលវាមានប្លុកស្មើគ្នា។ ប្រសិនបើវាបាត់មួយទៀត វានឹងគាំង ហើយយកអាងស្តុកទុកជាមួយវា។

នៅក្នុងឧបករណ៍និម្មិតដែលឆ្លុះបញ្ចាំង (កញ្ចក់ vdev) ប្លុកនីមួយៗត្រូវបានរក្សាទុកនៅលើឧបករណ៍នីមួយៗនៅក្នុង vdev ។ ទោះបីជាកញ្ចក់ពីរគឺជារឿងធម្មតាបំផុតក៏ដោយ ប៉ុន្តែចំនួនឧបករណ៍ដែលបំពានណាមួយអាចនៅក្នុងកញ្ចក់មួយ - បីដងត្រូវបានប្រើជាញឹកញាប់នៅក្នុងការដំឡើងធំសម្រាប់ធ្វើឱ្យប្រសើរឡើងនូវការអនុវត្តការអាន និងការអត់ធ្មត់កំហុស។ កញ្ចក់ vdev អាចរួចផុតពីការបរាជ័យណាមួយ ដរាបណាយ៉ាងហោចណាស់ឧបករណ៍មួយនៅក្នុង vdev បន្តដំណើរការ។

vdevs តែមួយគឺមានគ្រោះថ្នាក់។ ឧបករណ៍និម្មិតបែបនេះនឹងមិនរួចផុតពីការបរាជ័យតែមួយទេ - ហើយប្រសិនបើប្រើជាកន្លែងផ្ទុកឬ vdev ពិសេសនោះការបរាជ័យរបស់វានឹងនាំទៅដល់ការបំផ្លាញអាងទាំងមូល។ សូមប្រយ័ត្ននៅទីនេះ។

CACHE, LOG, និង SPECIAL VAs អាចត្រូវបានបង្កើតដោយប្រើ topologies ខាងលើណាមួយ - ប៉ុន្តែត្រូវចាំថាការបាត់បង់ SPECIAL VA មានន័យថាការបាត់បង់អាង ដូច្នេះហើយ topology លែងត្រូវការតទៅទៀតត្រូវបានណែនាំយ៉ាងខ្លាំង។

ឧបករណ៍

នេះប្រហែលជាពាក្យដែលងាយយល់បំផុតនៅក្នុង ZFS - វាជាឧបករណ៍ចូលប្រើដោយចៃដន្យប្លុក។ សូមចងចាំថាឧបករណ៍និម្មិតត្រូវបានបង្កើតឡើងពីឧបករណ៍នីមួយៗ ខណៈពេលដែលក្រុមមួយត្រូវបានបង្កើតឡើងដោយឧបករណ៍និម្មិត។

ថាស - ទាំងម៉ាញេទិចឬរឹង - គឺជាឧបករណ៍ប្លុកទូទៅបំផុតដែលត្រូវបានប្រើជាប្លុកអាគារនៃ vdev ។ ទោះយ៉ាងណាក៏ដោយ ឧបករណ៍ណាមួយដែលមានអ្នកពិពណ៌នានៅក្នុង /dev នឹងធ្វើ ដូច្នេះអារេ RAID ផ្នែករឹងទាំងមូលអាចត្រូវបានប្រើជាឧបករណ៍ដាច់ដោយឡែក។

ឯកសារឆៅសាមញ្ញគឺជាឧបករណ៍ប្លុកជំនួសដ៏សំខាន់បំផុតមួយដែល vdev អាចត្រូវបានបង្កើតឡើងពី។ អាងសាកល្បងពី ឯកសារតូចៗ គឺជាមធ្យោបាយដ៏ងាយស្រួលមួយដើម្បីពិនិត្យមើលពាក្យបញ្ជាអាង និងមើលថាតើទំហំទំនេរប៉ុន្មានមាននៅក្នុងអាង ឬឧបករណ៍និម្មិតនៃ topology ដែលបានផ្តល់ឱ្យ។

អ្នក​អាច​បង្កើត​បណ្តុំ​សាកល្បង​ពី​ឯកសារ​តូច​ៗ​ក្នុង​ពេល​តែ​ប៉ុន្មាន​វិនាទី​ប៉ុណ្ណោះ - ប៉ុន្តែ​កុំភ្លេច​លុប​អាង​ទាំងមូល និង​សមាសធាតុ​របស់វា​បន្ទាប់​មក

ចូរនិយាយថាអ្នកចង់ដាក់ម៉ាស៊ីនមេនៅលើថាសចំនួនប្រាំបី ហើយគ្រោងនឹងប្រើថាស 10 TB (~9300 GiB) ប៉ុន្តែអ្នកមិនប្រាកដថាមួយណាដែលសាកសមនឹងតម្រូវការរបស់អ្នកបំផុត។ នៅក្នុងឧទាហរណ៍ខាងលើ យើងបង្កើតបណ្តុំសាកល្បងពីឯកសារតូចៗក្នុងរយៈពេលប៉ុន្មានវិនាទី ហើយឥឡូវនេះយើងដឹងថា RAIDz2 vdev នៃថាស 10 TB ចំនួនប្រាំបីផ្តល់នូវសមត្ថភាពប្រើប្រាស់បាន 50 TiB។

ឧបករណ៍ពិសេសមួយទៀតគឺ SPARE (ទំនេរ)។ ឧបករណ៍ប្តូរក្តៅ មិនដូចឧបករណ៍ធម្មតាទេ ជាកម្មសិទ្ធិរបស់អាងទាំងមូល និងមិនមែនសម្រាប់ឧបករណ៍និម្មិតតែមួយទេ។ ប្រសិនបើ vdev នៅក្នុងអាងបរាជ័យ ហើយឧបករណ៍ទំនេរមួយត្រូវបានភ្ជាប់ទៅអាង ហើយអាចប្រើបាន នោះវានឹងចូលរួមជាមួយ vdev ដែលរងផលប៉ះពាល់ដោយស្វ័យប្រវត្តិ។

បន្ទាប់ពីភ្ជាប់ទៅ vdev ដែលរងផលប៉ះពាល់ ឧបករណ៍ទំនេរចាប់ផ្តើមទទួលច្បាប់ចម្លង ឬបង្កើតឡើងវិញនូវទិន្នន័យដែលគួរតែមាននៅលើឧបករណ៍ដែលបាត់។ នៅក្នុង RAID ប្រពៃណីនេះត្រូវបានគេហៅថាការកសាងឡើងវិញខណៈពេលដែលនៅក្នុង ZFS វាត្រូវបានគេហៅថា resilvering ។

វាជាការសំខាន់ក្នុងការកត់សម្គាល់ថាឧបករណ៍ទំនេរមិនជំនួសឧបករណ៍ដែលបរាជ័យជាអចិន្ត្រៃយ៍ទេ។ នេះគ្រាន់តែជាការជំនួសបណ្តោះអាសន្នដើម្បីកាត់បន្ថយពេលវេលាដែល vdev ត្រូវបានបន្ទាបបន្ថោក។ បន្ទាប់ពីអ្នកគ្រប់គ្រងជំនួស vdev ដែលបរាជ័យ ការលែងត្រូវការតទៅទៀតត្រូវបានស្ដារទៅឧបករណ៍អចិន្រ្តៃយ៍នោះ ហើយ SPARE ត្រូវបានផ្តាច់ចេញពី vdev ហើយត្រឡប់ទៅធ្វើការវិញជាកន្លែងទំនេរសម្រាប់អាងទាំងមូល។

សំណុំទិន្នន័យ ប្លុក និងផ្នែក

សំណុំបន្ទាប់នៃប្លុកអគារដើម្បីយល់នៅលើដំណើរ ZFS របស់យើងគឺតិចជាងអំពីផ្នែករឹង និងច្រើនទៀតអំពីរបៀបដែលទិន្នន័យខ្លួនឯងត្រូវបានរៀបចំ និងរក្សាទុក។ យើងកំពុងរំលងកម្រិតមួយចំនួននៅទីនេះ - ដូចជា metaslab - ដើម្បីកុំឱ្យពង្រាយព័ត៌មានលម្អិតខណៈពេលដែលរក្សាការយល់ដឹងអំពីរចនាសម្ព័ន្ធទាំងមូល។

សំណុំទិន្នន័យ (សំណុំទិន្នន័យ)

នៅពេលយើងបង្កើតសំណុំទិន្នន័យដំបូង វាបង្ហាញទំហំអាងដែលមានទាំងអស់។ បន្ទាប់មកយើងកំណត់កូតា - ហើយផ្លាស់ប្តូរចំណុចម៉ោន។ វេទមន្ត!

Zvol គឺសម្រាប់ផ្នែកភាគច្រើនគ្រាន់តែជាសំណុំទិន្នន័យដែលដកចេញពីស្រទាប់ប្រព័ន្ធឯកសាររបស់វា ដែលយើងកំពុងជំនួសនៅទីនេះជាមួយនឹងប្រព័ន្ធឯកសារ ext4 ធម្មតា។

សំណុំទិន្នន័យ ZFS គឺប្រហាក់ប្រហែលនឹងប្រព័ន្ធឯកសារដែលបានម៉ោនស្តង់ដារ។ ដូចប្រព័ន្ធឯកសារធម្មតាដែរ នៅ glance ដំបូងវាមើលទៅដូចជា "គ្រាន់តែថតមួយផ្សេងទៀត" ។ ប៉ុន្តែដូចជាប្រព័ន្ធឯកសារដែលអាចម៉ោនបានធម្មតា សំណុំទិន្នន័យ ZFS នីមួយៗមានសំណុំលក្ខណៈសម្បត្តិមូលដ្ឋានផ្ទាល់ខ្លួន។

ជាដំបូង សំណុំទិន្នន័យអាចមានកូតាដែលបានកំណត់។ ប្រសិនបើកំណត់ zfs set quota=100G poolname/datasetnameបន្ទាប់មក អ្នកនឹងមិនអាចសរសេរទៅថតដែលបានម៉ោនបានទេ។ /poolname/datasetname ច្រើនជាង 100 GiB ។

សម្គាល់វត្តមាន - និងអវត្តមាន - នៃសញ្ញានៅដើមបន្ទាត់នីមួយៗ? សំណុំទិន្នន័យនីមួយៗមានកន្លែងផ្ទាល់ខ្លួនទាំងនៅក្នុងឋានានុក្រម ZFS និងឋានានុក្រមម៉ោនប្រព័ន្ធ។ មិនមានសញ្ញាកាត់នាំមុខនៅក្នុងឋានានុក្រម ZFS ទេ - អ្នកចាប់ផ្តើមដោយឈ្មោះអាងហើយបន្ទាប់មកផ្លូវពីសំណុំទិន្នន័យមួយទៅសំណុំទិន្នន័យបន្ទាប់។ ឧទាហរណ៍, pool/parent/child សម្រាប់សំណុំទិន្នន័យដែលមានឈ្មោះ child នៅក្រោមសំណុំទិន្នន័យមេ parent នៅក្នុងអាងមួយដែលមានឈ្មោះច្នៃប្រឌិត pool.

តាមលំនាំដើម ចំណុចម៉ោនរបស់សំណុំទិន្នន័យនឹងស្មើនឹងឈ្មោះរបស់វានៅក្នុងឋានានុក្រម ZFS ដោយមានសញ្ញាចុចនាំមុខ - អាងដែលមានឈ្មោះ pool បានម៉ោនជា /pool, សំណុំទិន្នន័យ parent បាន​ដំឡើង​នៅ​ក្នុង /pool/parentនិងសំណុំទិន្នន័យកុមារ child បាន​ដំឡើង​នៅ​ក្នុង /pool/parent/child. ទោះយ៉ាងណាក៏ដោយ ចំណុចភ្ជាប់ប្រព័ន្ធរបស់សំណុំទិន្នន័យអាចត្រូវបានផ្លាស់ប្តូរ។

ប្រសិនបើយើងបញ្ជាក់ zfs set mountpoint=/lol pool/parent/childបន្ទាប់មកសំណុំទិន្នន័យ pool/parent/child បានដំឡើងនៅលើប្រព័ន្ធដូច /lol.

បន្ថែមពីលើសំណុំទិន្នន័យ យើងគួរនិយាយអំពីបរិមាណ (zvols) ។ កម្រិតសំឡេងគឺប្រហាក់ប្រហែលនឹងសំណុំទិន្នន័យ លើកលែងតែវាមិនមានប្រព័ន្ធឯកសារទេ - វាគ្រាន់តែជាឧបករណ៍ទប់ស្កាត់ប៉ុណ្ណោះ។ ឧទាហរណ៍អ្នកអាចបង្កើត zvol ជាមួយឈ្មោះ mypool/myzvolបន្ទាប់មកធ្វើទ្រង់ទ្រាយវាជាមួយប្រព័ន្ធឯកសារ ext4 ហើយបន្ទាប់មកម៉ោនប្រព័ន្ធឯកសារនោះ - ឥឡូវនេះអ្នកមានប្រព័ន្ធឯកសារ ext4 ប៉ុន្តែជាមួយនឹងមុខងារសុវត្ថិភាពទាំងអស់របស់ ZFS! វាអាចហាក់ដូចជាឆ្កួតៗនៅលើម៉ាស៊ីនតែមួយ ប៉ុន្តែវាមានន័យច្រើនក្នុងនាមជាកម្មវិធីខាងក្រោយនៅពេលនាំចេញឧបករណ៍ iSCSI ។

ប្លុក

ឯកសារត្រូវបានតំណាងដោយប្លុកមួយ ឬច្រើន។ ប្លុកនីមួយៗត្រូវបានរក្សាទុកនៅលើឧបករណ៍និម្មិតមួយ។ ទំហំប្លុកជាធម្មតាស្មើនឹងប៉ារ៉ាម៉ែត្រ ទំហំកំណត់ត្រាប៉ុន្តែអាចត្រូវបានកាត់បន្ថយទៅ 2^ ការផ្លាស់ប្តូរប្រសិនបើវាមានទិន្នន័យមេតា ឬឯកសារតូចមួយ។

យើងពិតជា ពិតជា កុំនិយាយលេងអំពីការពិន័យលើការអនុវត្តដ៏ធំ ប្រសិនបើអ្នកកំណត់ការផ្លាស់ប្តូរតូចពេក

នៅក្នុងក្រុម ZFS ទិន្នន័យទាំងអស់ រួមទាំងទិន្នន័យមេតាត្រូវបានរក្សាទុកក្នុងប្លុក។ ទំហំប្លុកអតិបរមាសម្រាប់សំណុំទិន្នន័យនីមួយៗត្រូវបានកំណត់នៅក្នុងលក្ខណសម្បត្តិ recordsize (ទំហំកំណត់ត្រា) ។ ទំហំកំណត់ត្រាអាចត្រូវបានផ្លាស់ប្តូរ ប៉ុន្តែវានឹងមិនផ្លាស់ប្តូរទំហំ ឬទីតាំងនៃប្លុកណាមួយដែលត្រូវបានសរសេររួចហើយទៅកាន់សំណុំទិន្នន័យនោះទេ - វាប៉ះពាល់តែប្លុកថ្មី ដូចដែលពួកគេត្រូវបានសរសេរ។

លើកលែងតែមានការបញ្ជាក់ផ្សេងពីនេះ ទំហំកំណត់ត្រាលំនាំដើមបច្ចុប្បន្នគឺ 128 KiB។ វាជាប្រភេទនៃការដោះដូរដ៏លំបាកមួយ ដែលការសម្តែងមិនល្អឥតខ្ចោះ ប៉ុន្តែវាមិនគួរឱ្យភ័យខ្លាចនៅក្នុងករណីភាគច្រើនផងដែរ។ Recordsize អាចកំណត់ទៅតម្លៃណាមួយពី 4K ទៅ 1M (ជាមួយការកំណត់កម្រិតខ្ពស់ recordsize អ្នកអាចដំឡើងកាន់តែច្រើន ប៉ុន្តែនេះកម្រជាគំនិតល្អ)។

ប្លុកណាមួយសំដៅលើទិន្នន័យនៃឯកសារតែមួយ អ្នកមិនអាចច្របាច់ឯកសារពីរផ្សេងគ្នាទៅក្នុងប្លុកតែមួយបានទេ។ ឯកសារនីមួយៗមានប្លុកមួយ ឬច្រើន អាស្រ័យលើទំហំរបស់វា។ ប្រសិនបើទំហំឯកសារតូចជាងទំហំកំណត់ត្រា វានឹងត្រូវបានរក្សាទុកក្នុងប្លុកតូចជាងឧទាហរណ៍ ប្លុកដែលមានឯកសារ 2KiB នឹងកាន់កាប់តែផ្នែក 4KiB មួយនៅលើថាសប៉ុណ្ណោះ។

ប្រសិនបើឯកសារមានទំហំធំល្មម ហើយត្រូវការប្លុកជាច្រើន នោះកំណត់ត្រាទាំងអស់ដែលមានឯកសារនេះនឹងមានទំហំ recordsize - រួមទាំងធាតុចុងក្រោយដែលជាផ្នែកសំខាន់ដែលអាចមាន កន្លែងដែលមិនប្រើ.

zvols មិនមានទ្រព្យសម្បត្តិទេ។ recordsize - ជំនួសមកវិញ ពួកគេមានទ្រព្យសម្បត្តិសមមូល volblocksize.

វិស័យ

ប្លុកអគារមូលដ្ឋានចុងក្រោយបំផុតគឺវិស័យ។ វាជាឯកតារូបវន្តតូចបំផុតដែលអាចសរសេរទៅ ឬអានពីឧបករណ៍មូលដ្ឋាន។ អស់ជាច្រើនទសវត្សរ៍ ថាសភាគច្រើនបានប្រើផ្នែក 512 បៃ។ ថ្មីៗនេះ ថាសភាគច្រើនត្រូវបានកំណត់រចនាសម្ព័ន្ធសម្រាប់ផ្នែក 4 KiB ហើយមួយចំនួន - ជាពិសេស SSDs - មានផ្នែក 8 KiB ឬច្រើនជាងនេះ។

ប្រព័ន្ធ ZFS មានទ្រព្យសម្បត្តិដែលអនុញ្ញាតឱ្យអ្នកកំណត់ទំហំផ្នែកដោយដៃ។ ទ្រព្យសម្បត្តិនេះ។ ashift. មានការយល់ច្រលំបន្តិច ការផ្លាស់ប្តូរគឺជាអំណាចនៃពីរ។ ឧទាហរណ៍, ashift=9 មានន័យថាទំហំផ្នែកនៃ 2^9 ឬ 512 បៃ។

ZFS សាកសួរប្រព័ន្ធប្រតិបត្តិការសម្រាប់ព័ត៌មានលម្អិតអំពីឧបករណ៍ប្លុកនីមួយៗ នៅពេលដែលវាត្រូវបានបន្ថែមទៅ vdev ថ្មី ហើយតាមទ្រឹស្តីនឹងដំឡើង ashift ដោយស្វ័យប្រវត្តិយ៉ាងត្រឹមត្រូវដោយផ្អែកលើព័ត៌មាននោះ។ ជាអកុសល ដ្រាយជាច្រើននិយាយអំពីទំហំផ្នែករបស់ពួកគេ ដើម្បីរក្សាភាពឆបគ្នាជាមួយ Windows XP (ដែលមិនអាចយល់បាននូវ drives ជាមួយនឹងទំហំផ្នែកផ្សេងទៀត)។

នេះមានន័យថាអ្នកគ្រប់គ្រង ZFS ត្រូវបានណែនាំយ៉ាងខ្លាំងឱ្យដឹងពីទំហំជាក់ស្តែងនៃឧបករណ៍របស់ពួកគេ និងកំណត់ដោយដៃ ashift. ប្រសិនបើ ashift ត្រូវបានកំណត់ទាបពេក នោះចំនួននៃប្រតិបត្តិការអាន/សរសេរកើនឡើងតាមតារាសាស្ត្រ។ ដូច្នេះការសរសេរ 512-byte "sectors" ទៅក្នុងវិស័យ 4 KiB ពិតប្រាកដមានន័យថាត្រូវសរសេរ "sector" ដំបូង បន្ទាប់មកអានផ្នែក 4 KiB កែប្រែវាជាមួយ "sector" 512-byte ទីពីរសរសេរវាត្រឡប់ទៅថ្មី វិស័យ 4 KiB ហើយដូច្នេះនៅលើ។ សម្រាប់ធាតុនីមួយៗ។

នៅក្នុងពិភពពិត ការពិន័យបែបនេះប៉ះពាល់ដល់ Samsung EVO SSDs ដែល ashift=13ប៉ុន្តែ SSDs ទាំងនេះនិយាយអំពីទំហំផ្នែករបស់ពួកគេ ហើយដូច្នេះលំនាំដើមត្រូវបានកំណត់ទៅ ashift=9. ប្រសិនបើអ្នកគ្រប់គ្រងប្រព័ន្ធដែលមានបទពិសោធន៍មិនផ្លាស់ប្តូរការកំណត់នេះទេ SSD នេះដំណើរការ យឺតជាង HDD ម៉ាញេទិកធម្មតា។

សម្រាប់ការប្រៀបធៀបសម្រាប់ទំហំធំពេក ashift ជាក់ស្តែងមិនមានការពិន័យទេ។ មិនមានការពិន័យលើការអនុវត្តជាក់ស្តែងទេ ហើយការកើនឡើងនៃទំហំដែលមិនប្រើគឺគ្មានដែនកំណត់ (ឬសូន្យជាមួយនឹងការបង្ហាប់ដែលបានបើក)។ ដូច្នេះហើយ យើងសូមណែនាំយ៉ាងមុតមាំថា សូម្បីតែដ្រាយវ៍ទាំងនោះដែលប្រើផ្នែក 512-byte ដំឡើង ashift=12 ឬសូម្បី ashift=13ដើម្បីប្រឈមមុខនឹងអនាគតដោយទំនុកចិត្ត។

ទ្រព្យសម្បត្តិ ashift ត្រូវបានកំណត់សម្រាប់ឧបករណ៍និម្មិត vdev នីមួយៗ និង មិនមែនសម្រាប់អាងទេ។ដូចដែលមនុស្សជាច្រើនគិតខុស - ហើយមិនផ្លាស់ប្តូរបន្ទាប់ពីដំឡើង។ ប្រសិនបើអ្នកបុកដោយចៃដន្យ ashift នៅពេលអ្នកបន្ថែម vdev ថ្មីទៅអាងទឹក អ្នកបានបំពុលអាងទឹកនោះដោយមិនអាចទទួលយកបានជាមួយនឹងឧបករណ៍ដំណើរការទាប ហើយជាធម្មតាមិនមានជម្រើសផ្សេងទៀតក្រៅពីបំផ្លាញអាង ហើយចាប់ផ្តើមឡើងវិញ។ សូម្បីតែការដក vdev ចេញក៏នឹងមិនជួយសង្គ្រោះអ្នកពីការកំណត់រចនាសម្ព័ន្ធដែលខូចដែរ។ ashift!

យន្តការចម្លងលើការសរសេរ

ប្រសិនបើប្រព័ន្ធឯកសារធម្មតាត្រូវការសរសេរជាន់លើទិន្នន័យ វាផ្លាស់ប្តូរប្លុកនីមួយៗដែលវាមាន

ប្រព័ន្ធឯកសារចម្លងលើការសរសេរសរសេរកំណែប្លុកថ្មី ហើយបន្ទាប់មកដោះសោកំណែចាស់

នៅក្នុងអរូបី ប្រសិនបើយើងព្រងើយកន្តើយនឹងទីតាំងជាក់ស្តែងនៃប្លុក នោះ "ទិន្នន័យផ្កាយដុះកន្ទុយ" របស់យើងត្រូវបានធ្វើឱ្យសាមញ្ញទៅជា "ដង្កូវទិន្នន័យ" ដែលផ្លាស់ទីពីឆ្វេងទៅស្តាំឆ្លងកាត់ផែនទីនៃកន្លែងទំនេរ។

ឥឡូវនេះ យើងអាចទទួលបានគំនិតដ៏ល្អមួយអំពីរបៀបដែលការចម្លងលើការសរសេររូបថតដំណើរការ - ប្លុកនីមួយៗអាចជារបស់រូបថតច្រើន ហើយនឹងបន្តរហូតដល់រូបថតដែលពាក់ព័ន្ធទាំងអស់ត្រូវបានបំផ្លាញ

យន្តការចម្លងលើការសរសេរ (CoW) គឺជាមូលដ្ឋានគ្រឹះនៃអ្វីដែលធ្វើឱ្យ ZFS ជាប្រព័ន្ធដ៏អស្ចារ្យមួយ។ គោលគំនិតជាមូលដ្ឋានគឺសាមញ្ញ - ប្រសិនបើអ្នកសួរប្រព័ន្ធឯកសារបែបប្រពៃណីដើម្បីផ្លាស់ប្តូរឯកសារ វានឹងធ្វើដូចអ្វីដែលអ្នកបានសួរ។ ប្រសិនបើអ្នកស្នើឱ្យប្រព័ន្ធឯកសារចម្លងលើការសរសេរឱ្យធ្វើដូចគ្នា វានឹងនិយាយថា "យល់ព្រម" ប៉ុន្តែកុហកអ្នក។

ផ្ទុយទៅវិញ ប្រព័ន្ធឯកសារចម្លងលើការសរសេរសរសេរកំណែថ្មីនៃប្លុកដែលបានកែប្រែ ហើយបន្ទាប់មកធ្វើបច្ចុប្បន្នភាពទិន្នន័យមេតារបស់ឯកសារដើម្បីផ្ដាច់ប្លុកចាស់ និងភ្ជាប់ប្លុកថ្មីដែលអ្នកទើបតែសរសេរទៅវា។

ការផ្ដាច់ប្លុកចាស់ និងភ្ជាប់ប្លុកថ្មីត្រូវបានធ្វើរួចក្នុងប្រតិបត្តិការមួយ ដូច្នេះវាមិនអាចរំខានបានទេ - ប្រសិនបើអ្នកបិទដំណើរការបន្ទាប់ពីវាកើតឡើង អ្នកមានកំណែថ្មីនៃឯកសារ ហើយប្រសិនបើអ្នកបិទដំណើរការមុន អ្នកមានកំណែចាស់។ . ក្នុងករណីណាក៏ដោយវានឹងមិនមានជម្លោះនៅក្នុងប្រព័ន្ធឯកសារទេ។

ការចម្លងលើការសរសេរនៅក្នុង ZFS កើតឡើងមិនត្រឹមតែនៅកម្រិតប្រព័ន្ធឯកសារប៉ុណ្ណោះទេ ប៉ុន្តែក៏នៅកម្រិតគ្រប់គ្រងថាសផងដែរ។ នេះមានន័យថា ZFS មិនត្រូវបានប៉ះពាល់ដោយចន្លោះពណ៌ស (រន្ធនៅក្នុង RAID) - បាតុភូតនៅពេលដែលបន្ទះមានពេលវេលាដើម្បីកត់ត្រាតែផ្នែកខ្លះមុនពេលប្រព័ន្ធគាំង ជាមួយនឹងការខូចខាតអារេបន្ទាប់ពីការចាប់ផ្ដើមឡើងវិញ។ នៅទីនេះឆ្នូតត្រូវបានសរសេរជាអាតូម, vdev តែងតែបន្តបន្ទាប់គ្នា, និង Bob គឺជាពូរបស់អ្នក។.

ZIL៖ កំណត់ហេតុចេតនា ZFS

ប្រព័ន្ធ ZFS ចាត់ចែងការសរសេរដែលធ្វើសមកាលកម្មក្នុងវិធីពិសេសមួយ - វាទុកជាបណ្ដោះអាសន្ន ប៉ុន្តែភ្លាមៗរក្សាទុកពួកវាក្នុង ZIL មុនពេលសរសេរពួកវាជាអចិន្ត្រៃយ៍នៅពេលក្រោយ រួមជាមួយនឹងការសរសេរអសមកាល។

ជាធម្មតា ទិន្នន័យដែលសរសេរទៅ ZIL មិនត្រូវបានអានម្តងទៀតទេ។ ប៉ុន្តែវាអាចទៅរួចបន្ទាប់ពីប្រព័ន្ធគាំង

SLOG ឬឧបករណ៍ LOG ទីពីរគឺគ្រាន់តែជាឧបករណ៍ពិសេស - និងលឿនបំផុត - vdev ដែល ZIL អាចត្រូវបានរក្សាទុកដាច់ដោយឡែកពីកន្លែងផ្ទុកសំខាន់

បន្ទាប់ពីគាំង ទិន្នន័យកខ្វក់ទាំងអស់នៅក្នុង ZIL ត្រូវបានចាក់ឡើងវិញ - ក្នុងករណីនេះ ZIL ស្ថិតនៅលើ SLOG ដូច្នេះវាត្រូវបានចាក់ឡើងវិញពីទីនោះ

មានពីរប្រភេទសំខាន់ៗនៃប្រតិបត្តិការសរសេរ - សមកាលកម្ម (សមកាលកម្ម) និងអសមកាល (អសមកាល) ។ សម្រាប់បន្ទុកការងារភាគច្រើន ការសរសេរភាគច្រើនគឺអសមកាល - ប្រព័ន្ធឯកសារអនុញ្ញាតឱ្យពួកវាត្រូវបានប្រមូលផ្តុំ និងចេញជាបាច់ កាត់បន្ថយការបែងចែក និងការកើនឡើងយ៉ាងខ្លាំង។

ការថតដែលធ្វើសមកាលកម្មគឺជាបញ្ហាខុសគ្នាទាំងស្រុង។ នៅពេលកម្មវិធីស្នើសុំការសរសេរសមកាលកម្ម វាប្រាប់ប្រព័ន្ធឯកសារ៖ "អ្នកត្រូវបញ្ចូលវាទៅអង្គចងចាំដែលមិនងាយនឹងបង្កជាហេតុ ឥឡូវ​នេះរហូត​មក​ដល់​ពេល​នេះ ខ្ញុំ​មិន​អាច​ធ្វើ​អ្វី​បាន​ទៀត​ទេ»។ ដូច្នេះ ការសរសេរសមកាលកម្មគួរតែត្រូវបានប្តេជ្ញាចិត្តទៅកាន់ថាសភ្លាមៗ ហើយប្រសិនបើវាបង្កើនការបំបែក ឬកាត់បន្ថយការបញ្ជូន នោះក៏ដូច្នោះដែរ។

ZFS គ្រប់គ្រងការសរសេរសមកាលកម្មខុសពីប្រព័ន្ធឯកសារធម្មតា - ជំនួសឱ្យការផ្ទេរពួកវាភ្លាមៗទៅកន្លែងផ្ទុកធម្មតា ZFS ប្រគល់វាទៅកន្លែងផ្ទុកពិសេសដែលហៅថា ZFS Intent Log ឬ ZIL ។ ល្បិចគឺថាកំណត់ត្រាទាំងនេះ ផងដែរ នៅតែស្ថិតក្នុងសតិ ដោយត្រូវបានប្រមូលផ្តុំរួមជាមួយនឹងសំណើសរសេរអសមកាលធម្មតា ដែលត្រូវបញ្ចូនទៅកន្លែងផ្ទុកនៅពេលក្រោយជា TXGs ធម្មតាឥតខ្ចោះ (ក្រុមប្រតិបត្តិការ)។

នៅក្នុងប្រតិបត្តិការធម្មតា ZIL ត្រូវបានសរសេរទៅ និងមិនអានម្តងទៀត។ នៅពេលដែលមួយសន្ទុះក្រោយមក កំណត់ត្រាពី ZIL ត្រូវបានប្តេជ្ញាចិត្តចំពោះការផ្ទុកសំខាន់នៅក្នុង TXGs ធម្មតាពី RAM ពួកគេត្រូវបានផ្តាច់ចេញពី ZIL ។ ពេលវេលាតែមួយគត់ដែលត្រូវបានអានពី ZIL គឺនៅពេលដែលអាងត្រូវបាននាំចូល។

ប្រសិនបើ ZFS បរាជ័យ - ប្រព័ន្ធប្រតិបត្តិការគាំង ឬការដាច់ចរន្តអគ្គិសនី - ខណៈពេលដែលមានទិន្នន័យនៅក្នុង ZIL ទិន្នន័យនោះនឹងត្រូវបានអានកំឡុងពេលនាំចូលអាងបន្ទាប់ (ឧទាហរណ៍ នៅពេលចាប់ផ្តើមប្រព័ន្ធសង្គ្រោះបន្ទាន់ឡើងវិញ)។ អ្វីក៏ដោយនៅក្នុង ZIL នឹងត្រូវបានអាន ដោយដាក់ជាក្រុមទៅជា TXGs ដែលប្តេជ្ញាចិត្តចំពោះការផ្ទុកសំខាន់ ហើយបន្ទាប់មកត្រូវបានផ្ដាច់ចេញពី ZIL ក្នុងអំឡុងពេលដំណើរការនាំចូល។

ថ្នាក់ជំនួយ vdev មួយត្រូវបានគេហៅថា LOG ឬ SLOG ដែលជាឧបករណ៍បន្ទាប់បន្សំរបស់ LOG ។ វាមានគោលបំណងមួយ - ដើម្បីផ្តល់អាងដាច់ដោយឡែកមួយ និងលឿនជាង vdev ដែលធន់នឹងការសរសេរច្រើន ដើម្បីរក្សាទុក ZIL ជំនួសឱ្យការរក្សាទុក ZIL នៅលើហាង vdev សំខាន់។ ZIL ខ្លួនវាមានឥរិយាបទដូចគ្នាមិនថាវាត្រូវបានរក្សាទុកនៅកន្លែងណាក៏ដោយ ប៉ុន្តែប្រសិនបើ LOG vdev មានដំណើរការសរសេរខ្ពស់ខ្លាំង ការសរសេរសមកាលកម្មនឹងលឿនជាងមុន។

ការបន្ថែម vdev ជាមួយ LOG ទៅអាងមិនដំណើរការទេ។ មិនអាចទេ។ ធ្វើឱ្យប្រសើរឡើងនូវការសរសេរអសមកាល - ទោះបីជាអ្នកបង្ខំឱ្យសរសេរទាំងអស់ទៅ ZIL ជាមួយ zfs set sync=alwaysពួកគេនឹងនៅតែត្រូវបានភ្ជាប់ទៅកន្លែងផ្ទុកសំខាន់នៅក្នុង TXG តាមរបៀបដូចគ្នា និងក្នុងល្បឿនដូចគ្នាដោយគ្មានកំណត់ហេតុ។ ការកែលម្អការអនុវត្តផ្ទាល់តែមួយគត់គឺភាពយឺតយ៉ាវនៃការសរសេរសមកាលកម្ម (ព្រោះកំណត់ហេតុកាន់តែលឿនបង្កើនល្បឿនប្រតិបត្តិការ) ។ sync).

ទោះយ៉ាងណាក៏ដោយ នៅក្នុងបរិយាកាសដែលទាមទារការសរសេរសមកាលកម្មច្រើនរួចហើយ vdev LOG អាចបង្កើនល្បឿនការសរសេរអសមកាល និងការអានដែលមិនមានឃ្លាំងសម្ងាត់ដោយប្រយោល។ ការដាក់បញ្ចូលធាតុ ZIL ទៅកាន់ vdev LOG ដាច់ដោយឡែកមានន័យថាមានការឈ្លោះគ្នាតិចសម្រាប់ IOPS លើការផ្ទុកបឋម ដែលធ្វើអោយប្រសើរឡើងនូវដំណើរការនៃការអាន និងសរសេរទាំងអស់ក្នុងកម្រិតមួយចំនួន។

រូបថត

យន្តការចម្លងលើការសរសេរក៏ជាមូលដ្ឋានគ្រឹះចាំបាច់សម្រាប់ការថតរូបអាតូមិច ZFS និងការចម្លងអសមកាលបន្ថែម។ ប្រព័ន្ធឯកសារសកម្មមានមែកធាងទ្រនិចដែលសម្គាល់កំណត់ត្រាទាំងអស់ជាមួយនឹងទិន្នន័យបច្ចុប្បន្ន - នៅពេលអ្នកថតរូប អ្នកគ្រាន់តែចម្លងមែកធាងទ្រនិចនេះ។

នៅពេលដែលកំណត់ត្រាត្រូវបានសរសេរជាន់លើនៅលើប្រព័ន្ធឯកសារសកម្ម ZFS ដំបូងសរសេរកំណែប្លុកថ្មីទៅកន្លែងទំនេរដែលមិនប្រើ។ បន្ទាប់មកវាផ្ដាច់កំណែចាស់នៃប្លុកពីប្រព័ន្ធឯកសារបច្ចុប្បន្ន។ ប៉ុន្តែប្រសិនបើរូបថតមួយចំនួនសំដៅទៅលើប្លុកចាស់ វានៅតែមិនផ្លាស់ប្តូរ។ ប្លុក​ចាស់​នឹង​មិន​ត្រូវ​បាន​ស្ដារ​ឡើង​វិញ​ជា​ទំហំ​ទំនេរ​ទេ រហូត​ទាល់​តែ​រូបថត​ទាំងអស់​ដែល​យោង​ប្លុក​នេះ​ត្រូវ​បាន​បំផ្លាញ!

ការចម្លង

បណ្ណាល័យ Steam របស់ខ្ញុំក្នុងឆ្នាំ 2015 គឺ 158 GiB និងរួមបញ្ចូលឯកសារចំនួន 126 ។ នេះគឺជិតនឹងស្ថានភាពល្អបំផុតសម្រាប់ rsync - ការចម្លង ZFS លើបណ្តាញគឺ "លឿនជាង" 927% ប៉ុណ្ណោះ។

នៅលើបណ្តាញតែមួយ ការចម្លងឯកសាររូបភាពម៉ាស៊ីននិម្មិត Windows 40 ទំហំ 7GB តែមួយគឺជារឿងខុសគ្នាទាំងស្រុង។ ការចម្លង ZFS គឺលឿនជាង rsync 289 ដង - ឬ "តែ" 161 ដងលឿនជាង ប្រសិនបើអ្នកមានជំនាញគ្រប់គ្រាន់ក្នុងការហៅ rsync ជាមួយ --inplace ។

នៅពេលដែលរូបភាព VM ត្រូវបានធ្វើមាត្រដ្ឋាន rsync ចេញមាត្រដ្ឋានជាមួយវា។ 1,9 TiB មិនធំសម្រាប់រូបភាព VM ទំនើបទេ ប៉ុន្តែវាធំល្មមដែលការចម្លង ZFS លឿនជាង rsync ដល់ទៅ 1148 ដង សូម្បីតែជាមួយអាគុយម៉ង់ --inplace របស់ rsync

នៅពេលដែលអ្នកយល់ពីរបៀបដែលរូបថតដំណើរការ វាគួរតែងាយស្រួលក្នុងការយល់ខ្លឹមសារនៃការចម្លង។ ដោយសាររូបថតគ្រាន់តែជាដើមនៃចង្អុលទៅថត វាធ្វើតាមថាបើយើងធ្វើ zfs send រូបថតបន្ទាប់មក យើងផ្ញើទាំងមែកធាងនេះ និងកំណត់ត្រាទាំងអស់ដែលពាក់ព័ន្ធជាមួយវា។ នៅពេលដែលយើងផ្ញើនេះ។ zfs send в zfs receive នៅលើគោលដៅ វាសរសេរទាំងខ្លឹមសារពិតនៃប្លុក និងមែកធាងនៃទ្រនិចដែលសំដៅលើប្លុកទៅកាន់សំណុំទិន្នន័យគោលដៅ។

អ្វីៗកាន់តែគួរឱ្យចាប់អារម្មណ៍នៅលើកទីពីរ zfs send. ឥឡូវនេះយើងមានប្រព័ន្ធពីរដែលនីមួយៗមាន poolname/datasetname@1ហើយអ្នកថតរូបថ្មី។ poolname/datasetname@2. ដូច្នេះនៅក្នុងអាងដើមអ្នកមាន datasetname@1 и datasetname@2ហើយនៅក្នុងក្រុមគោលដៅរហូតមកដល់ពេលនេះមានតែរូបថតដំបូងប៉ុណ្ណោះ។ datasetname@1.

ដោយសារយើងមានរូបថតធម្មតារវាងប្រភព និងគោលដៅ datasetname@1, យើង​អាច​ធ្វើ​វា​បាន បន្ថែម zfs send លើវា។ នៅពេលយើងនិយាយទៅកាន់ប្រព័ន្ធ zfs send -i poolname/datasetname@1 poolname/datasetname@2វាប្រៀបធៀបដើមឈើទ្រនិចពីរ។ ចំណុចណាមួយដែលមានតែនៅក្នុង @2ជាក់ស្តែងសំដៅទៅលើប្លុកថ្មី - ដូច្នេះយើងត្រូវការមាតិកានៃប្លុកទាំងនេះ។

នៅលើប្រព័ន្ធពីចម្ងាយ ដំណើរការបន្ថែម send គ្រាន់តែសាមញ្ញ។ ដំបូងយើងសរសេរធាតុថ្មីទាំងអស់ដែលរួមបញ្ចូលក្នុងស្ទ្រីម sendហើយបន្ទាប់មកបន្ថែមចំណុចចង្អុលទៅប្លុកទាំងនោះ។ Voila យើងមាន @2 នៅក្នុងប្រព័ន្ធថ្មី!

ការចម្លងបន្ថែមដោយអសមកាល ZFS គឺជាការកែលម្អដ៏ធំមួយលើវិធីសាស្ត្រដែលមិនមានមូលដ្ឋានលើរូបថតមុនៗ ដូចជា rsync ជាដើម។ ក្នុងករណីទាំងពីរ មានតែទិន្នន័យដែលបានផ្លាស់ប្តូរប៉ុណ្ណោះដែលត្រូវបានផ្ទេរ - ប៉ុន្តែ rsync ត្រូវតែជាមុនសិន អាន ពីថាសទាំងអស់ ទិន្នន័យទាំងសងខាង ដើម្បីពិនិត្យមើលផលបូក និងប្រៀបធៀបវា។ ផ្ទុយទៅវិញ ការចម្លង ZFS មិនអានអ្វីក្រៅពីដើមឈើទ្រនិច - និងប្លុកណាមួយដែលមិនមានវត្តមាននៅក្នុងរូបថតដែលបានចែករំលែក។

ការបង្ហាប់ដែលភ្ជាប់មកជាមួយ

យន្តការចម្លងលើការសរសេរក៏ជួយសម្រួលដល់ប្រព័ន្ធបង្ហាប់ក្នុងជួរផងដែរ។ នៅក្នុងប្រព័ន្ធឯកសារប្រពៃណី ការបង្ហាប់មានបញ្ហា - ទាំងកំណែចាស់ និងកំណែថ្មីនៃទិន្នន័យដែលបានកែប្រែស្ថិតនៅក្នុងចន្លោះដូចគ្នា។

ប្រសិនបើយើងពិចារណាលើបំណែកនៃទិន្នន័យនៅកណ្តាលនៃឯកសារដែលចាប់ផ្តើមជីវិតជា megabyte សូន្យពី 0x00000000 ហើយដូច្នេះនៅលើនោះ វាងាយស្រួលណាស់ក្នុងការបង្ហាប់វាទៅផ្នែកមួយនៅលើថាស។ ប៉ុន្តែតើមានអ្វីកើតឡើងប្រសិនបើយើងជំនួសមេកាបៃនៃសូន្យនោះជាមួយនឹងទិន្នន័យដែលមិនអាចបង្ហាប់បានមួយមេហ្គាបៃដូចជា JPEG ឬ pseudo-random noise? ដោយមិននឹកស្មានដល់ ទិន្នន័យមេកាបៃនេះនឹងមិនត្រូវការមួយទេ ប៉ុន្តែផ្នែក 256 4 KiB ហើយនៅក្នុងកន្លែងនេះនៅលើថាសមានតែផ្នែកមួយប៉ុណ្ណោះដែលត្រូវបានបម្រុងទុក។

ZFS មិនមានបញ្ហានេះទេ ព្រោះកំណត់ត្រាដែលបានកែប្រែតែងតែត្រូវបានសរសេរទៅកាន់កន្លែងទំនេរដែលមិនប្រើ - ប្លុកដើមកាន់កាប់តែផ្នែកមួយ 4 KiB ហើយកំណត់ត្រាថ្មីនឹងកាន់កាប់ 256 ប៉ុន្តែនេះមិនមែនជាបញ្ហាទេ - បំណែកដែលបានកែប្រែថ្មីៗនេះពី " កណ្តាល" នៃឯកសារនឹងត្រូវបានសរសេរទៅកន្លែងទំនេរដែលមិនប្រើដោយមិនគិតពីថាតើទំហំរបស់វាបានផ្លាស់ប្តូរឬអត់ ដូច្នេះសម្រាប់ ZFS នេះគឺជាស្ថានភាពធម្មតា។

ការបង្ហាប់ ZFS ដើមត្រូវបានបិទតាមលំនាំដើម ហើយប្រព័ន្ធផ្តល់នូវក្បួនដោះស្រាយដែលអាចដោតបាន - បច្ចុប្បន្នគឺ LZ4, gzip (1-9), LZJB, និង ZLE ។

• LZ4 ។ គឺ​ជា​ក្បួន​ដោះស្រាយ​ការ​ផ្សាយ​ដែល​ផ្តល់​នូវ​អត្ថប្រយោជន៍​នៃ​ការ​បង្ហាប់ និង​ការ​បង្រួម​លឿន​បំផុត​សម្រាប់​ករណី​ប្រើ​ប្រាស់​ភាគ​ច្រើន - សូម្បី​តែ​នៅ​លើ CPU ដែល​មាន​ល្បឿន​យឺត​ក៏​ដោយ។
• GZIP គឺជាក្បួនដោះស្រាយដ៏ថ្លៃថ្លា ដែលអ្នកប្រើប្រាស់យូនីកទាំងអស់ស្គាល់ និងស្រលាញ់។ វា​អាច​ត្រូវ​បាន​អនុវត្ត​ជាមួយ​កម្រិត​បង្ហាប់ 1-9 ដោយ​មាន​សមាមាត្រ​បង្ហាប់ និង​ការ​ប្រើ​ស៊ីភីយូ​កើនឡើង​នៅពេល​វា​ឈាន​ដល់​កម្រិត 9 ។ ក្បួនដោះស្រាយ​គឺ​សម​ល្អ​សម្រាប់​ករណី​ប្រើ​អត្ថបទ​ទាំងអស់ (ឬ​អាច​បង្ហាប់​បាន​ខ្ពស់​ផ្សេងទៀត) ប៉ុន្តែ​ច្រើន​តែ​បង្ក​បញ្ហា​ស៊ីភីយូ - ប្រើ​វា ដោយប្រុងប្រយ័ត្ន ជាពិសេសនៅកម្រិតខ្ពស់។
• LZJB គឺជាក្បួនដោះស្រាយដើមនៅក្នុង ZFS ។ វាលែងប្រើហើយមិនគួរប្រើទៀតទេ LZ4 លើសវាគ្រប់វិធី។
• អាក្រក់ - ការអ៊ិនកូដកម្រិតសូន្យ ការអ៊ិនកូដកម្រិតសូន្យ។ វា​មិន​ប៉ះ​ទិន្នន័យ​ធម្មតា​ទាល់​តែ​សោះ ប៉ុន្តែ​បង្ហាប់​លេខ​សូន្យ​ធំៗ។ មានប្រយោជន៍សម្រាប់សំណុំទិន្នន័យដែលមិនអាចបង្រួមបានទាំងស្រុង (ដូចជា JPEG, MP4 ឬទម្រង់ដែលបានបង្ហាប់រួចហើយផ្សេងទៀត) ដោយសារវាមិនអើពើទិន្នន័យដែលមិនអាចបង្ហាប់បាន ប៉ុន្តែបង្រួមទំហំដែលមិនប្រើនៅក្នុងកំណត់ត្រាលទ្ធផល។

យើងសូមណែនាំការបង្ហាប់ LZ4 សម្រាប់ករណីប្រើប្រាស់ស្ទើរតែទាំងអស់; ការពិន័យលើការអនុវត្តនៅពេលជួបប្រទះទិន្នន័យដែលមិនអាចបង្រួមបានគឺតូចណាស់ និង កំណើន ដំណើរការសម្រាប់ទិន្នន័យធម្មតាគឺសំខាន់។ ការចម្លងរូបភាពម៉ាស៊ីននិម្មិតសម្រាប់ការដំឡើងថ្មីនៃប្រព័ន្ធប្រតិបត្តិការ Windows (ប្រព័ន្ធប្រតិបត្តិការដែលបានដំឡើងថ្មីៗ មិនទាន់មានទិន្នន័យនៅខាងក្នុងនៅឡើយ) ជាមួយ compression=lz4 លឿនជាង 27% compression=noneនៅ ការធ្វើតេស្តនេះក្នុងឆ្នាំ 2015.

ARC - ឃ្លាំងសម្ងាត់ជំនួសអាដាប់ធ័រ

ZFS គឺជាប្រព័ន្ធឯកសារទំនើបតែមួយគត់ដែលយើងដឹងថាប្រើយន្តការឃ្លាំងសម្ងាត់អានដោយខ្លួនឯង ជាជាងពឹងផ្អែកលើឃ្លាំងសម្ងាត់ទំព័ររបស់ប្រព័ន្ធប្រតិបត្តិការដើម្បីរក្សាទុកច្បាប់ចម្លងនៃប្លុកដែលបានអានថ្មីៗនៅក្នុង RAM ។

ទោះបីជាឃ្លាំងសម្ងាត់ដើមមិនមានបញ្ហាក៏ដោយ - ZFS មិនអាចឆ្លើយតបទៅនឹងសំណើបែងចែកអង្គចងចាំថ្មីបានលឿនដូចខឺណែល ដូច្នេះបញ្ហាប្រឈមថ្មី malloc() នៅលើការបែងចែកអង្គចងចាំអាចបរាជ័យប្រសិនបើវាត្រូវការ RAM ដែលបច្ចុប្បន្នកាន់កាប់ដោយ ARC ។ ប៉ុន្តែមានហេតុផលល្អក្នុងការប្រើឃ្លាំងសម្ងាត់ផ្ទាល់ខ្លួនរបស់អ្នក យ៉ាងហោចណាស់សម្រាប់ពេលនេះ។

ប្រព័ន្ធប្រតិបត្តិការទំនើបដែលគេស្គាល់ទាំងអស់ រួមទាំង MacOS, Windows, Linux និង BSD ប្រើក្បួនដោះស្រាយ LRU (Least Used) ដើម្បីអនុវត្តឃ្លាំងសម្ងាត់ទំព័រ។ នេះគឺជាក្បួនដោះស្រាយបឋមដែលរុញប្លុកឃ្លាំងសម្ងាត់ "ឡើងជួរ" បន្ទាប់ពីអាននីមួយៗ ហើយរុញប្លុក "ចុះជួរ" តាមតម្រូវការ ដើម្បីបន្ថែមការខកខានឃ្លាំងសម្ងាត់ថ្មី (ប្លុកដែលគួរត្រូវបានអានពីថាស មិនមែនមកពីឃ្លាំងសម្ងាត់ទេ) ឡើង។

ក្បួនដោះស្រាយជាធម្មតាដំណើរការល្អ ប៉ុន្តែនៅលើប្រព័ន្ធដែលមានសំណុំទិន្នន័យការងារធំ LRU ងាយនាំទៅរកការវាយលុក - បណ្តេញប្លុកដែលត្រូវការជាញឹកញាប់ ដើម្បីបង្កើតកន្លែងសម្រាប់ប្លុកដែលនឹងមិនត្រូវបានគេអានពីឃ្លាំងសម្ងាត់ម្តងទៀត។

ធ្នូ គឺ​ជា​ក្បួន​ដោះស្រាយ​ឆោតល្ងង់​តិច​ជាង​ដែល​អាច​ត្រូវ​បាន​គិត​ថា​ជា​ឃ្លាំង​សម្ងាត់ "មាន​ទម្ងន់"។ រាល់ពេលដែលប្លុកឃ្លាំងសម្ងាត់ត្រូវបានអាន វាកាន់តែ "ធ្ងន់" បន្តិច និងពិបាកក្នុងការបណ្តេញចេញ - ហើយសូម្បីតែបន្ទាប់ពីការបណ្តេញចេញប្លុកក៏ដោយ។ បានតាមដាន ក្នុងរយៈពេលជាក់លាក់មួយ។ ប្លុក​ដែល​ត្រូវ​បាន​បណ្តេញ​ចេញ ប៉ុន្តែ​បន្ទាប់​មក​ត្រូវ​បាន​អាន​ត្រឡប់​ទៅ​ក្នុង​ឃ្លាំង​សម្ងាត់​វិញ​ក៏​នឹង​ក្លាយ​ជា "ធ្ងន់​ជាង" ដែរ។

លទ្ធផលចុងក្រោយនៃរឿងទាំងអស់នេះគឺជាឃ្លាំងសម្ងាត់ដែលមានសមាមាត្របុកខ្ពស់ជាងច្រើន សមាមាត្ររវាងការចូលឃ្លាំងសម្ងាត់ (អានពីឃ្លាំងសម្ងាត់) និងបាត់ឃ្លាំងសម្ងាត់ (អានពីថាស)។ នេះគឺជាស្ថិតិដ៏សំខាន់បំផុត - មិនត្រឹមតែឃ្លាំងសម្ងាត់ដែលវាយប្រហារខ្លួនឯងតាមលំដាប់លំដោយលឿនជាងមុននោះទេ ការខកខាននៃឃ្លាំងសម្ងាត់ក៏អាចត្រូវបានបម្រើលឿនជាងមុនផងដែរ ដោយសារឃ្លាំងសម្ងាត់ចូលកាន់តែច្រើន ការស្នើសុំឌីសក្នុងពេលដំណាលគ្នាកាន់តែតិច និងរយៈពេលពន្យាពេលសម្រាប់ការខកខានដែលនៅសល់ដែលត្រូវតែ ត្រូវបានបម្រើជាមួយថាស។

សេចក្តីសន្និដ្ឋាន

បន្ទាប់ពីបានសិក្សាអត្ថន័យជាមូលដ្ឋាននៃ ZFS - របៀបដែលការចម្លងលើការសរសេរដំណើរការ ក៏ដូចជាទំនាក់ទំនងរវាងឃ្លាំងផ្ទុក ឧបករណ៍និម្មិត ប្លុក វិស័យ និងឯកសារ - យើងត្រៀមខ្លួនរួចរាល់ហើយដើម្បីពិភាក្សាអំពីការអនុវត្តជាក់ស្តែងជាមួយនឹងចំនួនពិត។

នៅក្នុងផ្នែកបន្ទាប់ យើងនឹងពិនិត្យមើលការអនុវត្តជាក់ស្តែងនៃអាងជាមួយ vdevs ឆ្លុះ និង RAIDz ធៀបនឹងគ្នាទៅវិញទៅមក និងក៏ធៀបនឹង RAID kernel ប្រពៃណីដែលយើងបានស្វែងរកផងដែរ។ មុននេះ.

ដំបូងយើងចង់គ្របដណ្តប់តែមូលដ្ឋាន - ZFS topologies ខ្លួនឯង - ប៉ុន្តែបន្ទាប់ពី បែបនេះ ចូរយើងត្រៀមខ្លួនដើម្បីនិយាយអំពីការដំឡើងកម្រិតខ្ពស់បន្ថែមទៀត និងការលៃតម្រូវ ZFS រួមទាំងការប្រើប្រាស់ប្រភេទ vdev ជំនួយដូចជា L2ARC, SLOG និងការបែងចែកពិសេស។

ប្រភព: www.habr.com