ការផ្ទុកទិន្នន័យយូរអង្វែង និង APIs ឯកសារលីនុច

ខ្ញុំស្រាវជ្រាវអំពីស្ថេរភាពនៃការផ្ទុកទិន្នន័យនៅក្នុងប្រព័ន្ធពពក បានសម្រេចចិត្តសាកល្បងខ្លួនឯង ដើម្បីប្រាកដថាខ្ញុំយល់អំពីរឿងជាមូលដ្ឋាន។ I ចាប់ផ្តើមដោយការអាន NVMe spec ដើម្បីយល់ពីអ្វីដែលធានាទាក់ទងនឹងការបន្តទិន្នន័យ (នោះគឺការធានាថាទិន្នន័យនឹងមានបន្ទាប់ពីការបរាជ័យប្រព័ន្ធ) ផ្តល់ឱ្យយើងនូវថាស NMVe ។ ខ្ញុំបានធ្វើការសន្និដ្ឋានសំខាន់ៗដូចខាងក្រោម៖ អ្នកត្រូវពិចារណាទិន្នន័យដែលខូចតាំងពីពេលដែលពាក្យបញ្ជាសរសេរទិន្នន័យត្រូវបានផ្តល់ឱ្យ ហើយរហូតដល់ពេលដែលពួកគេត្រូវបានសរសេរទៅកាន់ឧបករណ៍ផ្ទុក។ ទោះយ៉ាងណាក៏ដោយ នៅក្នុងកម្មវិធីភាគច្រើន ការហៅប្រព័ន្ធគឺត្រូវបានប្រើប្រាស់យ៉ាងមានសុវត្ថិភាពក្នុងការសរសេរទិន្នន័យ។

នៅក្នុងអត្ថបទនេះ ខ្ញុំស្វែងយល់ពីយន្តការតស៊ូដែលផ្តល់ដោយ APIs ឯកសារលីនុច។ វាហាក់ដូចជាថាអ្វីគ្រប់យ៉ាងគួរតែសាមញ្ញនៅទីនេះ: កម្មវិធីហៅពាក្យបញ្ជា write()ហើយបន្ទាប់ពីប្រតិបត្តិការនៃពាក្យបញ្ជានេះត្រូវបានបញ្ចប់ ទិន្នន័យនឹងត្រូវបានរក្សាទុកដោយសុវត្ថិភាពនៅលើថាស។ ប៉ុន្តែ write() ចម្លងតែទិន្នន័យកម្មវិធីទៅឃ្លាំងសម្ងាត់ខឺណែលដែលមាននៅក្នុង RAM ។ ដើម្បីបង្ខំឱ្យប្រព័ន្ធសរសេរទិន្នន័យទៅថាស យន្តការបន្ថែមមួយចំនួនត្រូវប្រើ។

ជាទូទៅ សម្ភារៈនេះគឺជាសំណុំនៃកំណត់ចំណាំដែលទាក់ទងនឹងអ្វីដែលខ្ញុំបានរៀនលើប្រធានបទដែលខ្ញុំចាប់អារម្មណ៍។ ប្រសិនបើយើងនិយាយយ៉ាងខ្លីអំពីសារៈសំខាន់បំផុត វាប្រែថាដើម្បីរៀបចំការផ្ទុកទិន្នន័យប្រកបដោយនិរន្តរភាព អ្នកត្រូវប្រើពាក្យបញ្ជា fdatasync() ឬបើកឯកសារដែលមានទង់ O_DSYNC. ប្រសិនបើអ្នកចាប់អារម្មណ៍ក្នុងការស្វែងយល់បន្ថែមអំពីអ្វីដែលកើតឡើងចំពោះទិន្នន័យនៅលើផ្លូវពីកូដទៅថាស សូមពិនិត្យមើល នេះ អត្ថបទ។

លក្ខណៈពិសេសនៃការប្រើប្រាស់មុខងារ write()

