បទសម្ភាសន៍លើកទីពីរជាមួយ Eduard Shishkin អ្នកអភិវឌ្ឍន៍ Reiser4 FS

បទសម្ភាសន៍លើកទីពីរជាមួយ Eduard Shishkin អ្នកបង្កើតប្រព័ន្ធឯកសារ Reiser4 ត្រូវបានបោះពុម្ពផ្សាយ។

ដើម្បីចាប់ផ្តើម សូមរំលឹកអ្នកអានថា អ្នកធ្វើការឱ្យអ្នកណា និងកន្លែងណា។

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

តើអ្នកកំពុងប្តេជ្ញាចិត្តចំពោះសាខាខឺណែលមេឬ?

កម្រណាស់ ហើយប្រសិនបើនិយោជករបស់ខ្ញុំទាមទារវា។ លើកចុងក្រោយគឺប្រហែល 9 ឆ្នាំមុន ខ្ញុំបានផ្ញើបំណះដើម្បីបង្កើនទំហំផ្ទុកដែលចែករំលែកនៅលើម៉ាស៊ីនដោយប្រើពិធីការ XNUMXp (ឈ្មោះផ្សេងទៀតសម្រាប់អាជីវកម្មនេះគឺ VirtFS) ។ កំណត់សម្គាល់សំខាន់មួយត្រូវតែធ្វើឡើងនៅទីនេះ៖ ទោះបីជាខ្ញុំបានធ្វើការជាមួយលីនុចយូរមកហើយក៏ដោយ ខ្ញុំមិនដែលជាអ្នកគាំទ្រវាទេ ពោលគឺខ្ញុំ "ដកដង្ហើមស្មើៗគ្នា" ដូចអ្វីៗផ្សេងទៀតដែរ។ ជាពិសេស ប្រសិនបើខ្ញុំសម្គាល់ឃើញមានកំហុស ខ្ញុំអាចចង្អុលវាបានភ្លាមៗតែម្តង។ ហើយដូច្នេះអ្នកអាចធ្វើតាមនរណាម្នាក់ហើយបញ្ចុះបញ្ចូលពួកគេ - នេះនឹងមិនកើតឡើងទេ។

ខ្ញុំចាំបានថាកាលពី 10 ឆ្នាំមុន អ្នកពិតជារិះគន់រចនាប័ទ្មអភិវឌ្ឍន៍ខឺណែល។ តាមទស្សនៈរបស់អ្នក (ឬប្រហែលជាសាជីវកម្ម) តើមានអ្វីផ្លាស់ប្តូរ តើសហគមន៍កាន់តែមានការឆ្លើយតបឬអត់? បើ​មិន​មែន​គិត​ថា​បន្ទោស​អ្នកណា?

ខ្ញុំមិនបានឃើញការផ្លាស់ប្តូរវិជ្ជមានណាមួយទេ។ បញ្ហាចម្បងរបស់សហគមន៍គឺការជំនួសវិទ្យាសាស្ត្រដោយបច្ចេកវិទ្យានយោបាយ ទំនាក់ទំនងផ្ទាល់ខ្លួន មតិភាគច្រើន ប្រជានិយម ដំបូន្មានពី "សំឡេងខាងក្នុង" ការសម្របសម្រួលរលួយ - អ្វីក៏ដោយក្រៅពីវិទ្យាសាស្ត្រ។ វិទ្យាសាស្ត្រកុំព្យូទ័រ មិនថាអ្នកមើលវាយ៉ាងណាទេ ជាដំបូង និងសំខាន់បំផុត គឺជាវិទ្យាសាស្ត្រពិតប្រាកដមួយ។ ហើយប្រសិនបើនរណាម្នាក់ចាប់ផ្តើមប្រកាសអត្ថន័យសម្រាប់ 2x2 ដែលខុសពី 4 ក្រោមបដានៃ "Linux វិធី” ឬក្រោមវិធីផ្សេងទៀត នោះវាមិនទំនងជានាំមកនូវអ្វីក្រៅពីគ្រោះថ្នាក់នោះទេ។

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

តើអ្នកវាយតម្លៃវឌ្ឍនភាពក្នុងការអភិវឌ្ឍន៍ Btrfs យ៉ាងដូចម្តេច? តើ FS នេះអាចកម្ចាត់ជំងឺកុមារបានទេ? តើអ្នកដាក់ទីតាំងសម្រាប់ខ្លួនអ្នកដោយរបៀបណា - ជា FS "សម្រាប់ផ្ទះ" ឬសម្រាប់ការប្រើប្រាស់សាជីវកម្មផងដែរ?

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

វាមើលទៅដូចនេះ (បានសាកល្បងសម្រាប់ខឺណែល Linux ៥.១២)។ នៅលើប្រព័ន្ធដែលទើបដំឡើងថ្មី ស្គ្រីបមួយត្រូវបានដំណើរការ ដែលបង្កើតឯកសារដែលមានឈ្មោះជាក់លាក់នៅក្នុងថតឯកសារដើមក្នុងរង្វិលជុំ សរសេរទិន្នន័យទៅពួកវានៅអុហ្វសិតជាក់លាក់ ហើយបន្ទាប់មកលុបឯកសារទាំងនេះ។ បន្ទាប់ពីដំណើរការស្គ្រីបនេះមួយនាទី គ្មានអ្វីចម្លែកកើតឡើងទេ។ បន្ទាប់ពីប្រាំនាទី ទំហំដែលកាន់កាប់នៅលើភាគថាសកើនឡើងបន្តិច។ បន្ទាប់ពីពីរទៅបីម៉ោង វាឈានដល់ 50% (ពីតម្លៃដំបូង 15%)។ ហើយបន្ទាប់ពីប្រាំទៅប្រាំមួយម៉ោង ស្គ្រីបគាំងជាមួយនឹងកំហុស "គ្មានទំហំទំនេរនៅលើភាគថាស"។ បន្ទាប់ពីនេះ អ្នកមិនអាចសរសេរសូម្បីតែឯកសារ 4K ទៅកាន់ភាគថាសរបស់អ្នកបានទៀតទេ។

ស្ថានភាពគួរឱ្យចាប់អារម្មណ៍មួយកើតឡើង៖ អ្នកបានបញ្ចប់ដោយមិនសរសេរអ្វីទៅភាគថាស ហើយទំហំទំនេរទាំងអស់ (ប្រហែល 85%) បានបាត់នៅកន្លែងណាមួយ។ ការវិភាគនៃផ្នែកដែលទទួលរងការវាយប្រហារបែបនេះនឹងបង្ហាញឱ្យឃើញថ្នាំងមែកធាងជាច្រើនដែលមានធាតុតែមួយ (វត្ថុដែលបំពាក់ដោយសោ) ទំហំជាច្រើនបៃ។ នោះគឺមាតិកាដែលកាន់កាប់ 15% នៃទំហំថាសពីមុនប្រែទៅជា "លាប" ស្មើៗគ្នាលើភាគថាសទាំងមូល ដូច្នេះគ្មានកន្លែងសម្រាប់សរសេរឯកសារថ្មីទេ ព្រោះកូនសោរបស់វាធំជាងឯកសារដែលមានស្រាប់ទាំងអស់ ហើយឥតគិតថ្លៃ។ ប្លុកនៅលើភាគថាសបានអស់ហើយ។

លើសពីនេះទៅទៀត វាកើតឡើងរួចហើយនៅលើការកំណត់រចនាសម្ព័ន្ធ Btrfs មូលដ្ឋាន (ដោយមិនមានរូបថត ភាគរង។ នៃប្លុកដែលមិនបានធ្វើទ្រង់ទ្រាយ) - លទ្ធផលចុងក្រោយនឹងដូចគ្នា។

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

នៅលើសមូហភាព ម៉ាស៊ីនបម្រើ អ្នកវាយប្រហារនឹងអាច "នាំមុខ" ពួកគេបានជានិច្ច។ អ្នកគ្រប់គ្រងប្រព័ន្ធនឹងមិនអាចកំណត់ថាអ្នកណាជាអ្នករំលោភបំពានគាត់ពិតប្រាកដនោះទេ។ វិធីលឿនបំផុតដើម្បីជួសជុលបញ្ហានេះនៅក្នុង Btrfs គឺត្រូវស្ដាររចនាសម្ព័ន្ធនៃដើមឈើ B ធម្មតា ពោលគឺរចនាទម្រង់ឌីសឡើងវិញ និងសរសេរផ្នែកសំខាន់នៃកូដ Btrfs ឡើងវិញ។ នេះនឹងចំណាយពេល 8-10 ឆ្នាំ រួមទាំងការបំបាត់កំហុស ដោយផ្តល់ថាអ្នកអភិវឌ្ឍន៍បានអនុវត្តតាមឯកសារដើមយ៉ាងតឹងរ៉ឹងលើក្បួនដោះស្រាយ និងរចនាសម្ព័ន្ធទិន្នន័យពាក់ព័ន្ធ ហើយមិនបានលេង "ទូរស័ព្ទខូច" ដូចទម្លាប់ (និងលើកទឹកចិត្ត) នៅក្នុង...Linux វិធី"។

នៅទីនេះយើងក៏ត្រូវបន្ថែមពេលវេលាដែលត្រូវការសម្រាប់អ្នកអភិវឌ្ឍន៍ដើម្បីយល់ទាំងអស់នេះ។ នេះគឺជាកន្លែងដែលវាកាន់តែពិបាក។ ទោះយ៉ាងណាក៏ដោយ 10 ឆ្នាំគឺមិនគ្រប់គ្រាន់សម្រាប់ពួកគេក្នុងការយល់។ មែនហើយ រហូតដល់ពេលនោះ អ្នកមិនអាចសង្ឃឹមសម្រាប់អព្ភូតហេតុបានទេ។ វានឹងមិនកើតឡើងក្នុងទម្រង់នៃជម្រើសម៉ោន "ដែលអ្នក និងខ្ញុំមិនបានដឹងអំពី" ឬនៅក្នុងទម្រង់នៃបំណះដែល "គ្រាន់តែជាបញ្ហានៃអាជីវកម្ម" ដើម្បីរៀបចំ។ សម្រាប់ "ជួសជុល" ដ៏ប្រញាប់ប្រញាល់បែបនេះ ខ្ញុំនឹងបង្ហាញសេណារីយ៉ូថ្មីនៃការខូចទ្រង់ទ្រាយ។ B-trees គឺជាប្រធានបទដែលខ្ញុំចូលចិត្តបំផុត ហើយខ្ញុំត្រូវតែនិយាយថា រចនាសម្ព័ន្ធទាំងនេះមិនអត់ឱនចំពោះសេរីភាពជាមួយខ្លួនឯងទេ!

តើខ្ញុំដាក់ Btrfs សម្រាប់ខ្លួនខ្ញុំដោយរបៀបណា? ជា​អ្វី​ដែល​មិន​អាច​ហៅ​ថា​ជា​ប្រព័ន្ធ​ឯកសារ​បាន​ទេ ទុក​ឱ្យ​ប្រើ​តែ​ម្នាក់​ឯង។ ដោយសារតែតាមនិយមន័យ FS គឺជាប្រព័ន្ធរង OS ដែលទទួលខុសត្រូវចំពោះការគ្រប់គ្រងប្រកបដោយប្រសិទ្ធភាពនៃធនធាន "disk space" ដែលយើងមើលមិនឃើញក្នុងករណី Btrfs ។ ជាការប្រសើរណាស់ ស្រមៃថាអ្នកមកហាងដើម្បីទិញនាឡិកាមួយ ដើម្បីកុំឱ្យយឺតពេលសម្រាប់ការងារ ហើយជំនួសឱ្យនាឡិកា ពួកគេបានលក់ឱ្យអ្នកនូវអាំងភ្លើងអគ្គិសនីជាមួយនឹងកម្មវិធីកំណត់ម៉ោងរយៈពេលអតិបរមា 30 នាទី។ ដូច្នេះស្ថានភាពជាមួយ Btrfs គឺកាន់តែអាក្រក់។

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

ខ្ញុំចង់សុំយោបល់លើការបញ្ឈប់ការគាំទ្រ Btrfs នៅក្នុង RHEL ។