ការហៅតាមប្រព័ន្ធ write() កំណត់ក្នុងស្តង់ដារ IEEE POSIX ជាការប៉ុនប៉ងសរសេរទិន្នន័យទៅកាន់អ្នកពិពណ៌នាឯកសារ។ បន្ទាប់ពីបញ្ចប់ការងារដោយជោគជ័យ write() ប្រតិបត្តិការ​អាន​ទិន្នន័យ​ត្រូវតែ​ត្រឡប់​ពិតប្រាកដ​បៃ​ដែល​ត្រូវ​បាន​សរសេរ​ពីមុន ដោយ​ធ្វើ​ដូច្នេះ​ទោះបីជា​ទិន្នន័យ​កំពុង​ត្រូវ​បាន​ចូល​ប្រើ​ពី​ដំណើរការ​ឬ​ខ្សែស្រឡាយ​ផ្សេងទៀត (មើលចុះ ផ្នែកដែលត្រូវគ្នានៃស្តង់ដារ POSIX) ។ វាគឺជាការនៅក្នុងផ្នែកស្តីពីអន្តរកម្មនៃខ្សែស្រលាយជាមួយនឹងប្រតិបត្តិការឯកសារធម្មតា មានកំណត់សម្គាល់ដែលនិយាយថាប្រសិនបើខ្សែស្រឡាយពីរនីមួយៗហៅមុខងារទាំងនេះ នោះការហៅនីមួយៗត្រូវតែមើលឃើញនូវផលវិបាកដែលបានបញ្ជាក់ទាំងអស់ដែលការប្រតិបត្តិនៃការហៅផ្សេងទៀតនាំទៅដល់ ឬ មិនឃើញទាល់តែសោះ គ្មានលទ្ធផលអ្វីទាំងអស់។ នេះនាំឱ្យមានការសន្និដ្ឋានថារាល់ប្រតិបត្តិការ I/O ឯកសារទាំងអស់ត្រូវតែចាក់សោរលើធនធានដែលកំពុងដំណើរការ។

តើនេះមានន័យថាប្រតិបត្តិការ write() តើអាតូមិច? តាមទស្សនៈបច្ចេកទេស បាទ។ ប្រតិបត្តិការ​អាន​ទិន្នន័យ​ត្រូវតែ​ត្រឡប់​ទាំង​អស់​ឬ​គ្មាន​អ្វី​ដែល​ត្រូវ​បាន​សរសេរ​ជាមួយ write(). ប៉ុន្តែប្រតិបត្តិការ write()ស្របតាមស្ដង់ដារ មិនត្រូវបញ្ចប់ឡើយ ដោយបានកត់ត្រានូវអ្វីៗទាំងអស់ ដែលនាងត្រូវបានស្នើឱ្យសរសេរចុះ។ វាត្រូវបានអនុញ្ញាតឱ្យសរសេរតែផ្នែកនៃទិន្នន័យប៉ុណ្ណោះ។ ជាឧទាហរណ៍ យើងប្រហែលជាមានស្ទ្រីមពីរដែលនីមួយៗបន្ថែម 1024 បៃទៅឯកសារដែលបានពិពណ៌នាដោយអ្នកពណ៌នាឯកសារដូចគ្នា។ តាមទស្សនៈនៃស្តង់ដារ លទ្ធផលនឹងអាចទទួលយកបាន នៅពេលដែលប្រតិបត្តិការសរសេរនីមួយៗអាចបន្ថែមតែមួយបៃទៅឯកសារ។ ប្រតិបត្តិការទាំងនេះនឹងនៅតែជាអាតូមិច ប៉ុន្តែបន្ទាប់ពីពួកគេបានបញ្ចប់ ទិន្នន័យដែលពួកគេសរសេរទៅឯកសារនឹងមានភាពច្របូកច្របល់។ នៅទីនេះ ការពិភាក្សាគួរឱ្យចាប់អារម្មណ៍ខ្លាំងណាស់លើប្រធានបទនេះនៅលើ Stack Overflow ។

មុខងារ fsync() និង fdatasync()

មធ្យោបាយងាយស្រួលបំផុតដើម្បីបញ្ចូនទិន្នន័យទៅថាសគឺការហៅមុខងារ fsync(). មុខងារនេះស្នើឱ្យប្រព័ន្ធប្រតិបត្តិការផ្លាស់ទីប្លុកដែលបានកែប្រែទាំងអស់ពីឃ្លាំងសម្ងាត់ទៅថាស។ នេះរួមបញ្ចូលទាំងទិន្នន័យមេតាទាំងអស់នៃឯកសារ (ពេលវេលាចូលប្រើ ពេលវេលាកែប្រែឯកសារ និងដូច្នេះនៅលើ)។ ខ្ញុំជឿថាទិន្នន័យមេតានេះកម្រត្រូវការណាស់ ដូច្នេះប្រសិនបើអ្នកដឹងថាវាមិនសំខាន់សម្រាប់អ្នក អ្នកអាចប្រើមុខងារបាន។ fdatasync()។ នេះ ជួយ នៅលើ fdatasync() វានិយាយថាក្នុងអំឡុងពេលប្រតិបត្តិការនៃមុខងារនេះ ចំនួននៃទិន្នន័យមេតាត្រូវបានរក្សាទុកទៅក្នុងថាស ដែល "ចាំបាច់សម្រាប់ការអនុវត្តត្រឹមត្រូវនៃប្រតិបត្តិការអានទិន្នន័យខាងក្រោម" ។ ហើយនេះគឺជាអ្វីដែលកម្មវិធីភាគច្រើនយកចិត្តទុកដាក់។

បញ្ហាមួយដែលអាចកើតឡើងនៅទីនេះគឺថាយន្តការទាំងនេះមិនធានាថាឯកសារអាចត្រូវបានរកឃើញបន្ទាប់ពីការបរាជ័យដែលអាចកើតមាន។ ជាពិសេសនៅពេលដែលឯកសារថ្មីត្រូវបានបង្កើតមួយគួរតែហៅ fsync() សម្រាប់ថតដែលមានវា។ បើមិនដូច្នេះទេ បន្ទាប់ពីគាំង វាអាចបង្ហាញថាឯកសារនេះមិនមានទេ។ ហេតុផលសម្រាប់នេះគឺថានៅក្រោមយូនីក ដោយសារការប្រើប្រាស់តំណភ្ជាប់រឹង ឯកសារអាចមាននៅក្នុងថតច្រើន។ ដូច្នេះនៅពេលហៅ fsync() មិនមានវិធីសម្រាប់ឯកសារដើម្បីដឹងថាតើទិន្នន័យថតណាមួយគួរតែត្រូវបានហូរទៅថាស (នៅទីនេះ អ្នកអាចអានបន្ថែមអំពីរឿងនេះ) ។ វាហាក់ដូចជាប្រព័ន្ធឯកសារ ext4 មានសមត្ថភាព ដោយស្វ័យប្រវត្តិ ប្រើ fsync() ទៅកាន់ថតដែលមានឯកសារដែលត្រូវគ្នា ប៉ុន្តែនេះអាចមិនមែនជាករណីជាមួយប្រព័ន្ធឯកសារផ្សេងទៀតទេ។

យន្តការនេះអាចត្រូវបានអនុវត្តខុសគ្នានៅក្នុងប្រព័ន្ធឯកសារផ្សេងៗគ្នា។ ខ្ញុំបានប្រើ blktrace ដើម្បីស្វែងយល់អំពីអ្វីដែលប្រតិបត្តិការថាសត្រូវបានប្រើនៅក្នុងប្រព័ន្ធឯកសារ ext4 និង XFS ។ ទាំងពីរចេញពាក្យបញ្ជាសរសេរធម្មតាទៅថាសសម្រាប់ទាំងមាតិកានៃឯកសារ និងទិនានុប្បវត្តិប្រព័ន្ធឯកសារ សម្អាតឃ្លាំងសម្ងាត់ និងចេញដោយអនុវត្ត FUA (ការចូលប្រើអង្គភាពបង្ខំ សរសេរទិន្នន័យដោយផ្ទាល់ទៅថាស រំលងឃ្លាំងសម្ងាត់) សរសេរទៅទិនានុប្បវត្តិ។ ពួកគេប្រហែលជាធ្វើដូច្នេះដើម្បីបញ្ជាក់ការពិតនៃប្រតិបត្តិការ។ នៅលើដ្រាយដែលមិនគាំទ្រ FUA វាបណ្តាលឱ្យមានការឆាបឆេះឃ្លាំងសម្ងាត់ពីរ។ ការពិសោធន៍របស់ខ្ញុំបានបង្ហាញថា fdatasync() លឿនបន្តិច fsync(). ឧបករណ៍ប្រើប្រាស់ blktrace បង្ហាញថា fdatasync() ជាធម្មតាសរសេរទិន្នន័យតិចទៅថាស (ក្នុង ext4 fsync() សរសេរ 20 KiB និង fdatasync() - ១៦ គីប) ។ ដូចគ្នានេះផងដែរខ្ញុំបានរកឃើញថា XFS គឺលឿនជាង ext16 បន្តិច។ ហើយនៅទីនេះដោយមានជំនួយ blktrace អាចរកឃើញថា fdatasync() បញ្ចូនទិន្នន័យតិចទៅថាស (4 KiB ក្នុង XFS)។

ស្ថានភាពមិនច្បាស់លាស់នៅពេលប្រើ fsync()

ខ្ញុំអាចគិតពីស្ថានភាពមិនច្បាស់លាស់ចំនួនបីដែលទាក់ទងនឹង fsync()ដែលខ្ញុំបានជួបប្រទះនៅក្នុងការអនុវត្ត។