មិនមានអ្វីពិសេសដើម្បីផ្តល់យោបល់នៅទីនេះទេអ្វីគ្រប់យ៉ាងគឺច្បាស់ណាស់។ ពួកគេក៏មានវាជា "ការមើលបច្ចេកវិទ្យា" ផងដែរ។ ដូច្នេះខ្ញុំមិនបានឆ្លងកាត់ "ការមើលជាមុន" នេះទេ។ សូមកុំទុកស្លាកនេះជារៀងរហូត! ប៉ុន្តែ​ពួកគេ​មិន​អាច​បើក​ដំណើរការ​ផលិតផល​រចនា​ដែល​មាន​កំហុស​ដោយ​មាន​ការ​គាំទ្រ​ពេញលេញ​ទេ។ RHEL គឺជាសហគ្រាសមួយ ពោលគឺទំនាក់ទំនងទំនិញ-លុយដែលបានកំណត់។ Red Hat មិនអាចគំរាមកំហែងអ្នកប្រើប្រាស់ដូចដែលពួកគេធ្វើនៅលើបញ្ជីសំបុត្ររួម Btrfs បានទេ។ គ្រាន់តែស្រមៃមើលស្ថានភាព៖ អតិថិជនដែលបានចំណាយប្រាក់ដែលរកបានយ៉ាងលំបាករបស់គាត់សម្រាប់ឌីស ហើយអ្នកសម្រាប់ការគាំទ្រផងដែរ ចង់យល់ពីកន្លែងដែលទំហំថាសរបស់គាត់បានទៅ បន្ទាប់ពីគាត់មិនបានសរសេរអ្វីទាំងអស់។ តើអ្នកនឹងឆ្លើយអ្វីគាត់ចំពោះរឿងនេះ?

បន្ថែមទៀត។ អតិថិជនរបស់ Red Hat រួមមានធនាគារធំៗ និងកន្លែងប្តូរប្រាក់។ ស្រមៃមើលថាតើនឹងមានអ្វីកើតឡើងប្រសិនបើពួកគេទទួលរងការវាយប្រហារ DoS ដោយផ្អែកលើភាពងាយរងគ្រោះដែលបានលើកឡើងនៅក្នុង Btrfs ។ តើអ្នកគិតថាអ្នកណាជាអ្នកទទួលខុសត្រូវចំពោះរឿងនេះ? ចំពោះអ្នកដែលហៀបនឹងចង្អុលម្រាមដៃរបស់ពួកគេទៅកាន់បន្ទាត់នៃអាជ្ញាប័ណ្ណ GPL ដែលជាកន្លែងដែលវាត្រូវបានសរសេរថាអ្នកនិពន្ធមិនទទួលខុសត្រូវចំពោះអ្វីនោះទេខ្ញុំនឹងនិយាយភ្លាមៗថា: "លាក់វាឱ្យឆ្ងាយ!" មួកក្រហមនឹងឆ្លើយ ហើយតាមរបៀបដែលវាហាក់ដូចជាមិនគ្រប់គ្រាន់! ប៉ុន្តែខ្ញុំដឹងថា Red Hat មិនប្រឈមមុខនឹងបញ្ហាបែបនេះទេ ដោយសារក្រុមវិស្វករ QA ដ៏ខ្លាំងរបស់ពួកគេ ដែលខ្ញុំមានឱកាសធ្វើការយ៉ាងជិតស្និទ្ធក្នុងពេលរបស់ខ្ញុំ។

ហេតុអ្វីបានជាក្រុមហ៊ុនមួយចំនួនបន្តគាំទ្រ Btrfs នៅក្នុងផលិតផលសហគ្រាសរបស់ពួកគេ?

សូមចំណាំថា បុព្វបទ "enterprise" នៅក្នុងឈ្មោះផលិតផលមិនមានន័យច្រើនទេ។ Enterprise គឺជារង្វាស់នៃការទទួលខុសត្រូវដែលបង្កប់នៅក្នុងទំនាក់ទំនងកិច្ចសន្យាជាមួយអតិថិជន។ ខ្ញុំស្គាល់តែសហគ្រាសមួយដែលផ្អែកលើ GNU ប៉ុណ្ណោះ។Linux — នោះគឺជា RHEL។ អ្វីៗផ្សេងទៀត តាមគំនិតរបស់ខ្ញុំ គឺគ្រាន់តែក្លែងបន្លំជាសហគ្រាសប៉ុណ្ណោះ ប៉ុន្តែមិនមែនទេ។ ហើយចុងក្រោយ ប្រសិនបើមានតម្រូវការសម្រាប់អ្វីមួយ នោះនឹងតែងតែមានការផ្គត់ផ្គង់ (ក្នុងករណីរបស់យើង នោះគឺជា "ការគាំទ្រ" ដែលបានរៀបរាប់ខាងលើ)។ តម្រូវការអាចមានសម្រាប់អ្វីៗគ្រប់យ៉ាង រួមទាំងកម្មវិធីដែលមិនអាចប្រើបានផងដែរ។ របៀបដែលតម្រូវការនេះត្រូវបានបង្កើតឡើង និងអ្នកណាជាអ្នកជំរុញវា គឺជាប្រធានបទមួយផ្សេងទៀតទាំងស្រុង។

ដូច្នេះ ខ្ញុំនឹងមិនប្រញាប់ប្រញាល់សន្និដ្ឋានណាមួយឡើយ បន្ទាប់ពីមានពាក្យចចាមអារ៉ាមថា Facebook បានដាក់ពង្រាយ Btrfs នៅលើម៉ាស៊ីនមេរបស់ខ្លួន។ លើសពីនេះ អាសយដ្ឋានរបស់អ្នកទាំងនោះ ម៉ាស៊ីនបម្រើ ខ្ញុំសូមណែនាំឱ្យរក្សាវាទុកដោយប្រុងប្រយ័ត្នដោយហេតុផលដែលបានរៀបរាប់ខាងលើ។

ហេតុអ្វីបានជាមានការខិតខំប្រឹងប្រែងយ៉ាងខ្លាំងក្នុងការសម្អាតកូដ XFS នាពេលថ្មីៗនេះ? យ៉ាងណាមិញ ដំបូងឡើយ នេះគឺជាប្រព័ន្ធឯកសារភាគីទីបី ហើយ ext4 មានស្ថេរភាពក្នុងរយៈពេលយូរ និងមានការបន្តពីកំណែដែលមានស្ថេរភាពស្មើគ្នាពីមុន។ តើ Red Hat មានចំណាប់អារម្មណ៍អ្វីនៅក្នុង XFS? តើវាសមហេតុផលទេក្នុងការអភិវឌ្ឍន៍ប្រព័ន្ធឯកសារពីរដែលមានលក្ខណៈស្រដៀងគ្នាក្នុងគោលបំណង - ext4 និង XFS?

ខ្ញុំ​មិន​ចាំ​ថា​អ្វី​ដែល​ជំរុញ​ចិត្ត​នេះ​។ វាពិតជាអាចទៅរួចដែលគំនិតផ្តួចផ្តើមនេះបានមកពីអតិថិជន Red Hat ។ ខ្ញុំចាំបានថា ការស្រាវជ្រាវប្រភេទនេះត្រូវបានអនុវត្ត៖ នៅលើប្រព័ន្ធឯកសារមួយចំនួនចាប់ពីដើមទឹក វត្ថុមួយចំនួនធំត្រូវបានបង្កើតឡើងនៅលើដ្រាយវ៍ខ្ពស់នៃជំនាន់ថ្មី។ យោងតាមលទ្ធផល XFS មានអាកប្បកិរិយាប្រសើរជាង ext4 ។ ដូច្នេះ​ហើយ ពួក​គេ​ចាប់​ផ្ដើម​ផ្សព្វផ្សាយ​វា​ជា​ការ​សន្យា​បំផុត។ ក្នុងករណីណាក៏ដោយ ខ្ញុំនឹងមិនស្វែងរកអ្វីដែលគួរឱ្យចាប់អារម្មណ៍នៅទីនេះទេ។

សម្រាប់​ខ្ញុំ វា​ដូច​ជា​គេ​បាន​ជំនួស​សាប៊ូ​។ មិនមានចំណុចណាមួយក្នុងការអភិវឌ្ឍន៍ ext4 និង XFS ទេ។ ទាំងពីរស្របគ្នានិងណាមួយនៃពួកគេដើម្បីជ្រើសរើសពី។ គ្មានអ្វីល្អនឹងមកពីនេះទេ។ ទោះបីជានៅក្នុងធម្មជាតិមានស្ថានភាពជាញឹកញាប់នៅពេលដែលមានសក្តានុពលច្រើនសម្រាប់កំណើន ប៉ុន្តែមិនមានកន្លែងសម្រាប់រីកចម្រើននោះទេ។ ក្នុង​ករណី​នេះ ការ​រីក​ចម្រើន​ថ្មី​ដ៏​ចម្លែក​ខុស​ៗ​គ្នា​បាន​កើត​ឡើង ដែល​អ្នក​រាល់​គ្នា​ចង្អុល​មេដៃ ("អូ មើល អ្វី​ដែល​អ្នក​នឹង​មិន​ឃើញ​ក្នុង​ជីវិត​នេះ!")។

តើអ្នកគិតថាបញ្ហានៃការរំលោភលើស្រទាប់ត្រូវបានដោះស្រាយ (ក្នុងន័យអវិជ្ជមាន) ជាមួយនឹងវត្តមាននៃមុខងារអ៊ិនគ្រីបនៅក្នុង ext4, F2FS (មិននិយាយពី RAID នៅក្នុង Btrfs) ទេ?

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