ហេតុការណ៍​បែប​នេះ​លើក​ដំបូង​បាន​កើត​ឡើង​ក្នុង​ឆ្នាំ​២០០៨។ នៅពេលនោះ ចំណុចប្រទាក់ Firefox 2008 "ជាប់គាំង" ប្រសិនបើឯកសារមួយចំនួនធំកំពុងត្រូវបានសរសេរទៅថាស។ បញ្ហាគឺថាការអនុវត្តចំណុចប្រទាក់បានប្រើមូលដ្ឋានទិន្នន័យ SQLite ដើម្បីរក្សាទុកព័ត៌មានអំពីស្ថានភាពរបស់វា។ បន្ទាប់ពីការផ្លាស់ប្តូរនីមួយៗដែលបានកើតឡើងនៅក្នុងចំណុចប្រទាក់មុខងារត្រូវបានហៅ fsync()ដែលបានផ្តល់ការធានាដ៏ល្អនៃការផ្ទុកទិន្នន័យដែលមានស្ថេរភាព។ នៅក្នុងប្រព័ន្ធឯកសារ ext3 ដែលបានប្រើបន្ទាប់មកមានមុខងារ fsync() ហូរទៅថាសទំព័រ "កខ្វក់" ទាំងអស់នៅក្នុងប្រព័ន្ធ ហើយមិនត្រឹមតែទំព័រដែលទាក់ទងនឹងឯកសារដែលត្រូវគ្នានោះទេ។ នេះមានន័យថាការចុចប៊ូតុងនៅក្នុង Firefox អាចបណ្តាលឱ្យទិន្នន័យមេកាបៃត្រូវបានសរសេរទៅថាសម៉ាញេទិក ដែលអាចចំណាយពេលច្រើនវិនាទី។ ដំណោះស្រាយចំពោះបញ្ហា តាមដែលខ្ញុំយល់ វា សម្ភារៈគឺដើម្បីផ្លាស់ទីការងារជាមួយមូលដ្ឋានទិន្នន័យទៅជាកិច្ចការផ្ទៃខាងក្រោយអសមកាល។ នេះមានន័យថា Firefox បានប្រើដើម្បីអនុវត្តតម្រូវការរក្សាការផ្ទុកកាន់តែតឹងរ៉ឹងជាងការចាំបាច់ ហើយលក្ខណៈពិសេសរបស់ប្រព័ន្ធឯកសារ ext3 ធ្វើឱ្យបញ្ហានេះកាន់តែធ្ងន់ធ្ងរ។

បញ្ហាទី ២ បានកើតឡើងក្នុងឆ្នាំ ២០០៩ ។ បន្ទាប់មក បន្ទាប់ពីប្រព័ន្ធគាំង អ្នកប្រើប្រាស់ប្រព័ន្ធឯកសារ ext2009 ថ្មីបានរកឃើញថា ឯកសារដែលបានបង្កើតថ្មីៗជាច្រើនមានប្រវែងសូន្យ ប៉ុន្តែវាមិនបានកើតឡើងជាមួយប្រព័ន្ធឯកសារ ext4 ចាស់នោះទេ។ នៅក្នុងកថាខណ្ឌមុន ខ្ញុំបាននិយាយអំពីរបៀបដែល ext3 បោះចោលទិន្នន័យច្រើនពេកនៅលើឌីស ដែលធ្វើឲ្យអ្វីៗថយចុះច្រើន។ fsync(). ដើម្បីកែលម្អស្ថានភាពនេះ ext4 លុបតែទំព័រ "កខ្វក់" ទាំងនោះដែលពាក់ព័ន្ធនឹងឯកសារជាក់លាក់មួយ។ ហើយទិន្នន័យនៃឯកសារផ្សេងទៀតនៅតែមាននៅក្នុងអង្គចងចាំសម្រាប់រយៈពេលយូរជាងជាមួយ ext3 ។ វាត្រូវបានធ្វើដើម្បីកែលម្អការអនុវត្ត (តាមលំនាំដើម ទិន្នន័យស្ថិតនៅក្នុងស្ថានភាពនេះរយៈពេល 30 វិនាទី អ្នកអាចកំណត់រចនាសម្ព័ន្ធនេះដោយប្រើ dirty_expire_centisecs; នៅទីនេះ អ្នកអាចស្វែងរកព័ត៌មានបន្ថែមអំពីរឿងនេះ) ។ នេះមានន័យថា ទិន្នន័យមួយចំនួនធំអាចបាត់បង់ដោយមិនអាចទាញយកមកវិញបានបន្ទាប់ពីការគាំង។ ដំណោះស្រាយចំពោះបញ្ហានេះគឺត្រូវប្រើ fsync() នៅក្នុងកម្មវិធីដែលត្រូវការផ្តល់នូវការផ្ទុកទិន្នន័យដែលមានស្ថេរភាព និងការពារពួកគេឱ្យបានច្រើនតាមដែលអាចធ្វើទៅបានពីផលវិបាកនៃការបរាជ័យ។ មុខងារ fsync() ដំណើរការកាន់តែមានប្រសិទ្ធភាពជាមួយ ext4 ជាង ext3 ។ គុណវិបត្តិនៃវិធីសាស្រ្តនេះគឺថាការប្រើប្រាស់របស់វាដូចពីមុន ដំណើរការយឺតៗ ដូចជាការដំឡើងកម្មវិធីជាដើម។ មើលព័ត៌មានលម្អិតអំពីរឿងនេះ នៅទីនេះ и នៅទីនេះ.

បញ្ហាទីបីទាក់ទងនឹង fsync(), ដើមឆ្នាំ 2018 ។ បន្ទាប់មកនៅក្នុងក្របខ័ណ្ឌនៃគម្រោង PostgreSQL វាត្រូវបានគេរកឃើញថាប្រសិនបើមុខងារ fsync() ជួបប្រទះកំហុសមួយ វាសម្គាល់ទំព័រ "កខ្វក់" ថា "ស្អាត" ។ ជាលទ្ធផលការហៅដូចខាងក្រោម fsync() កុំធ្វើអ្វីជាមួយទំព័របែបនេះ។ ដោយសារតែនេះ ទំព័រដែលបានកែប្រែត្រូវបានរក្សាទុកក្នុងអង្គចងចាំ ហើយមិនដែលសរសេរទៅថាសឡើយ។ នេះគឺជាគ្រោះមហន្តរាយពិតប្រាកដព្រោះកម្មវិធីនឹងគិតថាទិន្នន័យមួយចំនួនត្រូវបានសរសេរទៅថាស ប៉ុន្តែតាមពិតវានឹងមិនមានទេ។ ការបរាជ័យបែបនេះ fsync() គឺកម្រណាស់ កម្មវិធីក្នុងស្ថានភាពបែបនេះមិនអាចធ្វើអ្វីបានស្ទើរតែទាំងអស់ដើម្បីប្រយុទ្ធប្រឆាំងនឹងបញ្ហានេះ។ ប៉ុន្មានថ្ងៃនេះ នៅពេលដែលវាកើតឡើង PostgreSQL និងកម្មវិធីផ្សេងទៀតគាំង។ វាគឺជាការនៅក្នុង "Can Applications Recover from fsync Failures?" បញ្ហានេះត្រូវបានស្វែងយល់យ៉ាងលម្អិត។ បច្ចុប្បន្នដំណោះស្រាយដ៏ល្អបំផុតចំពោះបញ្ហានេះគឺត្រូវប្រើ Direct I/O ជាមួយនឹងទង់ជាតិ O_SYNC ឬជាមួយទង់ជាតិ O_DSYNC. ជាមួយនឹងវិធីសាស្រ្តនេះ ប្រព័ន្ធនឹងរាយការណ៍អំពីកំហុសដែលអាចកើតឡើងនៅពេលអនុវត្តប្រតិបត្តិការសរសេរទិន្នន័យជាក់លាក់ ប៉ុន្តែវិធីសាស្រ្តនេះតម្រូវឱ្យកម្មវិធីគ្រប់គ្រងសតិបណ្ដោះអាសន្នដោយខ្លួនឯង។ សូមអានបន្ថែមអំពីវា។ នៅទីនេះ и នៅទីនេះ.

ការបើកឯកសារដោយប្រើទង់ O_SYNC និង O_DSYNC

ចូរយើងត្រលប់ទៅការពិភាក្សាអំពីយន្តការលីនុច ដែលផ្តល់នូវការផ្ទុកទិន្នន័យជាប់លាប់។ មានន័យថា យើងកំពុងនិយាយអំពីការប្រើប្រាស់ទង់ជាតិ O_SYNC ឬទង់ជាតិ O_DSYNC នៅពេលបើកឯកសារដោយប្រើការហៅប្រព័ន្ធ បើក (). ជាមួយនឹងវិធីសាស្រ្តនេះ ប្រតិបត្តិការសរសេរទិន្នន័យនីមួយៗត្រូវបានអនុវត្តដូចជាបន្ទាប់ពីពាក្យបញ្ជានីមួយៗ write() ប្រព័ន្ធត្រូវបានផ្តល់ឱ្យរៀងគ្នានូវពាក្យបញ្ជា fsync() и fdatasync()។ នេះ លក្ខណៈបច្ចេកទេសរបស់ POSIX វាត្រូវបានគេហៅថា "ការធ្វើសមកាលកម្ម I/O File Integrity Completion" និង "Data Integrity Completion"។ អត្ថប្រយោជន៍ចម្បងនៃវិធីសាស្រ្តនេះគឺថាមានតែការហៅប្រព័ន្ធមួយប៉ុណ្ណោះដែលត្រូវប្រតិបត្តិដើម្បីធានានូវភាពត្រឹមត្រូវនៃទិន្នន័យ មិនមែនពីរទេ (ឧទាហរណ៍ − write() и fdatasync()) គុណវិបត្តិចម្បងនៃវិធីសាស្រ្តនេះគឺថារាល់ប្រតិបត្តិការសរសេរដោយប្រើឧបករណ៍ពិពណ៌នាឯកសារដែលត្រូវគ្នានឹងត្រូវបានធ្វើសមកាលកម្មដែលអាចកំណត់លទ្ធភាពនៃរចនាសម្ព័ន្ធកូដកម្មវិធី។

ការប្រើប្រាស់ Direct I/O ជាមួយនឹងទង់ O_DIRECT