ឧទាហរណ៍ ការឆ្លុះ ដែលជាសកម្មភាពប្រពៃណីសម្រាប់ស្រទាប់ប្លុក ធ្វើឱ្យយល់បានក្នុងការអនុវត្តនៅកម្រិតប្រព័ន្ធឯកសារ។ សម្រាប់ហេតុផលផ្សេងៗគ្នា។ ឧទាហរណ៍ អំពើពុករលួយទិន្នន័យ "ស្ងាត់" (រលួយបន្តិច) កើតឡើងនៅលើថាស។ នេះគឺជាពេលដែលឧបករណ៍ដំណើរការបានត្រឹមត្រូវ ប៉ុន្តែទិន្នន័យប្លុកត្រូវបានខូចខាតដោយមិនបានរំពឹងទុកក្រោមឥទ្ធិពលនៃហ្គាម៉ា quantum រឹងដែលបញ្ចេញដោយ quasar ឆ្ងាយ។ល។ អ្វី​ដែល​អាក្រក់​បំផុត​គឺ​ប្រសិនបើ​ប្លុក​នេះ​ក្លាយ​ជា​ប្លុក​ប្រព័ន្ធ FS (superblock, bitmap block, storage tree node ។

សូមចំណាំថាកញ្ចក់ដែលផ្តល់ដោយស្រទាប់ប្លុក (ដែលគេហៅថា RAID 1) នឹងមិនជួយសង្គ្រោះអ្នកពីបញ្ហានេះទេ។ ជាការប្រសើរណាស់: នរណាម្នាក់គួរតែពិនិត្យមើល checksums និងអានការចម្លងក្នុងករណីបរាជ័យ? លើសពីនេះទៀត វាសមហេតុផលក្នុងការឆ្លុះមិនត្រឹមតែអ្វីៗទាំងអស់ប៉ុណ្ណោះទេ ប៉ុន្តែមានតែទិន្នន័យមេតាប៉ុណ្ណោះ។ ទិន្នន័យសំខាន់ៗមួយចំនួន (ឧទាហរណ៍ ឯកសារដែលអាចប្រតិបត្តិបាននៃកម្មវិធីសំខាន់ៗ) អាចត្រូវបានរក្សាទុកជាទិន្នន័យមេតា។ ក្នុងករណីនេះពួកគេទទួលបានការធានាសុវត្ថិភាពដូចគ្នា។ វាសមហេតុផលក្នុងការប្រគល់ការការពារទិន្នន័យដែលនៅសល់ទៅប្រព័ន្ធរងផ្សេងទៀត (ប្រហែលជាសូម្បីតែកម្មវិធីអ្នកប្រើប្រាស់) - យើងបានផ្តល់លក្ខខណ្ឌចាំបាច់ទាំងអស់សម្រាប់រឿងនេះ។

កញ្ចក់ "សេដ្ឋកិច្ច" បែបនេះមានសិទ្ធិមាន ហើយពួកវាអាចត្រូវបានរៀបចំយ៉ាងមានប្រសិទ្ធភាពនៅកម្រិតប្រព័ន្ធឯកសារប៉ុណ្ណោះ។ បើមិនដូច្នេះទេ ការបំពានលើស្រទាប់កំពុងពង្រាយប្រព័ន្ធរងដែលមានកូដស្ទួនសម្រាប់ជាប្រយោជន៍ដល់អត្ថប្រយោជន៍មីក្រូទស្សន៍មួយចំនួន។ ឧទាហរណ៍ដ៏គួរឱ្យចាប់អារម្មណ៍មួយគឺការអនុវត្ត RAID-5 ដោយប្រើ FS ។ ដំណោះស្រាយបែបនេះ (RAID / LVM ផ្ទាល់ខ្លួននៅក្នុងប្រព័ន្ធឯកសារ) សម្លាប់អ្នកក្រោយក្នុងន័យស្ថាបត្យកម្ម។ វាគួរតែត្រូវបានកត់សម្គាល់ផងដែរនៅទីនេះថាការរំលោភលើស្រទាប់គឺ "ដាក់នៅលើស្ទ្រីម" ដោយប្រភេទផ្សេងៗនៃអ្នកបោកប្រាស់ទីផ្សារ។ អវត្ដមាននៃគំនិតណាមួយ មុខងារដែលត្រូវបានអនុវត្តយូរមកហើយនៅកម្រិតជិតខាងត្រូវបានបន្ថែមទៅប្រព័ន្ធរង នេះត្រូវបានបង្ហាញជាមុខងារមានប្រយោជន៍បំផុតថ្មី ហើយត្រូវបានជំរុញយ៉ាងសកម្ម។

Reiser4 ត្រូវបានចោទប្រកាន់ពីបទរំលោភលើកម្រិត "ពីខាងក្រោម" ។ ដោយផ្អែកលើការពិតដែលថាប្រព័ន្ធឯកសារមិនមែនជា monolithic ដូចអ្វីផ្សេងទៀតទាំងអស់ទេប៉ុន្តែជាម៉ូឌុលការសន្មត់ដែលមិនបានបញ្ជាក់ត្រូវបានធ្វើឡើងដែលវាធ្វើអ្វីដែលកម្រិតខាងលើ (VFS) គួរតែធ្វើ។

តើវាអាចទៅរួចទេក្នុងការនិយាយអំពីការស្លាប់របស់ ReiserFS v3.6 និងឧទាហរណ៍ JFS? ថ្មីៗនេះ ពួកគេស្ទើរតែគ្មានការចាប់អារម្មណ៍នៅក្នុងស្នូល។ តើពួកគេលែងប្រើហើយឬនៅ?

នៅទីនេះយើងត្រូវកំណត់ថាតើការស្លាប់នៃផលិតផលសូហ្វវែរមានន័យដូចម្តេច។ ម៉្យាងវិញទៀត ពួកគេត្រូវបានប្រើប្រាស់ដោយជោគជ័យ (នោះជាអ្វីដែលពួកគេត្រូវបានបង្កើតឡើងសម្រាប់ទាំងអស់) ដែលមានន័យថាពួកគេរស់នៅ។ ម្យ៉ាងវិញទៀត ខ្ញុំមិនអាចនិយាយសម្រាប់ JFS បានទេ (ខ្ញុំមិនដឹងច្រើនទេ) ប៉ុន្តែ ReiserFS (v3) ពិបាកសម្របខ្លួនទៅនឹងនិន្នាការថ្មី (សាកល្បងក្នុងការអនុវត្ត)។ នេះមានន័យថានៅពេលអនាគតអ្នកអភិវឌ្ឍន៍នឹងយកចិត្តទុកដាក់មិនមែនចំពោះវាទេប៉ុន្តែសម្រាប់អ្នកដែលងាយស្រួលសម្របខ្លួន។ ពីខាងនេះវាប្រែថា, alas, វាត្រូវបានស្លាប់នៅក្នុងលក្ខខណ្ឌស្ថាបត្យកម្ម។ ខ្ញុំនឹងមិនរៀបចំគំនិតនៃ "លែងប្រើខាងសីលធម៌" ទាល់តែសោះ។ ឧទាហរណ៍វាអនុវត្តបានល្អចំពោះតុរប្យួរខោអាវ ប៉ុន្តែមិនមែនចំពោះផលិតផលសូហ្វវែរទេ។ មានគំនិតនៃភាពអន់ជាង និងឧត្តមភាពនៅក្នុងអ្វីមួយ។ ខ្ញុំពិតជាអាចនិយាយបានថា ReserFS v3 ឥឡូវនេះគឺទាបជាង Reiser4 នៅក្នុងអ្វីគ្រប់យ៉ាង ប៉ុន្តែនៅក្នុងប្រភេទនៃបន្ទុកការងារមួយចំនួនវាប្រសើរជាង FSs ផ្សេងទៀតទាំងអស់។

តើអ្នកដឹងអំពីការអភិវឌ្ឍន៍របស់ FS Tux3 និង HAMMER/HAMMER2 (FS for DragonFly BSD) ទេ?

បាទ យើងដឹងហើយ។ នៅក្នុង Tux3 ខ្ញុំធ្លាប់ចាប់អារម្មណ៍លើបច្ចេកវិទ្យានៃការថតរូបរបស់ពួកគេ (ដែលគេហៅថា "ទ្រនិចកំណែ") ប៉ុន្តែនៅក្នុង Reiser4 យើងទំនងជានឹងទៅផ្លូវផ្សេង។ ខ្ញុំ​បាន​គិត​អំពី​ការ​គាំទ្រ​រូប​ថត​ជា​យូរ​មក​ហើយ ហើយ​មិន​ទាន់​បាន​សម្រេច​ចិត្ត​ពី​របៀប​អនុវត្ត​វា​សម្រាប់​ភាគ​សាមញ្ញ Reiser4 ទេ។ ការពិតគឺថាបច្ចេកទេសបញ្ជរយោង "ខ្ជិល" ដែលស្នើឡើងដោយ Ohad Rodeh ដំណើរការសម្រាប់តែដើមឈើ B ប៉ុណ្ណោះ។ យើងមិនមានពួកគេទេ។ សម្រាប់រចនាសម្ព័ន្ធទិន្នន័យទាំងនោះដែលត្រូវបានប្រើនៅក្នុង Reiesr4 បញ្ជរ "ខ្ជិល" មិនត្រូវបានកំណត់ទេ - ដើម្បីណែនាំពួកវា វាចាំបាច់ក្នុងការដោះស្រាយបញ្ហាក្បួនដោះស្រាយមួយចំនួនដែលគ្មាននរណាម្នាក់បានអនុវត្តនៅឡើយ។

យោងទៅតាម HAMMER: ខ្ញុំបានអានអត្ថបទមួយពីអ្នកបង្កើត។ មិន​ចាប់អារម្មណ៍។ ជាថ្មីម្តងទៀត B-ដើមឈើ។ រចនាសម្ព័ន្ធទិន្នន័យនេះគឺហួសសម័យអស់សង្ឃឹម។ យើងបានបោះបង់ចោលវានៅសតវត្សរ៍ចុងក្រោយ។

តើអ្នកវាយតម្លៃតម្រូវការដែលកំពុងកើនឡើងសម្រាប់បណ្តាញ FSs ដូចជា CephFS/GlusterFS/etc យ៉ាងដូចម្តេច? តើតម្រូវការនេះមានន័យថាការផ្លាស់ប្តូរអាទិភាពរបស់អ្នកអភិវឌ្ឍន៍ឆ្ពោះទៅរកបណ្តាញ FS និងការយកចិត្តទុកដាក់មិនគ្រប់គ្រាន់ចំពោះ FS ក្នុងស្រុកទេ?

បាទ ការផ្លាស់ប្តូរអាទិភាពបែបនេះបានកើតឡើង។ ការអភិវឌ្ឍន៍ប្រព័ន្ធឯកសារក្នុងស្រុកបាននៅទ្រឹង។ Alas ការធ្វើអ្វីមួយដែលសំខាន់សម្រាប់បរិមាណក្នុងស្រុកឥឡូវនេះគឺពិបាកណាស់ ហើយមិនមែនគ្រប់គ្នាអាចធ្វើបាននោះទេ។ គ្មាននរណាម្នាក់ចង់វិនិយោគលើការអភិវឌ្ឍន៍របស់ពួកគេទេ។ នេះគឺដូចគ្នានឹងការស្នើសុំឱ្យអង្គការពាណិជ្ជកម្មដើម្បីបែងចែកប្រាក់សម្រាប់ការស្រាវជ្រាវគណិតវិទ្យាដែរ ដោយមិនមានការសាទរទេ ពួកគេនឹងសួរអ្នកពីរបៀបដែលអ្នកអាចរកលុយតាមទ្រឹស្តីបទថ្មី។ ឥឡូវនេះ FS ក្នុងស្រុកគឺជាអ្វីមួយដែលលេចចេញជាវេទមន្ត "ក្រៅប្រអប់" និង "គួរតែដំណើរការជានិច្ច" ហើយប្រសិនបើវាមិនដំណើរការ វាបណ្តាលឱ្យមានការរអ៊ូរទាំដោយមិនបានដោះស្រាយដូចជា "បាទ តើពួកគេកំពុងគិតអ្វី!"

អាស្រ័យហេតុនេះ កង្វះការយកចិត្តទុកដាក់ចំពោះ FS ក្នុងស្រុក ទោះបីជានៅតែមានការងារច្រើននៅក្នុងតំបន់នោះ។ ហើយបាទ អ្នកគ្រប់គ្នាបានងាកទៅរកកន្លែងផ្ទុកចែកចាយ ដែលត្រូវបានបង្កើតឡើងនៅលើមូលដ្ឋាននៃប្រព័ន្ធឯកសារមូលដ្ឋានដែលមានស្រាប់។ វាទាន់សម័យណាស់ឥឡូវនេះ។ ឃ្លា "ទិន្នន័យធំ" បណ្តាលឱ្យមានការប្រញាប់ប្រញាល់ adrenaline សម្រាប់មនុស្សជាច្រើន ដោយភ្ជាប់វាជាមួយសន្និសីទ សិក្ខាសាលា ប្រាក់ខែធំៗ ។ល។

តើវាសមហេតុផលប៉ុណ្ណាជាគោលការណ៍ក្នុងការអនុវត្តប្រព័ន្ធឯកសារបណ្តាញក្នុងចន្លោះខឺណែល ជាជាងក្នុងទំហំអ្នកប្រើប្រាស់?

វិធីសាស្រ្តសមហេតុផលបំផុតដែលមិនទាន់ត្រូវបានអនុវត្តនៅគ្រប់ទីកន្លែង។ ជាទូទៅ សំណួរថាតើប្រព័ន្ធឯកសារបណ្តាញគួរត្រូវបានអនុវត្តនៅក្នុងចន្លោះណាដែលហៅថា "ដាវមុខពីរ"។ សូមក្រឡេកមើលឧទាហរណ៍មួយ។ ម៉ាស៊ីនភ្ញៀវបានកត់ត្រាទិន្នន័យនៅលើម៉ាស៊ីនពីចម្ងាយ។ ពួកគេបានធ្លាក់ចូលទៅក្នុងឃ្លាំងសម្ងាត់ទំព័ររបស់នាងក្នុងទម្រង់ជាទំព័រកខ្វក់។ នេះគឺជាការងារសម្រាប់ប្រព័ន្ធឯកសារបណ្តាញ "ច្រកផ្លូវស្តើង" ក្នុងចន្លោះខឺណែល។ បន្ទាប់មកប្រព័ន្ធប្រតិបត្តិការនឹងសួរអ្នកឱ្យសរសេរទំព័រទាំងនោះទៅក្នុងថាសដើម្បីដោះលែងពួកវា។ បន្ទាប់មកម៉ូឌុល FS បណ្តាញបញ្ជូនបន្ត IO-បញ្ជូនបន្ត (បញ្ជូន) ចូលមកលេង។ វាកំណត់ថាតើម៉ាស៊ីនមេមួយណា (ថ្នាំងម៉ាស៊ីនមេ) ទំព័រទាំងនេះនឹងទៅ។

បន្ទាប់មកជង់បណ្តាញបានឆ្លងកាត់ (ហើយដូចដែលយើងដឹងហើយថាវាត្រូវបានអនុវត្តនៅក្នុងចន្លោះខឺណែល) ។ បន្ទាប់មក ថ្នាំងម៉ាស៊ីនមេទទួលបានកញ្ចប់ព័ត៌មាននោះជាមួយនឹងទិន្នន័យ ឬទិន្នន័យមេតា ហើយណែនាំម៉ូឌុលផ្ទុកខាងក្រោយ (ឧទាហរណ៍ FS មូលដ្ឋានដែលដំណើរការក្នុងចន្លោះខឺណែល) ដើម្បីកត់ត្រាអ្វីៗទាំងអស់នេះ។ ដូច្នេះ យើងបានកាត់បន្ថយសំណួរទៅកន្លែងដែលម៉ូឌុល "ផ្ញើ" និង "ទទួល" គួរតែដំណើរការ។ ប្រសិនបើម៉ូឌុលណាមួយដំណើរការក្នុងចន្លោះអ្នកប្រើប្រាស់ វានឹងនាំទៅរកការផ្លាស់ប្តូរបរិបទដោយជៀសមិនរួច (ដោយសារតម្រូវការប្រើប្រាស់សេវាកម្មខឺណែល)។ ចំនួននៃកុងតាក់បែបនេះអាស្រ័យលើព័ត៌មានលម្អិតនៃការអនុវត្ត។

ប្រសិនបើមានកុងតាក់បែបនេះច្រើន នោះល្បឿនផ្ទុក (ដំណើរការ I/O) នឹងថយចុះ។ ប្រសិនបើទំហំផ្ទុកខាងក្រោយរបស់អ្នកត្រូវបានបង្កើតឡើងពីថាសយឺត នោះអ្នកនឹងមិនកត់សំគាល់ការធ្លាក់ចុះគួរឱ្យកត់សម្គាល់នោះទេ។ ប៉ុន្តែប្រសិនបើអ្នកមានថាសលឿន (SSD, NVRAM ។ វិធីស្ដង់ដារដើម្បីសន្សំប្រាក់គឺត្រូវផ្លាស់ទីម៉ូឌុលទៅក្នុងចន្លោះខឺណែល។ ជាឧទាហរណ៍ យើងបានរកឃើញថាការផ្លាស់ទីម៉ាស៊ីនមេ 9p ពី QEMU ទៅខឺណែលនៅលើម៉ាស៊ីនមេនាំឱ្យដំណើរការ VirtFS កើនឡើងបីដង។

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

តើគោលគំនិតអ្វីខ្លះដែល FSs ក្នុងស្រុកអាចខ្ចីពីបណ្តាញ និងច្រាសមកវិញ?

សព្វថ្ងៃនេះ បណ្តាញ FSs ជាក្បួនមានកម្មវិធីបន្ថែមលើ FSs ក្នុងស្រុក ដូច្នេះខ្ញុំមិនយល់ច្បាស់ពីរបៀបដែលអ្នកអាចខ្ចីអ្វីមួយពីក្រោយនោះទេ។ ជាការប្រសើរណាស់, សូមពិចារណាក្រុមហ៊ុនមួយដែលមានបុគ្គលិក 4 នាក់ដែលមនុស្សគ្រប់គ្នាធ្វើរឿងផ្ទាល់ខ្លួនរបស់ពួកគេ: មួយចែកចាយ, ផ្ញើមួយផ្សេងទៀត, ទីបីទទួលបាន, ហាងទីបួន។ ហើយសំណួរថាតើក្រុមហ៊ុនអាចខ្ចីអ្វីពីបុគ្គលិករបស់ខ្លួនដែលរក្សាទុកវាហាក់ដូចជាមិនត្រឹមត្រូវ (វាមានរួចហើយនូវអ្វីដែលវាអាចខ្ចីពីគាត់ជាយូរមកហើយ) ។

ប៉ុន្តែ FSs ក្នុងស្រុកមានច្រើនដែលត្រូវរៀនពីបណ្តាញ។ ជាដំបូង អ្នកគួរតែរៀនពីពួកគេពីរបៀបប្រមូលផ្តុំបរិមាណឡូជីខលនៅកម្រិតខ្ពស់។ ឥឡូវនេះអ្វីដែលគេហៅថា ប្រព័ន្ធឯកសារមូលដ្ឋាន "កម្រិតខ្ពស់" ប្រមូលផ្តុំបរិមាណឡូជីខលទាំងស្រុងដោយប្រើបច្ចេកវិទ្យា "ឧបករណ៍និម្មិត" ដែលបានខ្ចីពី LVM (ការរំលោភលើស្រទាប់ឆ្លងដូចគ្នាដែលត្រូវបានអនុវត្តជាលើកដំបូងនៅក្នុង ZFS) ។ ម្យ៉ាងវិញទៀត ការបកប្រែអាសយដ្ឋាននិម្មិត (លេខប្លុក) ទៅជាលេខពិត និងត្រឡប់មកវិញកើតឡើងនៅកម្រិតទាប (ឧទាហរណ៍ បន្ទាប់ពីប្រព័ន្ធឯកសារបានចេញសំណើ I/O)។

សូមចំណាំថាការបន្ថែម និងការដកឧបករណ៍ទៅភាគឡូជីខល (មិនមែនកញ្ចក់) ដែលរៀបចំនៅលើស្រទាប់ប្លុកនាំឱ្យមានបញ្ហាដែលអ្នកផ្គត់ផ្គង់នៃ "លក្ខណៈពិសេស" បែបនេះស្ងាត់បន្តិចអំពី។ ខ្ញុំកំពុងនិយាយអំពីការបែងចែកនៅលើឧបករណ៍ពិត ដែលអាចឈានដល់តម្លៃដ៏អស្ចារ្យ ខណៈដែលនៅលើឧបករណ៍និម្មិត អ្វីគ្រប់យ៉ាងគឺល្អ។ ទោះជាយ៉ាងណាក៏ដោយ មានមនុស្សតិចណាស់ដែលចាប់អារម្មណ៍លើឧបករណ៍និម្មិត៖ អ្នកគ្រប់គ្នាចាប់អារម្មណ៍នឹងអ្វីដែលកំពុងកើតឡើងនៅលើឧបករណ៍ពិតរបស់អ្នក។ ប៉ុន្តែ FS ដូច ZFS (ក៏ដូចជា FS ណាមួយដែលភ្ជាប់ជាមួយ LVM) ដំណើរការតែជាមួយឧបករណ៍ឌីសនិម្មិត (បែងចែកអាសយដ្ឋានថាសនិម្មិតពីក្នុងចំណោមឧបករណ៍ឥតគិតថ្លៃ បន្លំឧបករណ៍និម្មិតទាំងនេះ។ល។)។ ហើយពួកគេមិនដឹងថាមានអ្វីកើតឡើងនៅលើឧបករណ៍ពិតទេ!

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

អ្វី​ដែល​អាក្រក់​បំផុត​នោះ​គឺ​អ្នក​មិន​អាច​កែ​ស្ថាន​ការ​នេះ​បាន! រឿងតែមួយគត់ដែលអ្នកអាចធ្វើបាននៅទីនេះគឺសួរប្រព័ន្ធឯកសារឱ្យ defragment ឧបករណ៍និម្មិត។ ប៉ុន្តែនាងនឹងប្រាប់អ្នកថាអ្វីគ្រប់យ៉ាងគឺអស្ចារ្យនៅទីនោះ - មានវិសាលភាពតែមួយគត់ ការបែកបាក់គឺសូន្យ ហើយវាមិនអាចប្រសើរជាងនេះបានទេ! ដូច្នេះ បរិមាណឡូជីខលដែលបានរៀបចំនៅកម្រិតប្លុកមិនមានបំណងសម្រាប់ការបន្ថែម/ការដកឧបករណ៍ម្តងហើយម្តងទៀតទេ។ តាមរបៀបដ៏ល្អ អ្នកគ្រាន់តែប្រមូលផ្តុំបរិមាណឡូជីខលនៅកម្រិតប្លុកម្តង ផ្តល់វាទៅប្រព័ន្ធឯកសារ ហើយបន្ទាប់មកមិនធ្វើអ្វីផ្សេងទៀតជាមួយវា។

លើសពីនេះទៀត ការរួមបញ្ចូលគ្នានៃប្រព័ន្ធរង FS+LVM ឯករាជ្យមិនអនុញ្ញាតឱ្យគិតគូរពីលក្ខណៈផ្សេងគ្នានៃដ្រាយដែលបរិមាណឡូជីខលត្រូវបានប្រមូលផ្តុំនោះទេ។ ជាការពិតណាស់ ឧបមាថាអ្នកបានប្រមូលផ្តុំបរិមាណឡូជីខលពីឧបករណ៍ HDD និងរឹង។ ប៉ុន្តែបន្ទាប់មកអតីតនឹងតម្រូវឱ្យមានការ defragmentation ហើយក្រោយមកទៀតនឹងមិន។ សម្រាប់ចុងក្រោយ អ្នកត្រូវចេញសំណើសុំបោះបង់ ប៉ុន្តែសម្រាប់អតីត មិនមែនជាដើម។ ទោះយ៉ាងណាក៏ដោយ នៅក្នុងការរួមបញ្ចូលគ្នានេះ វាពិតជាលំបាកណាស់ក្នុងការបង្ហាញពីការជ្រើសរើសបែបនេះ។

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

បញ្ហាមួយទៀតគឺរង់ចាំសម្រាប់អ្វីដែលគេហៅថា។ ប្រព័ន្ធឯកសារ "Write-Anywhere" (នេះក៏រួមបញ្ចូល Reiser4 ផងដែរ ប្រសិនបើអ្នកបញ្ជាក់គំរូប្រតិបត្តិការសមស្របកំឡុងពេលម៉ោន)។ ប្រព័ន្ធឯកសារបែបនេះត្រូវតែផ្តល់ឧបករណ៍ defragmentation ដែលមិនធ្លាប់មានពីមុនមកនៅក្នុងថាមពលរបស់វា។ ហើយ​អ្នក​គ្រប់​គ្រង​កម្រិត​សំឡេង​កម្រិត​ទាប​មិន​បាន​ជួយ​នៅ​ទី​នេះ​ទេ គ្រាន់​តែ​ចូល​ទៅ​ក្នុង​ផ្លូវ​ប៉ុណ្ណោះ។ ការពិតគឺថាជាមួយនឹងអ្នកគ្រប់គ្រងបែបនេះ FS របស់អ្នកនឹងរក្សាទុកផែនទីនៃប្លុកឥតគិតថ្លៃនៃឧបករណ៍តែមួយ - និម្មិតមួយ។ ដូច្នោះហើយ អ្នកអាច defragment បានតែឧបករណ៍និម្មិតប៉ុណ្ណោះ។ នេះមានន័យថាកម្មវិធី defragmenter របស់អ្នកនឹងធ្វើការបានយូរ និងយូរនៅលើចន្លោះតែមួយដ៏ធំនៃអាសយដ្ឋាននិម្មិត។

ហើយប្រសិនបើអ្នកមានអ្នកប្រើប្រាស់ច្រើនដែលធ្វើការសរសេរជាន់លើដោយចៃដន្យ នោះឥទ្ធិពលដ៏មានប្រយោជន៍នៃ defragmenter បែបនេះនឹងត្រូវកាត់បន្ថយមកត្រឹមសូន្យ។ ប្រព័ន្ធរបស់អ្នកនឹងចាប់ផ្តើមយឺតដោយជៀសមិនរួច ហើយអ្នកគ្រាន់តែបត់ដៃរបស់អ្នកនៅចំពោះមុខការវិនិច្ឆ័យដ៏ខកចិត្ត "ការរចនាខូច" ។ Defragmenters ជាច្រើនដែលដំណើរការលើទំហំអាសយដ្ឋានដូចគ្នានឹងរំខានដល់គ្នាទៅវិញទៅមកប៉ុណ្ណោះ។ វាជាបញ្ហាខុសគ្នាទាំងស្រុង ប្រសិនបើអ្នករក្សាផែនទីផ្ទាល់ខ្លួនរបស់អ្នកនៃប្លុកឥតគិតថ្លៃសម្រាប់ឧបករណ៍ពិតនីមួយៗ។ វា​នឹង​មាន​ប្រសិទ្ធភាព​ស្រប​គ្នា​នឹង​ដំណើរការ defragmentation។

ប៉ុន្តែនេះអាចត្រូវបានធ្វើបានលុះត្រាតែអ្នកមានកម្មវិធីគ្រប់គ្រងកម្រិតសំឡេងឡូជីខលកម្រិតខ្ពស់។ ប្រព័ន្ធឯកសារក្នុងស្រុកដែលមានអ្នកគ្រប់គ្រងបែបនេះមិនមានពីមុនទេ (យ៉ាងហោចណាស់ ខ្ញុំមិនដឹងអំពីពួកវាទេ)។ មានតែប្រព័ន្ធឯកសារបណ្តាញ (ឧទាហរណ៍ GlusterFS) ដែលមានអ្នកគ្រប់គ្រងបែបនេះ។ ឧទាហរណ៍សំខាន់មួយទៀតគឺ ការត្រួតពិនិត្យភាពត្រឹមត្រូវកម្រិតសំឡេង (fsck) ឧបករណ៍ប្រើប្រាស់។ ប្រសិនបើអ្នករក្សាទុកផែនទីឯករាជ្យរបស់អ្នកនៃប្លុកឥតគិតថ្លៃសម្រាប់ភាគរងនីមួយៗ នោះនីតិវិធីសម្រាប់ពិនិត្យមើលបរិមាណឡូជីខលអាចត្រូវបានប៉ារ៉ាឡែលប្រកបដោយប្រសិទ្ធភាព។ ម៉្យាងទៀត បរិមាណឡូជីខលជាមួយអ្នកគ្រប់គ្រងកម្រិតខ្ពស់ធ្វើមាត្រដ្ឋានកាន់តែប្រសើរ។

លើសពីនេះ ជាមួយនឹងអ្នកគ្រប់គ្រងកម្រិតសំឡេងទាប អ្នកនឹងមិនអាចរៀបចំរូបថតពេញលក្ខណៈបានទេ។ ជាមួយនឹងប្រព័ន្ធឯកសារដូច LVM និង ZFS អ្នកអាចថតរូបបានតែក្នុងមូលដ្ឋានប៉ុណ្ណោះ ប៉ុន្តែមិនមែនជារូបថតសកលទេ។ ការ​ថត​រូប​ក្នុង​តំបន់​អនុញ្ញាត​ឱ្យ​អ្នក​ត្រឡប់​មក​វិញ​ភ្លាមៗ​តែ​ប្រតិបត្តិការ​ឯកសារ​ធម្មតា​ប៉ុណ្ណោះ។ ហើយគ្មាននរណាម្នាក់នៅទីនោះនឹងវិលត្រឡប់មកវិញនូវប្រតិបត្តិការជាមួយនឹងភាគឡូជីខល (បន្ថែម/យកឧបករណ៍ចេញ)។ សូមក្រឡេកមើលរឿងនេះជាមួយឧទាហរណ៍មួយ។ នៅពេលណាមួយ នៅពេលដែលអ្នកមានបរិមាណឡូជីខលនៃឧបករណ៍ពីរ A និង B ដែលមានឯកសារ 100 អ្នកថតរូបប្រព័ន្ធ S ហើយបន្ទាប់មកបង្កើតឯកសាររាប់រយផ្សេងទៀត។

បន្ទាប់ពីនោះ អ្នកបន្ថែមឧបករណ៍ C ទៅក្នុងកម្រិតសំឡេងរបស់អ្នក ហើយចុងក្រោយធ្វើឱ្យប្រព័ន្ធរបស់អ្នកត្រលប់មកវិញដើម្បីថតរូប S. សំណួរ៖ តើមានឯកសារ និងឧបករណ៍ប៉ុន្មានដែលផ្ទុកបរិមាណឡូជីខលរបស់អ្នកបន្ទាប់ពីវិលត្រលប់ទៅ S? វានឹងមាន 100 ឯកសារ ដូចដែលអ្នកប្រហែលជាបានទាយ ប៉ុន្តែវានឹងមាន 3 ឧបករណ៍ - ទាំងនេះគឺជាឧបករណ៍ដូចគ្នា A, B និង C ទោះបីជានៅពេលរូបថតត្រូវបានបង្កើត មានតែឧបករណ៍ពីរនៅក្នុងប្រព័ន្ធ (A និង B ) ប្រតិបត្តិការបន្ថែមឧបករណ៍ C មិនបានវិលត្រឡប់មកវិញទេ ហើយប្រសិនបើអ្នកឥឡូវនេះយកឧបករណ៍ C ចេញពីកុំព្យូទ័រ វានឹងខូចទិន្នន័យរបស់អ្នក ដូច្នេះមុននឹងលុប អ្នកនឹងត្រូវអនុវត្តប្រតិបត្តិការថ្លៃៗជាមុនសិន ដើម្បីដកឧបករណ៍ចេញពីបរិមាណសមតុល្យឡូជីខលឡើងវិញ ដែល នឹងរាយប៉ាយទិន្នន័យទាំងអស់ពីឧបករណ៍ C ទៅឧបករណ៍ A និង B។ ប៉ុន្តែប្រសិនបើ FS របស់អ្នកគាំទ្រការថតរូបជាសកល ការធ្វើសមតុល្យឡើងវិញបែបនេះនឹងមិនត្រូវបានទាមទារទេ ហើយបន្ទាប់ពីរំកិលត្រឡប់ទៅកាន់ S ភ្លាមៗ អ្នកអាចដកឧបករណ៍ C ចេញពីកុំព្យូទ័រដោយសុវត្ថិភាព។

ដូច្នេះ ការថតរូបជាសកលគឺល្អ ព្រោះវាអនុញ្ញាតឱ្យអ្នកជៀសវាងការដកចេញ (បន្ថែម) ឧបករណ៍ដែលមានតម្លៃថ្លៃពីបរិមាណតក្កវិជ្ជា (ទៅទំហំឡូជីខល) ជាមួយនឹងទិន្នន័យច្រើន (ជាការពិតប្រសិនបើអ្នកចាំថា "រូបថត" ប្រព័ន្ធរបស់អ្នក នៅពេលត្រឹមត្រូវ) ។ ខ្ញុំ​សូម​រំលឹក​អ្នក​ថា​ការ​បង្កើត​រូបថត​និង​ការ​ត្រឡប់​ប្រព័ន្ធ​ឯកសារ​ទៅ​ពួកគេ​គឺ​ជា​ប្រតិបត្តិការ​ភ្លាមៗ។ សំណួរអាចកើតឡើង៖ តើវាអាចទៅរួចដោយរបៀបណាក្នុងការវិលត្រលប់មកវិញនូវប្រតិបត្តិការភ្លាមៗនៅលើបរិមាណឡូជីខលដែលបានចំណាយពេលបីថ្ងៃ? ប៉ុន្តែវាអាចទៅរួច! ផ្តល់ថាប្រព័ន្ធឯកសាររបស់អ្នកត្រូវបានរចនាឡើងយ៉ាងត្រឹមត្រូវ។ ខ្ញុំបានបង្កើតគំនិតនៃ "រូបថត 3D" បែបនេះកាលពីបីឆ្នាំមុន ហើយកាលពីឆ្នាំមុនខ្ញុំបានប៉ាតង់បច្ចេកទេសនេះ។

រឿងបន្ទាប់ដែល FSs ក្នុងស្រុកគួររៀនពីបណ្តាញនានាគឺរក្សាទុកទិន្នន័យមេតានៅលើឧបករណ៍ដាច់ដោយឡែកតាមរបៀបដែលបណ្តាញ FSs រក្សាទុកពួកវានៅលើម៉ាស៊ីនដាច់ដោយឡែក (គេហៅថាម៉ាស៊ីនមេទិន្នន័យមេតា)។ មានកម្មវិធីដែលដំណើរការជាចម្បងជាមួយទិន្នន័យមេតា ហើយកម្មវិធីទាំងនេះអាចត្រូវបានពន្លឿនយ៉ាងខ្លាំងដោយការដាក់ទិន្នន័យមេតានៅលើឧបករណ៍ផ្ទុកទិន្នន័យដែលមានតម្លៃថ្លៃ។ ជាមួយនឹងការរួមបញ្ចូលគ្នា FS+LVM អ្នកនឹងមិនអាចបង្ហាញជម្រើសបែបនេះបានទេ៖ LVM មិនដឹងថាមានអ្វីនៅលើប្លុកដែលអ្នកបានបញ្ជូនវា (ទិន្នន័យនៅទីនោះ ឬទិន្នន័យមេតា)។

អ្នកនឹងមិនទទួលបានអត្ថប្រយោជន៍ច្រើនពីការអនុវត្ត LVM កម្រិតទាបផ្ទាល់ខ្លួនរបស់អ្នកនៅក្នុង FS បើប្រៀបធៀបទៅនឹងការរួមបញ្ចូលគ្នានៃ FS+LVM ប៉ុន្តែអ្វីដែលអ្នកអាចធ្វើបានល្អណាស់គឺពង្រាយ FS ដូច្នេះនៅពេលក្រោយវាមិនអាចធ្វើការជាមួយកូដរបស់វាបានទេ។ ZFS និង Btrfs ដែលប្រញាប់ប្រញាល់ជាមួយឧបករណ៍និម្មិត សុទ្ធតែជាឧទាហរណ៍ច្បាស់លាស់អំពីរបៀបដែលការរំលោភលើស្រទាប់សម្លាប់ប្រព័ន្ធក្នុងន័យស្ថាបត្យកម្ម ដូច្នេះហេតុអ្វីបានជាខ្ញុំទាំងអស់នេះ? លើសពីនេះទៅទៀត មិនចាំបាច់បង្កើត LVM កម្រិតទាបរបស់អ្នកនៅក្នុងប្រព័ន្ធឯកសារនោះទេ។ ជំនួសមកវិញ អ្នកត្រូវប្រមូលផ្តុំឧបករណ៍ទៅក្នុងបរិមាណឡូជីខលក្នុងកម្រិតខ្ពស់មួយ ដូចដែលប្រព័ន្ធឯកសារបណ្តាញមួយចំនួនធ្វើជាមួយម៉ាស៊ីនផ្សេងៗគ្នា (ថ្នាំងផ្ទុក)។ ពិត ពួកគេធ្វើនេះគួរឱ្យស្អប់ខ្ពើមដោយសារតែការប្រើប្រាស់ក្បួនដោះស្រាយមិនល្អ។

ឧទាហរណ៍នៃក្បួនដោះស្រាយដ៏គួរឱ្យភ័យខ្លាចគឺអ្នកបកប្រែ DHT នៅក្នុងប្រព័ន្ធឯកសារ GlusterFS និងអ្វីដែលគេហៅថាផែនទី CRUSH នៅក្នុងប្រព័ន្ធឯកសារ Ceph ។ គ្មាន​ក្បួន​ដោះស្រាយ​ណា​មួយ​ដែល​ខ្ញុំ​បាន​ឃើញ​ធ្វើ​ឱ្យ​ខ្ញុំ​ពេញ​ចិត្ត​ក្នុង​លក្ខខណ្ឌ​នៃ​ភាព​សាមញ្ញ និង​ការ​ធ្វើ​មាត្រដ្ឋាន​ល្អ​នោះ​ទេ។ ដូច្នេះខ្ញុំត្រូវចងចាំពិជគណិត និងបង្កើតអ្វីៗគ្រប់យ៉ាងដោយខ្លួនឯង។ នៅក្នុងឆ្នាំ 2015 ខណៈពេលដែលកំពុងពិសោធជាមួយបណ្តុំលើមុខងារ hash ខ្ញុំបានបង្កើតឡើង និងធ្វើប៉ាតង់អ្វីមួយដែលសាកសមនឹងខ្ញុំ។ ឥឡូវនេះខ្ញុំអាចនិយាយបានថាការប៉ុនប៉ងដើម្បីអនុវត្តទាំងអស់នេះបានជោគជ័យ។ ខ្ញុំ​មិន​ឃើញ​មាន​បញ្ហា​ជាមួយ​នឹង​ការ​ធ្វើ​មាត្រដ្ឋាន​ក្នុង​វិធី​សាស្រ្ដ​ថ្មី​ទេ។

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

តើការផ្លាស់ប្តូរនៅក្នុងប្រព័ន្ធរងឧបករណ៍ប្លុកខឺណែល (ឧទាហរណ៍ រូបរាងនៃ blk-mq) ប៉ះពាល់ដល់តម្រូវការសម្រាប់ការអនុវត្ត FS យ៉ាងដូចម្តេច?

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

តើការលេចឡើងនៃប្រភេទមេឌៀថ្មី (ឧទាហរណ៍ SMR ឬភាពគ្រប់ទីកន្លែងនៃ SSDs) មានន័យថាជាបញ្ហាប្រឈមថ្មីជាមូលដ្ឋានសម្រាប់ការរចនាប្រព័ន្ធឯកសារមែនទេ?

បាទ។ ហើយទាំងនេះគឺជាការលើកទឹកចិត្តធម្មតាសម្រាប់ការអភិវឌ្ឍន៍ FS ។ បញ្ហាប្រឈមអាចខុសគ្នា និងមិនបានរំពឹងទុកទាំងស្រុង។ ជាឧទាហរណ៍ ខ្ញុំបានលឺពី drives ដែលល្បឿននៃប្រតិបត្តិការ I/O គឺពឹងផ្អែកយ៉ាងខ្លាំងទៅលើទំហំនៃទិន្នន័យមួយ និងអុហ្វសិតរបស់វា។ នៅក្នុងលីនុច ដែលទំហំនៃប្លុក FS មិនអាចលើសពីទំហំទំព័រនោះ ដ្រាយបែបនេះនឹងមិនបង្ហាញសមត្ថភាពពេញលេញរបស់វាតាមលំនាំដើមទេ។ ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើប្រព័ន្ធឯកសាររបស់អ្នកត្រូវបានរចនាឡើងយ៉ាងត្រឹមត្រូវ នោះមានឱកាសទទួលបានច្រើនពីវា។

តើមានមនុស្សប៉ុន្មាននាក់ដែលកំពុងធ្វើការជាមួយលេខកូដ Reiser4 ក្រៅពីអ្នក?

តិចជាងខ្ញុំចង់បាន ប៉ុន្តែខ្ញុំក៏មិនជួបប្រទះនឹងការខ្វះខាតធនធានធ្ងន់ធ្ងរដែរ។ ខ្ញុំពេញចិត្តនឹងល្បឿននៃការអភិវឌ្ឍន៍របស់ Reiser4 ច្រើនជាង។ ខ្ញុំនឹងមិន "បើកសេះ" ទេ - នេះមិនមែនជាតំបន់ត្រឹមត្រូវទេ។ នៅទីនេះ “បើអ្នកបើកកាន់តែស្ងៀម អ្នកនឹងបន្តទៅ!” ប្រព័ន្ធឯកសារទំនើបគឺជាប្រព័ន្ធរងខឺណែលដ៏ស្មុគស្មាញបំផុត ការសម្រេចចិត្តរចនាខុសដែលអាចមិនធ្វើវិញនូវការងារមនុស្សច្រើនឆ្នាំបន្តបន្ទាប់ទៀត។

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

តើ​មាន​ក្រុមហ៊ុន​ណា​បង្ហាញ​ឆន្ទៈ​ក្នុង​ការ​គាំទ្រ​ដល់​ការ​អភិវឌ្ឍ​របស់ Reiser4 ទេ?

បាទ មានសំណើបែបនេះ រួមទាំង។ និងពីអ្នកលក់ធំ។ ប៉ុន្តែសម្រាប់រឿងនេះ ខ្ញុំត្រូវផ្លាស់ទៅប្រទេសផ្សេង។ ជា​អកុសល ខ្ញុំ​មិន​មាន​អាយុ 30 ឆ្នាំ​ទៀត​ទេ ខ្ញុំ​មិន​អាច​បែក​ចេញ​ហើយ​ចាកចេញ​ដូច​នោះ​នៅ​ពេល​កញ្ចែ​ដំបូង។

តើលក្ខណៈពិសេសអ្វីខ្លះដែលបច្ចុប្បន្នបាត់ពី Reiser4?

មិនមានមុខងារ "ផ្លាស់ប្តូរទំហំ" សម្រាប់ភាគសាមញ្ញ ដែលស្រដៀងនឹងអ្វីដែលមាននៅក្នុង ReiserFS(v3) ទេ។ លើសពីនេះទៀត ប្រតិបត្តិការឯកសារជាមួយទង់ DIRECT_IO នឹងមិនឈឺចាប់ទេ។ បន្ទាប់ ខ្ញុំចង់អាចបំបែកភាគទៅជា "ភាគរងនៃន័យ" ដែលមិនមានទំហំថេរ ហើយដែលអាចត្រូវបានម៉ោនជាភាគឯករាជ្យ។ បញ្ហាទាំងនេះគឺល្អសម្រាប់អ្នកចាប់ផ្តើមដំបូងដែលចង់សាកល្បងដៃរបស់ពួកគេនៅ "រឿងពិត" ។

ហើយជាចុងក្រោយខ្ញុំចង់ឱ្យមានបរិមាណតក្កវិជ្ជាបណ្តាញជាមួយនឹងការអនុវត្ត និងការគ្រប់គ្រងសាមញ្ញ (ក្បួនដោះស្រាយទំនើបអនុញ្ញាតវារួចហើយ)។ ប៉ុន្តែអ្វីដែល Reiser4 ប្រាកដជាមិនដែលមានគឺ RAID-Z, scrubs, free space caches, 128-bit variables និងភាពមិនសមហេតុសមផលទីផ្សារផ្សេងទៀតដែលកើតឡើងប្រឆាំងនឹងផ្ទៃខាងក្រោយនៃកង្វះខាតនៃគំនិតក្នុងចំណោមអ្នកបង្កើតប្រព័ន្ធឯកសារមួយចំនួន។

តើ​អ្វី​គ្រប់​យ៉ាង​ដែល​អាច​ត្រូវ​ការ​អាច​ត្រូវ​បាន​អនុវត្ត​ដោយ​កម្មវិធី​ជំនួយ?

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

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

ដូច្នេះ ដោយ​មាន​ជំនួយ​ពី​កម្មវិធី​ជំនួយ និង​ពហុមុខងារ​ខ្ពស់​ជាង​នេះ អ្នក​អាច​ពណ៌នា​អំពី​លក្ខណៈ​ដែល​គេ​ស្គាល់ ព្រម​ទាំង​ "ទស្សន៍ទាយ" ដែល​មិន​ដែល​បាន​និយាយ​ផង។ ខ្ញុំ​មិន​ទាន់​អាច​បញ្ជាក់​យ៉ាង​តឹងរ៉ឹង​អំពី​រឿង​នេះ​បាន​ទេ ប៉ុន្តែ​ខ្ញុំ​ក៏​មិន​ទាន់​ដឹង​អំពី​ឧទាហរណ៍​ផ្ទុយ​នៅឡើយ​ដែរ។ ជាទូទៅ សំណួរនេះបានរំឭកខ្ញុំអំពី "កម្មវិធី Erlangen" របស់ Felix Klein ។ នៅពេលមួយគាត់បានព្យាយាមតំណាងឱ្យធរណីមាត្រទាំងអស់ជាសាខានៃពិជគណិត (ជាពិសេសទ្រឹស្តីក្រុម) ។

ឥឡូវនេះចំពោះសំណួរចម្បង - តើអ្វីៗនឹងទៅជាយ៉ាងណាជាមួយនឹងការផ្សព្វផ្សាយ Reiser4 ដល់ស្នូលសំខាន់? តើមានការបោះពុម្ពផ្សាយលើស្ថាបត្យកម្មនៃប្រព័ន្ធឯកសារនេះដែលអ្នកបាននិយាយនៅក្នុងបទសម្ភាសន៍ចុងក្រោយដែរឬទេ? តើ​សំណួរ​នេះ​ពាក់ព័ន្ធ​កម្រិតណា​តាម​ទស្សនៈ​របស់​អ្នក?

ជាទូទៅ យើងបានស្នើសុំដាក់បញ្ចូលក្នុងសាខាធំអស់រយៈពេលបីឆ្នាំមកហើយ។ ការអត្ថាធិប្បាយចុងក្រោយរបស់ Reiser នៅក្នុងសារជាសាធារណៈ ដែលសំណើទាញត្រូវបានធ្វើឡើងនៅតែមិនមានចម្លើយ។ ដូច្នេះ​សំណួរ​បន្ថែម​ទៀត​គឺ​មិនមែន​សម្រាប់​យើង​ទេ។ ខ្ញុំ​ផ្ទាល់​មិន​យល់​ថា​ហេតុ​អ្វី​បាន​ជា​យើង​ត្រូវ​ការ "បញ្ចូល​គ្នា" ទៅ​ក្នុង​ប្រព័ន្ធ​ប្រតិបត្តិការ​ជាក់លាក់​មួយ។ នៅលើលីនុច ពន្លឺមិនបញ្ចូលគ្នាដូចក្រូចឆ្មារទេ។ ដូច្នេះ មានឃ្លាំងដាច់ដោយឡែកមួយ ដែលវានឹងមានច្រកសាខាជាច្រើនសម្រាប់ OSes ផ្សេងៗគ្នា។ អ្នកណាដែលត្រូវការវាអាចក្លូនច្រកដែលត្រូវគ្នា ហើយធ្វើអ្វីដែលអ្នកចង់បានជាមួយវា (ជាការពិតណាស់នៅក្នុងអាជ្ញាប័ណ្ណ) ជាការប្រសើរណាស់ ប្រសិនបើនរណាម្នាក់មិនត្រូវការវា នោះមិនមែនជាបញ្ហារបស់ខ្ញុំទេ។ នៅចំណុចនេះខ្ញុំស្នើឱ្យពិចារណាសំណួរនៃ "ការផ្សព្វផ្សាយទៅក្នុងខឺណែលលីនុចចម្បង" ដូចដែលបានដោះស្រាយ។

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

តើមានអ្វីថ្មីនៅក្នុង Reiser4 ក្នុងរយៈពេលប៉ុន្មានឆ្នាំកន្លងមកនេះ?

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

ទីបំផុតយើងបានគ្រប់គ្រងដើម្បីអនុវត្តគំនិតដ៏យូរអង្វែងរបស់យើង - គំរូប្រតិបត្តិការផ្សេងៗគ្នា។ ពីមុន Reiser4 ដំណើរការតែម៉ូដែល Macdonald-Reiser ដែលមានកូដរឹងមួយប៉ុណ្ណោះ។ នេះបានបង្កើតបញ្ហារចនា។ ជាពិសេស ការថតរូបមិនអាចទៅរួចក្នុងគំរូប្រតិបត្តិការបែបនេះទេ - ពួកគេនឹងត្រូវខូចដោយសមាសធាតុអាតូមិកហៅថា "OVERWRITE SET"។ Reiser4 បច្ចុប្បន្នគាំទ្រគំរូប្រតិបត្តិការចំនួនបី។ នៅក្នុងមួយក្នុងចំណោមពួកគេ (សរសេរ - គ្រប់ទីកន្លែង) សមាសធាតុអាតូមិច OVERWRITE SET រួមបញ្ចូលតែទំព័រប្រព័ន្ធ (រូបភាពនៃផែនទីប៊ីតឌីស។

ដូច្នេះឥឡូវនេះ រូបភាពអាចត្រូវបានដឹងតាមវិធីល្អបំផុត។ នៅក្នុងគំរូប្រតិបត្តិការមួយផ្សេងទៀត ទំព័រដែលបានកែប្រែទាំងអស់ទៅតែលើ OVERWRITE SET (នោះគឺជាការសរសេរកំណត់ហេតុសុទ្ធសាធ)។ ម៉ូដែលនេះគឺសម្រាប់អ្នកដែលបានត្អូញត្អែរអំពីការបែកបាក់យ៉ាងឆាប់រហ័សនៃភាគថាស Reiser4 ។ ឥឡូវនេះនៅក្នុងគំរូនេះភាគថាសរបស់អ្នកនឹងបំបែកមិនលឿនជាងជាមួយ ReiserFS (v3) ទេ។ ម៉ូដែលដែលមានស្រាប់ទាំងបីជាមួយនឹងការកក់មួយចំនួនធានានូវអាតូមិកនៃប្រតិបត្តិការ ប៉ុន្តែម៉ូដែលដែលបាត់បង់អាតូមិច និងរក្សាបានតែភាពសុចរិតនៃផ្នែកក៏អាចមានប្រយោជន៍ផងដែរ។ ម៉ូដែលបែបនេះអាចមានប្រយោជន៍សម្រាប់កម្មវិធីគ្រប់ប្រភេទ (មូលដ្ឋានទិន្នន័យ។ល។) ដែលបានអនុវត្តមុខងារទាំងនេះមួយចំនួនរួចហើយ។ វាងាយស្រួលណាស់ក្នុងការបន្ថែមម៉ូដែលទាំងនេះទៅ Reiser4 ប៉ុន្តែខ្ញុំមិនបានធ្វើវាទេ ព្រោះគ្មាននរណាម្នាក់សួរខ្ញុំ ហើយខ្ញុំផ្ទាល់មិនត្រូវការវាទេ។

មូលប្បទានប័ត្រទិន្នន័យមេតាបានបង្ហាញខ្លួន ហើយថ្មីៗនេះខ្ញុំបានបំពេញបន្ថែមពួកវាជាមួយនឹងកញ្ចក់ "សេដ្ឋកិច្ច" (នៅតែមិនស្ថិតស្ថេរ)។ ប្រសិនបើ checksum នៃប្លុកណាមួយបរាជ័យ Reiser4 អានប្លុកដែលត្រូវគ្នាភ្លាមៗពីឧបករណ៍ចម្លង។ ចំណាំថា ZFS និង Btrfs មិនអាចធ្វើដូចនេះបានទេ៖ ការរចនាមិនអនុញ្ញាតទេ។ នៅទីនោះអ្នកត្រូវតែដំណើរការដំណើរការស្កេនផ្ទៃខាងក្រោយពិសេសដែលហៅថា "scrub" ហើយរង់ចាំឱ្យវាទៅដល់ប្លុកដែលមានបញ្ហា។ អ្នកសរសេរកម្មវិធីហៅព្រឹត្តិការណ៍បែបនេះក្នុងន័យធៀបថា "ឈើច្រត់"។

ហើយទីបំផុត បរិមាណឡូជីខលប្លែកៗបានបង្ហាញខ្លួន ដោយផ្តល់នូវអ្វីគ្រប់យ៉ាងដែល ZFS, Btrfs, ស្រទាប់ប្លុក ក៏ដូចជាការរួមបញ្ចូលគ្នា FS+LVM ជាគោលការណ៍មិនអាចផ្តល់បាន - ការធ្វើមាត្រដ្ឋានប៉ារ៉ាឡែល ឧបករណ៍បែងចែកអាសយដ្ឋានឌីស O(1) ការផ្លាស់ប្តូរទិន្នន័យតម្លាភាពរវាងភាគរង។ ក្រោយមកទៀតក៏មានចំណុចប្រទាក់អ្នកប្រើផងដែរ។ ឥឡូវនេះ អ្នកអាចផ្លាស់ទីទិន្នន័យក្តៅបំផុតទៅកាន់ដ្រាយដែលដំណើរការខ្ពស់បំផុតបានយ៉ាងងាយស្រួលនៅលើកម្រិតសំឡេងរបស់អ្នក។

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

រហូតមកដល់ពេលនេះខ្ញុំអាចអនុវត្តគំនិតរបស់ខ្ញុំបាន 10 ភាគរយ ទោះជាយ៉ាងណាក៏ដោយ ខ្ញុំបានទទួលជោគជ័យក្នុងអ្វីដែលខ្ញុំចាត់ទុកថាជារឿងពិបាកបំផុត - ការភ្ជាប់ភាគឡូជីខលជាមួយនឹងដំណើរការ flash ដែលអនុវត្តសកម្មភាពពន្យារទាំងអស់នៅក្នុង reiser4 ។ ទាំងអស់នេះនៅតែស្ថិតក្នុងសាខា "format41" ពិសោធន៍។

តើ Reiser4 ឆ្លងកាត់ xfstests ទេ?

យ៉ាងហោចណាស់វាបានធ្វើសម្រាប់ខ្ញុំនៅពេលដែលខ្ញុំកំពុងរៀបចំការចេញផ្សាយចុងក្រោយ។

តើវាអាចទៅរួចជាគោលការណ៍ដើម្បីធ្វើឱ្យ Reiser4 ជាបណ្តាញ (ចង្កោម) FS ដោយប្រើកម្មវិធីជំនួយទេ?

វាអាចទៅរួច និងសូម្បីតែចាំបាច់! ប្រសិនបើអ្នកបង្កើតឯកសារបណ្តាញដោយផ្អែកលើប្រព័ន្ធឯកសារមូលដ្ឋានដែលបានរចនាយ៉ាងត្រឹមត្រូវ លទ្ធផលនឹងគួរឱ្យចាប់អារម្មណ៍ខ្លាំងណាស់! នៅក្នុងបណ្តាញទំនើប FSs ខ្ញុំមិនពេញចិត្តនឹងវត្តមាននៃកម្រិតផ្ទុក backend ដែលត្រូវបានអនុវត្តដោយប្រើ FS មូលដ្ឋានណាមួយឡើយ។ អត្ថិភាពនៃកម្រិតនេះគឺមិនសមហេតុផលទាំងស្រុង។ បណ្តាញ FS ត្រូវតែធ្វើអន្តរកម្មដោយផ្ទាល់ជាមួយស្រទាប់ប្លុក ហើយមិនត្រូវសុំឱ្យ FS មូលដ្ឋានបង្កើតឯកសារសេវាកម្មផ្សេងទៀតណាមួយឡើយ!

ជាទូទៅ ការបែងចែកប្រព័ន្ធឯកសារទៅក្នុងមូលដ្ឋាន និងបណ្តាញគឺមកពីអំពើអាក្រក់។ វាកើតឡើងពីភាពមិនល្អឥតខ្ចោះនៃក្បួនដោះស្រាយដែលត្រូវបានប្រើកាលពីសាមសិបឆ្នាំមុន ហើយជំនួសមកវិញនូវអ្វីដែលមិនទាន់ត្រូវបានស្នើឡើង។ នេះក៏ជាហេតុផលសម្រាប់ការលេចចេញនូវសមាសធាតុសូហ្វវែរដែលមិនចាំបាច់ (សេវាកម្មផ្សេងៗ។ តាមរបៀបដ៏ល្អ វាគួរតែមានតែមួយ FS ក្នុងទម្រង់នៃម៉ូឌុលខឺណែល និងសំណុំឧបករណ៍ប្រើប្រាស់របស់អ្នកប្រើប្រាស់ដែលបានដំឡើងនៅលើម៉ាស៊ីននីមួយៗ - ថ្នាំងចង្កោម។ FS នេះគឺទាំងក្នុងស្រុក និងបណ្តាញ។ ហើយគ្មានអ្វីទៀតទេ!

ប្រសិនបើជាមួយ Reiser4 ក្នុង Linuxប្រសិនបើគ្មានអ្វីកើតឡើងទេ ខ្ញុំចង់ស្នើឱ្យមាន FS សម្រាប់ FreeBSD (ដកស្រង់ចេញពីបទសម្ភាសន៍មុន៖ "...FreeBSD ... មានឫសគល់សិក្សា ... ហើយនេះមានន័យថាជាមួយនឹងប្រូបាប៊ីលីតេខ្ពស់យើងនឹងរកឃើញភាសារួមជាមួយអ្នកអភិវឌ្ឍន៍")?

ដូច្នេះ ដូចដែលយើងទើបតែបានរកឃើញ អ្វីគ្រប់យ៉ាងបានដំណើរការយ៉ាងល្អឥតខ្ចោះជាមួយលីនុចរួចហើយ៖ មានច្រក Reiser4 ដាច់ដោយឡែកសម្រាប់វាក្នុងទម្រង់ជាសាខាមេនៃឃ្លាំងរបស់យើង។ ខ្ញុំមិនភ្លេចអំពី FreeBSD ទេ! ផ្តល់ជូន! ខ្ញុំត្រៀមខ្លួនជាស្រេចដើម្បីធ្វើការយ៉ាងជិតស្និទ្ធជាមួយអ្នកដែលដឹងពីផ្នែកខាងក្នុងនៃ FreeBSD យ៉ាងច្បាស់។ និយាយអីញ្ចឹង៖ អ្វីដែលខ្ញុំពិតជាចូលចិត្តអំពីសហគមន៍របស់ពួកគេគឺថាការសម្រេចចិត្តនៅទីនោះត្រូវបានធ្វើឡើងដោយក្រុមប្រឹក្សាថ្មីនៃអ្នកជំនាញឯករាជ្យ ដែលមិនពាក់ព័ន្ធនឹងការបោកប្រាស់របស់រដ្ឋាភិបាលទៅលើបុគ្គលអចិន្ត្រៃយ៍ម្នាក់នោះទេ។

តើអ្នកវាយតម្លៃសហគមន៍អ្នកប្រើប្រាស់យ៉ាងដូចម្តេច? Linux ថ្ងៃនេះ? តើវាបានក្លាយជា "ពេញនិយម" ជាងមុនទេ?

ដោយគិតពីលក្ខណៈនៃការងាររបស់ខ្ញុំ វាពិតជាពិបាកសម្រាប់ខ្ញុំក្នុងការវាយតម្លៃរឿងនេះ។ អ្នកប្រើប្រាស់ភាគច្រើនមករកខ្ញុំជាមួយនឹងរបាយការណ៍កំហុស និងសំណើដើម្បីជួសជុលផ្នែក។ អ្នកប្រើប្រាស់ជាអ្នកប្រើប្រាស់។ ខ្លះ​យល់​ច្រើន ខ្លះ​តិច។ មនុស្សគ្រប់រូបត្រូវបានព្យាបាលដូចគ្នា។ ជាការប្រសើរណាស់ ប្រសិនបើអ្នកប្រើមិនអើពើនឹងការណែនាំរបស់ខ្ញុំ សូមអភ័យទោស៖ ការបញ្ជាទិញមិនអើពើនឹងបញ្ចូលនៅលើផ្នែករបស់ខ្ញុំផងដែរ។

តើវាអាចទៅរួចទេក្នុងការទស្សន៍ទាយការអភិវឌ្ឍន៍ប្រព័ន្ធឯកសារសម្រាប់រយៈពេលប្រាំទៅដប់ឆ្នាំខាងមុខ? តើអ្នកគិតថាអ្វីជាបញ្ហាប្រឈមចម្បងដែលអ្នកអភិវឌ្ឍន៍ FS អាចប្រឈមមុខ?

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

បំណះនីមួយៗធ្វើឱ្យបញ្ហារបស់វាកាន់តែធ្ងន់ធ្ងរ។ អញ្ចឹង។ ហើយតែងតែមាន “អ្នកផ្សាយដំណឹងល្អ” ជាច្រើនប្រភេទ ដែល “អ្វីៗដំណើរការបាន”។ ជាទូទៅ ទាំងនេះគឺជាសិស្សសាលា និងសិស្សដែលរំលងការបង្រៀន។ គ្រាន់តែស្រមៃ៖ វាដំណើរការសម្រាប់គាត់ ប៉ុន្តែសាស្រ្តាចារ្យមិនធ្វើទេ។ នេះ​ជា​ការ​ប្រញាប់​ប្រញាល់​របស់ Adrenaline! តាមទស្សនៈរបស់ខ្ញុំ គ្រោះថ្នាក់ដ៏ធំបំផុតគឺបណ្តាលមកពី "សិប្បករ" ដែលបានប្រញាប់ប្រញាល់ "វីស" នូវលក្ខណៈពិសេសដ៏អស្ចារ្យរបស់ Btrfs ទៅលើស្រទាប់គ្រប់ប្រភេទដូចជា systemd, docker ជាដើម។ - វាប្រហាក់ប្រហែលនឹង metastases រួចហើយ។

ឥឡូវ​នេះ​យើង​ព្យាយាម​ធ្វើ​ការ​ព្យាករ​ពី​ប្រាំ​ទៅ​ដប់​ឆ្នាំ។ ខ្ញុំបានរាយបញ្ជីយ៉ាងខ្លីរួចហើយនូវអ្វីដែលយើងនឹងធ្វើនៅក្នុង Reiser4។ បញ្ហាប្រឈមចម្បងសម្រាប់អ្នកអភិវឌ្ឍន៍ FS ក្នុងស្រុកចាប់ពីទឹកឡើងនឹងមាន (បាទ វាបានក្លាយជា) អសមត្ថភាពក្នុងការធ្វើការងារសមរម្យសម្រាប់ប្រាក់ខែ។ បើគ្មានគំនិតណាមួយក្នុងវិស័យផ្ទុកទិន្នន័យទេ ពួកគេនឹងបន្តព្យាយាមបិទភ្ជាប់ VFS, XFS និង ext4 អកុសលទាំងនេះ។ ស្ថានភាពជាមួយ VFS មើលទៅគួរឱ្យអស់សំណើចជាពិសេសប្រឆាំងនឹងផ្ទៃខាងក្រោយនេះ ដោយនឹកឃើញដល់ការធ្វើឱ្យទាន់សម័យដ៏គួរឱ្យរំភើបនៃភោជនីយដ្ឋានដែលមិនមានមេចុងភៅ ហើយគ្មានមេចុងភៅត្រូវបានគេរំពឹងទុកនោះទេ។

ឥឡូវនេះ កូដ VFS ចាក់សោទំព័រអង្គចងចាំច្រើនក្នុងពេលតែមួយដោយគ្មានលក្ខខណ្ឌ ហើយស្នើសុំប្រព័ន្ធឯកសារមូលដ្ឋានឱ្យដំណើរការលើពួកវា។ នេះត្រូវបានណែនាំដើម្បីកែលម្អដំណើរការរបស់ Ext4 ក្នុងអំឡុងពេលប្រតិបត្តិការលុប ប៉ុន្តែដូចដែលអ្នកអាចយល់បានយ៉ាងងាយស្រួល ការចាក់សោក្នុងពេលដំណាលគ្នាបែបនេះគឺមិនឆបគ្នាទាំងស្រុងជាមួយនឹងគំរូប្រតិបត្តិការកម្រិតខ្ពស់។ នេះមានន័យថាអ្នកមិនអាចបន្ថែមការគាំទ្រសម្រាប់ប្រព័ន្ធឯកសារឆ្លាតវៃមួយចំនួនទៅខឺណែលបានទេ។ ខ្ញុំមិនដឹងថាអ្វីៗនៅក្នុងតំបន់ផ្សេងទៀតយ៉ាងម៉េចទេ។ Linuxប៉ុន្តែនៅពេលនិយាយអំពីប្រព័ន្ធឯកសារ ការអភិវឌ្ឍណាមួយនៅទីនេះស្ទើរតែមិនឆបគ្នាជាមួយគោលនយោបាយដែល Torvalds កំពុងអនុវត្តនោះទេ (គម្រោងសិក្សាត្រូវបានបណ្តេញចេញ ហើយអ្នកបោកប្រាស់ដែលមិនដឹងថាដើមឈើ B ជាអ្វីត្រូវបានផ្តល់កិត្តិយសគ្មានទីបញ្ចប់)។ ដូច្នេះ ដំណើរនៃការពុកផុយយឺតត្រូវបានកំណត់។ ជាការពិតណាស់ ពួកគេនឹងព្យាយាមឱ្យអស់ពីសមត្ថភាពដើម្បីបញ្ជូនរឿងនេះទៅជា "ការអភិវឌ្ឍ"។

លើសពីនេះទៀត "អ្នកថែរក្សា" នៃប្រព័ន្ធឯកសារដោយដឹងថាអ្នកនឹងមិនរកបានច្រើនពី "ការផ្ទុក" តែម្នាក់ឯងនឹងព្យាយាមដៃរបស់ពួកគេក្នុងអាជីវកម្មដែលរកប្រាក់ចំណេញកាន់តែច្រើន។ ទាំងនេះជាក្បួនប្រព័ន្ធឯកសារចែកចាយ និងនិម្មិត។ ប្រហែល​ជា​ពួក​គេ​នឹង​បញ្ជូន ZFS ម៉ូដ​ទៅ​កន្លែង​ផ្សេង​ទៀត​ដែល​វា​មិន​ទាន់​មាន។ ប៉ុន្តែវាដូចជា FS ទាំងអស់ពីដើមទឹក ប្រហាក់ប្រហែលនឹងដើមឈើឆ្នាំថ្មី៖ ប្រសិនបើអ្នកអាចព្យួររបស់តូចៗផ្សេងទៀតនៅលើកំពូល នោះអ្នកមិនអាចចូលជ្រៅជាងនេះបានទេ។ ខ្ញុំទទួលស្គាល់ថាអាចបង្កើតប្រព័ន្ធសហគ្រាសដ៏ធ្ងន់ធ្ងរដោយផ្អែកលើ ZFS ប៉ុន្តែដោយសារឥឡូវនេះយើងកំពុងពិភាក្សាអំពីអនាគត ខ្ញុំគ្រាន់តែអាចបញ្ជាក់ដោយសោកសៅថា ZFS មិនមានសង្ឃឹមក្នុងរឿងនេះ៖ ជាមួយនឹងឧបករណ៍និម្មិតរបស់ពួកគេ បុរសបានកាត់ផ្តាច់អុកស៊ីសែន។ សម្រាប់ខ្លួន និងកូនចៅជំនាន់ក្រោយ ដើម្បីអភិវឌ្ឍបន្ថែមទៀត។ ZFS គឺជារឿងអតីតកាល។ ហើយ ext4 និង XFS គឺមិនមែនសូម្បីតែមួយថ្ងៃមុនកាលពីម្សិលមិញ។

វាគួរឱ្យកត់សម្គាល់ដោយឡែកពីគ្នាអំពីគោលគំនិតដែលត្រូវបានគេនិយាយច្រើនអំពី "Linux ប្រព័ន្ធឯកសាររបស់មនុស្សជំនាន់ក្រោយ។" នេះគឺជាគម្រោងនយោបាយ និងទីផ្សារទាំងស្រុង ដែលត្រូវបានបង្កើតឡើងដើម្បីអាចនិយាយបានថា "កំណត់អនាគតនៃប្រព័ន្ធឯកសារ" Linux សម្រាប់តួអង្គជាក់លាក់។ រឿងគឺថា វាធ្លាប់ជា Linux វាធ្លាប់តែជា "សម្រាប់ការសប្បាយ"។ ឥឡូវនេះ វាជាម៉ាស៊ីនរកលុយជាចម្បង។ លុយរកបានពីអ្វីៗគ្រប់យ៉ាង។ ឧទាហរណ៍ ការបង្កើតផលិតផលសូហ្វវែរល្អគឺពិបាកណាស់ ប៉ុន្តែ "អ្នកអភិវឌ្ឍន៍" ឆ្លាតវៃបានដឹងជាយូរមកហើយថាមិនចាំបាច់ប្រឹងប្រែងអ្វីទាំងអស់៖ សូម្បីតែសូហ្វវែរដែលមិនមាន ដែលត្រូវបានប្រកាស និងផ្សព្វផ្សាយនៅក្នុងព្រឹត្តិការណ៍សាធារណៈគ្រប់ប្រភេទ ក៏អាចលក់បានដោយជោគជ័យដែរ - រឿងសំខាន់គឺត្រូវមានមុខងារជាច្រើននៅលើស្លាយបទបង្ហាញ។

ប្រព័ន្ធឯកសារគឺល្អឥតខ្ចោះសម្រាប់ការនេះ ពីព្រោះអ្នកអាចចរចាដោយសុវត្ថិភាពរយៈពេលដប់ឆ្នាំលើលទ្ធផល។ ជាការប្រសើរណាស់, ប្រសិនបើនរណាម្នាក់នៅពេលក្រោយត្អូញត្អែរអំពីការខ្វះខាតនៃលទ្ធផលនេះ នោះគាត់គ្រាន់តែមិនយល់អ្វីទាំងអស់អំពីប្រព័ន្ធឯកសារ! នេះគឺជាការនឹកឃើញពីសាជីជ្រុងហិរញ្ញវត្ថុ៖ នៅផ្នែកខាងលើគឺជាអ្នកផ្សងព្រេងដែលបានចាប់ផ្តើមភាពរញ៉េរញ៉ៃនេះ ហើយមនុស្សមួយចំនួនតូចដែលមាន "សំណាង"៖ ពួកគេ "ដកភាគលាភ" ពោលគឺឧ។ បានទទួលប្រាក់សម្រាប់ការអភិវឌ្ឍន៍ ទទួលបានការងារដែលមានប្រាក់ខែល្អជាអ្នកគ្រប់គ្រង "បង្ហាញខ្លួន" នៅក្នុងសន្និសីទ។ល។

មកបន្ទាប់អ្នកដែល "សំណាង"៖ ពួកគេនឹងរាប់ការខាតបង់ ដោះស្រាយជាមួយនឹងផលវិបាកនៃការដាក់ពង្រាយផលិតផលសូហ្វវែរដែលមិនអាចប្រើបានទៅក្នុងផលិតកម្ម "ល។ មានពួកគេជាច្រើនទៀត។ ជាការប្រសើរណាស់, នៅមូលដ្ឋាននៃសាជីជ្រុងមានអ្នកអភិវឌ្ឍន៍ដ៏ធំមួយ " sawing" កូដគ្មានប្រយោជន៍។ ពួកគេគឺជាអ្នកចាញ់ដ៏ធំបំផុត ពីព្រោះពេលវេលាដែលខ្ជះខ្ជាយមិនអាចត្រឡប់មកវិញបានទេ។ ពីរ៉ាមីតបែបនេះមានអត្ថប្រយោជន៍យ៉ាងខ្លាំងចំពោះ Torvalds និងសហការីរបស់គាត់។ ហើយពីរ៉ាមីតទាំងនេះកាន់តែច្រើន កាន់តែល្អសម្រាប់ពួកគេ។ ដើម្បីចិញ្ចឹមពីរ៉ាមីតបែបនេះ អ្វីៗអាចយកទៅធ្វើជាស្នូលបាន។ ជាការពិតណាស់ នៅទីសាធារណៈ ពួកគេនិយាយផ្ទុយពីនេះ។ ប៉ុន្តែ​ខ្ញុំ​មិន​វិនិច្ឆ័យ​ដោយ​ពាក្យ​សម្ដី​ទេ តែ​ដោយ​ទង្វើ។

ដូច្នេះ "អនាគតនៃប្រព័ន្ធឯកសារ Linux" គឺជាកម្មវិធីមួយផ្សេងទៀតដែលមានការផ្សព្វផ្សាយខ្ពស់ ប៉ុន្តែមិនសូវអាចប្រើប្រាស់បាន។ បន្ទាប់ពី Btrfs វាទំនងជាខ្ពស់ដែល "អនាគត" នេះនឹងត្រូវបានជំនួសដោយ Bcachefs ដែលជាការប៉ុនប៉ងមួយផ្សេងទៀតដើម្បីបង្កាត់ពូជ។ Linux ស្រទាប់ប្លុកដែលមានប្រព័ន្ធឯកសារ (ឧទាហរណ៍មិនល្អអាចឆ្លងបាន)។ ហើយអ្វីដែលគួរឱ្យចាប់អារម្មណ៍នោះគឺថាវាមានបញ្ហាដូចគ្នានឹង Btrfs ដែរ។ ខ្ញុំសង្ស័យរឿងនេះអស់រយៈពេលយូរ ហើយបន្ទាប់មកខ្ញុំមិនអាចទប់ទល់នឹងការមើលកូដបានទេ—ហើយវាជាការពិត!

អ្នកនិពន្ធនៃ Bcachefs និង Btrfs នៅពេលបង្កើត FS របស់ពួកគេបានប្រើប្រាស់ប្រភពរបស់អ្នកដទៃយ៉ាងសកម្ម ដោយយល់តិចតួចអំពីពួកគេ។ ស្ថានភាពគឺនឹកឃើញដល់ហ្គេមរបស់កុមារ "ទូរស័ព្ទខូច" ។ ហើយ​ខ្ញុំ​អាច​ស្រមៃ​មើល​ថា​តើ​កូដ​នេះ​នឹង​ត្រូវ​បាន​បញ្ចូល​ក្នុង​ខឺណែល​ដោយ​របៀប​ណា។ តាមពិតគ្មាននរណាម្នាក់នឹងឃើញ "តុងរួច" ទេ (មនុស្សគ្រប់គ្នានឹងដើរលើពួកគេនៅពេលក្រោយ) ។ បន្ទាប់ពីមានសំណួរជាច្រើនអំពីរចនាប័ទ្មនៃកូដ ការចោទប្រកាន់លើការបំពានដែលមិនមាន។ បន្ទាប់មកត្រូវបានលក់ទៅឱ្យសាជីវកម្ម។

លទ្ធផលចុងក្រោយនឹងមិនចាប់អារម្មណ៍នរណាម្នាក់ឡើយ។ កាលពី 20 ឆ្នាំមុន ប្រហែលជាខ្ញុំចាប់អារម្មណ៍ ប៉ុន្តែឥឡូវនេះ សំណួរត្រូវបានចោទឡើងខុសគ្នា៖ តើវាអាចទៅរួចទេក្នុងការផ្សព្វផ្សាយនេះ ដូច្នេះមនុស្សមួយចំនួននឹងត្រូវបានជួលក្នុងរយៈពេលដប់ឆ្នាំខាងមុខ។ ហើយ alas វាមិនមែនជាទម្លាប់ក្នុងការងឿងឆ្ងល់អំពីលទ្ធផលចុងក្រោយនោះទេ។

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

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

យើងបង្កើតក្បួនដោះស្រាយទាំងអស់ដោយខ្លួនឯង។ បច្ចុប្បន្ននេះ ខ្ញុំចាប់អារម្មណ៍លើទិដ្ឋភាពពិជគណិត និងការរួមបញ្ចូលគ្នានៃវិទ្យាសាស្ត្រផ្ទុកទិន្នន័យ។ ជាពិសេស វាលកំណត់ អស៊ីមតូទិក និងវិសមភាព។ មានការងារសម្រាប់អ្នកសរសេរកម្មវិធីធម្មតាផងដែរ ប៉ុន្តែខ្ញុំត្រូវតែព្រមានអ្នកភ្លាមៗ៖ ការណែនាំទាំងអស់ដើម្បី "មើលប្រព័ន្ធឯកសារផ្សេងទៀត ហើយធ្វើដូចគ្នា" នឹងត្រូវបានមិនអើពើ។ បំណះដែលមានគោលបំណងធ្វើសមាហរណកម្មកាន់តែជិតស្និទ្ធជាមួយ Linux តាមរយៈខ្សែ VFS។

ដូច្នេះ យើងមិនមានតុងរួចទេ ប៉ុន្តែយើងមានការយល់ដឹងអំពីកន្លែងដែលយើងត្រូវផ្លាស់ទី ហើយយើងមានទំនុកចិត្តថាទិសដៅនេះគឺត្រឹមត្រូវ។ ការ​យល់​ដឹង​នេះ​មិន​បាន​មក​ក្នុង​ទម្រង់​នៃ​ម៉ាណា​មក​ពី​ស្ថានសួគ៌​ទេ។ ខ្ញុំសូមរំលឹកអ្នកថា យើងមានបទពិសោធន៍អភិវឌ្ឍន៍ 29 ឆ្នាំនៅពីក្រោយយើង ប្រព័ន្ធឯកសារពីរដែលសរសេរពីដំបូង។ និងចំនួនដូចគ្នានៃឧបករណ៍សង្គ្រោះទិន្នន័យ។ ហើយនេះគឺច្រើនណាស់!

ប្រភព: opennet.ru