ការហៅតាមប្រព័ន្ធ open() គាំទ្រទង់ជាតិ O_DIRECTដែលត្រូវបានរចនាឡើងដើម្បីឆ្លងកាត់ឃ្លាំងសម្ងាត់ប្រព័ន្ធប្រតិបត្តិការ អនុវត្តប្រតិបត្តិការ I/O អន្តរកម្មដោយផ្ទាល់ជាមួយឌីស។ នេះក្នុងករណីជាច្រើនមានន័យថា សរសេរពាក្យបញ្ជាដែលចេញដោយកម្មវិធីនឹងត្រូវបានបកប្រែដោយផ្ទាល់ទៅជាពាក្យបញ្ជាដែលមានបំណងធ្វើការជាមួយថាស។ ប៉ុន្តែជាទូទៅយន្តការនេះមិនមែនជាការជំនួសមុខងារទេ។ fsync() ឬ fdatasync(). ការពិតគឺថាឌីសខ្លួនឯងអាចធ្វើបាន ការពន្យាពេលឬឃ្លាំងសម្ងាត់ ពាក្យបញ្ជាសមរម្យសម្រាប់ការសរសេរទិន្នន័យ។ ហើយកាន់តែអាក្រក់ទៅទៀត នៅក្នុងករណីពិសេសមួយចំនួន ប្រតិបត្តិការ I/O បានធ្វើនៅពេលប្រើទង់ O_DIRECT, ការចាក់ផ្សាយ ទៅក្នុងប្រតិបត្តិការ buffed ប្រពៃណី។ មធ្យោបាយងាយស្រួលបំផុតដើម្បីដោះស្រាយបញ្ហានេះគឺត្រូវប្រើទង់ដើម្បីបើកឯកសារ O_DSYNCដែលនឹងមានន័យថា ប្រតិបត្តិការសរសេរនីមួយៗនឹងត្រូវបានបន្តដោយការហៅ fdatasync().

វាបានប្រែក្លាយថាប្រព័ន្ធឯកសារ XFS ថ្មីៗនេះបានបន្ថែម "ផ្លូវលឿន" សម្រាប់ O_DIRECT|O_DSYNC- កំណត់ត្រាទិន្នន័យ។ ប្រសិនបើប្លុកត្រូវបានសរសេរជាន់លើដោយប្រើ O_DIRECT|O_DSYNCបន្ទាប់មក XFS ជំនួសឱ្យការសម្អាតឃ្លាំងសម្ងាត់ នឹងប្រតិបត្តិពាក្យបញ្ជាសរសេរ FUA ប្រសិនបើឧបករណ៍គាំទ្រវា។ ខ្ញុំបានផ្ទៀងផ្ទាត់វាដោយប្រើឧបករណ៍ប្រើប្រាស់ blktrace នៅលើប្រព័ន្ធលីនុច 5.4/អ៊ូប៊ុនទូ 20.04។ វិធីសាស្រ្តនេះគួរតែមានប្រសិទ្ធភាពជាង ព្រោះវាសរសេរចំនួនទិន្នន័យអប្បបរមាទៅក្នុងថាស ហើយប្រើប្រតិបត្តិការមួយ មិនមែនពីរទេ (សរសេរ និងលុបឃ្លាំងសម្ងាត់)។ ខ្ញុំបានរកឃើញតំណភ្ជាប់ទៅ បំណះ ខឺណែលឆ្នាំ 2018 ដែលអនុវត្តយន្តការនេះ។ មានការពិភាក្សាមួយចំនួនអំពីការអនុវត្តការបង្កើនប្រសិទ្ធភាពនេះចំពោះប្រព័ន្ធឯកសារផ្សេងទៀត ប៉ុន្តែតាមដែលខ្ញុំដឹង XFS គឺជាប្រព័ន្ធឯកសារតែមួយគត់ដែលគាំទ្រវារហូតមកដល់ពេលនេះ។

មុខងារ sync_file_range()

លីនុចមានការហៅជាប្រព័ន្ធ sync_file_range()ដែលអាចឱ្យអ្នកបញ្ចោញតែផ្នែកនៃឯកសារទៅថាស មិនមែនឯកសារទាំងមូលទេ។ ការហៅទូរសព្ទនេះចាប់ផ្តើមដំណើរការអសមកាលកម្ម ហើយមិនរង់ចាំឱ្យវាបញ្ចប់នោះទេ។ ប៉ុន្តែនៅក្នុងឯកសារយោងទៅ sync_file_range() ពាក្យបញ្ជានេះត្រូវបានគេនិយាយថា "គ្រោះថ្នាក់ណាស់" ។ វាមិនត្រូវបានណែនាំឱ្យប្រើវាទេ។ លក្ខណៈពិសេសនិងគ្រោះថ្នាក់ sync_file_range() បានពិពណ៌នាយ៉ាងល្អនៅក្នុង នេះ សម្ភារៈ។ ជាពិសេស ការហៅទូរសព្ទនេះហាក់ដូចជាប្រើ RocksDB ដើម្បីគ្រប់គ្រងនៅពេលដែលខឺណែលបញ្ចេញទិន្នន័យ "កខ្វក់" ទៅក្នុងថាស។ ប៉ុន្តែនៅពេលជាមួយគ្នានៅទីនោះដើម្បីធានាបាននូវការផ្ទុកទិន្នន័យមានស្ថេរភាពវាក៏ត្រូវបានគេប្រើផងដែរ។ fdatasync()។ នេះ កូដ RocksDB មានមតិគួរឱ្យចាប់អារម្មណ៍មួយចំនួនលើប្រធានបទនេះ។ ឧទាហរណ៍វាមើលទៅដូចជាការហៅ sync_file_range() នៅពេលប្រើ ZFS មិនបញ្ចោញទិន្នន័យទៅថាសទេ។ បទពិសោធន៍ប្រាប់ខ្ញុំថា កូដដែលកម្រប្រើ អាចមានកំហុស។ ដូច្នេះ ខ្ញុំសូមណែនាំកុំឱ្យប្រើការហៅតាមប្រព័ន្ធនេះ លុះត្រាតែចាំបាច់។

ការហៅតាមប្រព័ន្ធដើម្បីជួយធានាឱ្យទិន្នន័យបន្ត

ខ្ញុំបានសន្និដ្ឋានថាមានវិធីសាស្រ្តចំនួនបីដែលអាចត្រូវបានប្រើដើម្បីអនុវត្តប្រតិបត្តិការ I/O ជាប់លាប់។ ពួកគេទាំងអស់ទាមទារការហៅមុខងារ fsync() សម្រាប់ថតដែលឯកសារត្រូវបានបង្កើត។ ទាំងនេះគឺជាវិធីសាស្រ្ត៖

1. ការហៅមុខងារ fdatasync() ឬ fsync() បន្ទាប់ពីមុខងារ write() (ប្រើប្រសើរជាង fdatasync()).
2. ធ្វើការជាមួយអ្នកពិពណ៌នាឯកសារដែលបើកដោយទង់ O_DSYNC ឬ O_SYNC (ប្រសើរជាង - ជាមួយទង់ O_DSYNC).
3. ការប្រើប្រាស់ពាក្យបញ្ជា pwritev2() ជាមួយនឹងទង់ជាតិ RWF_DSYNC ឬ RWF_SYNC (និយមជាមួយទង់ជាតិ RWF_DSYNC).

កំណត់សម្គាល់ការអនុវត្ត

ខ្ញុំមិនបានវាស់វែងដោយប្រុងប្រយ័ត្ននូវដំណើរការនៃយន្តការផ្សេងៗដែលខ្ញុំបានស៊ើបអង្កេតនោះទេ។ ភាពខុសគ្នាដែលខ្ញុំបានកត់សម្គាល់នៅក្នុងល្បឿននៃការងាររបស់ពួកគេគឺតូចណាស់។ នេះមានន័យថាខ្ញុំអាចខុស ហើយក្នុងលក្ខខណ្ឌផ្សេងទៀត រឿងដូចគ្នាអាចបង្ហាញលទ្ធផលខុសគ្នា ជាដំបូង ខ្ញុំនឹងនិយាយអំពីអ្វីដែលប៉ះពាល់ដល់ការអនុវត្តបន្ថែមទៀត ហើយបន្ទាប់មកអំពីអ្វីដែលប៉ះពាល់ដល់ការអនុវត្តតិចជាង។

1. ការសរសេរជាន់លើទិន្នន័យឯកសារគឺលឿនជាងការបន្ថែមទិន្នន័យទៅឯកសារមួយ (ការកើនឡើងនៃការអនុវត្តអាចមានពី 2-100%) ។ ការភ្ជាប់ទិន្នន័យទៅឯកសារតម្រូវឱ្យមានការផ្លាស់ប្តូរបន្ថែមទៅលើទិន្នន័យមេតារបស់ឯកសារ សូម្បីតែបន្ទាប់ពីការហៅរបស់ប្រព័ន្ធក៏ដោយ។ fallocate()ប៉ុន្តែទំហំនៃឥទ្ធិពលនេះអាចប្រែប្រួល។ ខ្ញុំសូមណែនាំសម្រាប់ដំណើរការល្អបំផុត ដើម្បីហៅទូរសព្ទ fallocate() ដើម្បីបែងចែកកន្លែងដែលត្រូវការជាមុន។ បន្ទាប់មក ចន្លោះនេះត្រូវតែបំពេញដោយលេខសូន្យ ហើយត្រូវបានហៅ fsync(). វានឹងធ្វើឱ្យប្លុកដែលត្រូវគ្នានៅក្នុងប្រព័ន្ធឯកសារត្រូវបានសម្គាល់ថា "បែងចែក" ជំនួសឱ្យ "មិនបានបែងចែក" ។ នេះផ្តល់នូវការកែលម្អការអនុវត្តតិចតួច (ប្រហែល 2%) ។ ដូចគ្នានេះផងដែរ ថាសមួយចំនួនអាចមានប្រតិបត្តិការចូលដំណើរការប្លុកដំបូងយឺតជាងឧបករណ៍ផ្សេងទៀត។ នេះមានន័យថាការបំពេញចន្លោះដោយលេខសូន្យអាចនាំទៅរកការកែលម្អការអនុវត្តដ៏សំខាន់ (ប្រហែល 100%) ។ ជាពិសេសវាអាចកើតឡើងជាមួយថាស។ AWS EBS (នេះ​ជា​ទិន្នន័យ​មិន​ផ្លូវការ ខ្ញុំ​មិន​អាច​បញ្ជាក់​បាន​ទេ)។ ដូចគ្នាសម្រាប់ការផ្ទុក។ GCP ថាសជាប់លាប់ (ហើយនេះគឺជាព័ត៌មានផ្លូវការរួចហើយ បញ្ជាក់ដោយការធ្វើតេស្ត) អ្នកជំនាញផ្សេងទៀតបានធ្វើដូចគ្នា។ ការសង្កេតទាក់ទងនឹងថាសផ្សេងៗគ្នា។
2. ការហៅតាមប្រព័ន្ធតិចជាងមុន ដំណើរការកាន់តែខ្ពស់ (ការទទួលបានប្រហែល 5%) ។ វាមើលទៅដូចជាការហៅទូរស័ព្ទ open() ជាមួយនឹងទង់ជាតិ O_DSYNC ឬហៅ pwritev2() ជាមួយនឹងទង់ជាតិ RWF_SYNC ការហៅទូរស័ព្ទលឿនជាងមុន fdatasync(). ខ្ញុំសង្ស័យថាចំណុចនៅទីនេះគឺថាជាមួយនឹងវិធីសាស្រ្តនេះ ការពិតដែលថាការហៅតាមប្រព័ន្ធតិចជាងមុនត្រូវតែអនុវត្តដើម្បីដោះស្រាយបញ្ហាដូចគ្នា (ការហៅមួយជំនួសឱ្យពីរ) ដើរតួនាទីមួយ។ ប៉ុន្តែភាពខុសគ្នានៃការអនុវត្តគឺតូចណាស់ដូច្នេះអ្នកអាចមិនអើពើវាបានយ៉ាងងាយស្រួលហើយប្រើអ្វីមួយនៅក្នុងកម្មវិធីដែលមិននាំឱ្យមានភាពស្មុគស្មាញនៃតក្កវិជ្ជារបស់វា។

ប្រសិនបើអ្នកចាប់អារម្មណ៍លើប្រធានបទនៃការរក្សាទុកទិន្នន័យប្រកបដោយនិរន្តរភាព ខាងក្រោមនេះជាសម្ភារមានប្រយោជន៍មួយចំនួន៖

• វិធីសាស្រ្តចូលប្រើ I/O - ទិដ្ឋភាពទូទៅនៃមូលដ្ឋាននៃយន្តការបញ្ចូល/ទិន្នផល។
• ធានាទិន្នន័យទៅដល់ថាស - រឿងអំពីអ្វីដែលកើតឡើងចំពោះទិន្នន័យនៅលើផ្លូវពីកម្មវិធីទៅថាស។
• ពេលណាដែលអ្នកគួរធ្វើសមកាលកម្មថតដែលមាន - ចម្លើយចំពោះសំណួរថាតើពេលណាត្រូវដាក់ពាក្យ fsync() សម្រាប់ថត។ សរុបមក វាប្រែថាអ្នកត្រូវធ្វើវានៅពេលបង្កើតឯកសារថ្មី ហើយហេតុផលសម្រាប់ការណែនាំនេះគឺថានៅក្នុងលីនុចអាចមានឯកសារយោងជាច្រើនចំពោះឯកសារដូចគ្នា។
• SQL Server នៅលើលីនុច៖ FUA Internals - នេះគឺជាការពិពណ៌នាអំពីរបៀបដែលការផ្ទុកទិន្នន័យជាប់លាប់ត្រូវបានអនុវត្តនៅក្នុង SQL Server នៅលើវេទិកាលីនុច។ មានការប្រៀបធៀបគួរឱ្យចាប់អារម្មណ៍មួយចំនួនរវាងការហៅប្រព័ន្ធ Windows និង Linux នៅទីនេះ។ ខ្ញុំស្ទើរតែប្រាកដថាវាត្រូវបានអរគុណចំពោះសម្ភារៈនេះដែលខ្ញុំបានរៀនអំពីការបង្កើនប្រសិទ្ធភាព FUA នៃ XFS ។

តើអ្នកធ្លាប់បាត់បង់ទិន្នន័យដែលអ្នកគិតថាត្រូវបានរក្សាទុកដោយសុវត្ថិភាពនៅលើថាសទេ?

ប្រភព: www.habr.com