សម័យបុរេប្រវត្តិសាស្ត្រ

មានម៉ាស៊ីនលក់នៃការរចនាផ្ទាល់ខ្លួនរបស់យើង។ នៅខាងក្នុង Raspberry Pi និងខ្សែភ្លើងមួយចំនួននៅលើក្តារដាច់ដោយឡែក។ អ្នកទទួលកាក់ អ្នកទទួលវិក្កយបត្រ ស្ថានីយធនាគារត្រូវបានភ្ជាប់... អ្វីគ្រប់យ៉ាងត្រូវបានគ្រប់គ្រងដោយកម្មវិធីដែលសរសេរដោយខ្លួនឯង។ ប្រវត្តិការងារទាំងមូលត្រូវបានសរសេរទៅកំណត់ហេតុនៅលើដ្រាយវ៍ពន្លឺ (MicroSD) ដែលបន្ទាប់មកត្រូវបានបញ្ជូនតាមអ៊ីនធឺណិត (ដោយប្រើម៉ូដឹម USB) ទៅកាន់ម៉ាស៊ីនមេ ដែលវាត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យ។ ព័ត៌មានលក់ត្រូវបានផ្ទុកទៅក្នុង 1c ក៏មានចំណុចប្រទាក់បណ្ដាញសាមញ្ញសម្រាប់ការត្រួតពិនិត្យជាដើម។

នោះគឺទិនានុប្បវត្តិមានសារៈសំខាន់ណាស់ - សម្រាប់គណនេយ្យ (ប្រាក់ចំណូលការលក់។ នេះ​អាច​និយាយ​បាន​ថា​ជា​ព័ត៌មាន​ទាំងអស់​ដែល​យើង​មាន​អំពី​ម៉ាស៊ីន​នេះ។

បញ្ហា

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

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

សូមប្រយ័ត្ន! អានយូរហើយ! ប្រសិនបើអ្នកមិនចាប់អារម្មណ៍លើ "ហេតុអ្វី" ប៉ុន្តែមានតែ "របៀប" អ្នកអាចទៅត្រង់ នៅ​ចុងបញ្ចប់ អត្ថបទ

ការសម្រេចចិត្ត

រឿងដំបូងដែលគិតគឺ៖ បោះបង់ចោល MicroSD ដំឡើងឧទាហរណ៍ SSD ហើយចាប់ផ្ដើមពីវា។ តាមទ្រឹស្តីអាចធ្វើទៅបាន ប្រហែលជា ប៉ុន្តែមានតម្លៃថ្លៃ ហើយមិនគួរឱ្យទុកចិត្តខ្លាំង (អាដាប់ទ័រ USB-SATA ត្រូវបានបន្ថែម ស្ថិតិបរាជ័យសម្រាប់ SSDs ថវិកាក៏មិនលើកទឹកចិត្តដែរ)។

USB HDD ក៏មិនមើលទៅដូចជាដំណោះស្រាយទាក់ទាញពិសេសដែរ។

ដូច្នេះហើយ យើងបានមករកជម្រើសនេះ៖ ទុកការចាប់ផ្ដើមពី MicroSD ប៉ុន្តែប្រើវាក្នុងរបៀបបានតែអាន ហើយរក្សាទុកកំណត់ហេតុប្រតិបត្តិការ (និងព័ត៌មានផ្សេងទៀតសម្រាប់ផ្នែករឹងជាក់លាក់មួយ - លេខស៊េរី ការក្រិតឧបករណ៍ចាប់សញ្ញា។ល។) នៅកន្លែងផ្សេង។ .

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

ផ្នែករឹង

មិនមានការសង្ស័យជាពិសេសអំពីជម្រើសនៃប្រភេទអង្គចងចាំនោះទេ - NOR Flash ។
អាគុយម៉ង់៖

• ការតភ្ជាប់សាមញ្ញ (ភាគច្រើនជាញឹកញាប់រថយន្តក្រុង SPI ដែលអ្នកមានបទពិសោធន៍ប្រើប្រាស់រួចហើយ ដូច្នេះគ្មានបញ្ហាផ្នែករឹងត្រូវបានមើលឃើញទុកជាមុន);
• តម្លៃគួរឱ្យអស់សំណើច;
• ពិធីការប្រតិបត្តិការស្តង់ដារ (ការអនុវត្តមានរួចហើយនៅក្នុងខឺណែលលីនុច ប្រសិនបើអ្នកប្រាថ្នា អ្នកអាចយកភាគីទីបីដែលមានវត្តមាន ឬសូម្បីតែសរសេរដោយខ្លួនឯង សំណាងល្អអ្វីគ្រប់យ៉ាងគឺសាមញ្ញ);
• ភាពជឿជាក់ និងធនធាន៖
  ពីសន្លឹកទិន្នន័យធម្មតា៖ ទិន្នន័យត្រូវបានរក្សាទុករយៈពេល 20 ឆ្នាំ 100000 វដ្តនៃការលុបសម្រាប់ប្លុកនីមួយៗ។
  ពីប្រភពភាគីទីបី៖ BER ទាបបំផុត ប្រកាសថាមិនត្រូវការលេខកូដកែកំហុសទេ។ (ការងារខ្លះចាត់ទុក ECC សម្រាប់ NOR ប៉ុន្តែជាធម្មតាវានៅតែមានន័យថា MLC NOR វាកើតឡើងផងដែរ).

ចូរយើងប៉ាន់ស្មានតម្រូវការសម្រាប់បរិមាណ និងធនធាន។

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

បច្ចុប្បន្ននេះយើងប្រមូលបានប្រហែល 100kb នៃកំណត់ហេតុក្នុងមួយថ្ងៃ (3-4 ពាន់ធាតុ) ប៉ុន្តែបន្តិចម្តងតួលេខនេះកំពុងកើនឡើង - ព័ត៌មានលម្អិតកំពុងកើនឡើង ព្រឹត្តិការណ៍ថ្មីៗកំពុងត្រូវបានបន្ថែម។ លើសពីនេះ ជួនកាលមានការផ្ទុះឡើង (ឧទាហរណ៍ឧបករណ៍ចាប់សញ្ញាខ្លះចាប់ផ្តើមផ្ញើសារឥតបានការជាមួយនឹងភាពវិជ្ជមានមិនពិត)។ យើងនឹងគណនាសម្រាប់ 10 ពាន់កំណត់ត្រា 100 បៃនីមួយៗ - មេកាបៃក្នុងមួយថ្ងៃ។

សរុបមក ទិន្នន័យស្អាត (បង្ហាប់ល្អ) 5MB ចេញមក។ បន្ថែមទៀតដល់ពួកគេ។ (ការប៉ាន់ប្រមាណ) 1MB នៃទិន្នន័យសេវាកម្ម។

នោះគឺយើងត្រូវការបន្ទះឈីប 8MB ប្រសិនបើយើងមិនប្រើការបង្ហាប់ ឬ 4MB ប្រសិនបើយើងប្រើវា។ តួលេខជាក់ស្តែងសម្រាប់ប្រភេទនៃការចងចាំនេះ។

ចំពោះធនធាន៖ ប្រសិនបើយើងមានគម្រោងថាការចងចាំទាំងមូលនឹងត្រូវបានសរសេរឡើងវិញមិនលើសពីម្តងរៀងរាល់ 5 ថ្ងៃទេនោះ លើសពី 10 ឆ្នាំនៃការបម្រើយើងទទួលបានតិចជាងមួយពាន់វដ្តនៃការសរសេរឡើងវិញ។
ខ្ញុំសូមរំលឹកអ្នកថាក្រុមហ៊ុនផលិតសន្យាមួយរយពាន់។

បន្តិចអំពី NOR vs NAND

សព្វថ្ងៃនេះជាការពិតណាស់ អង្គចងចាំ NAND កាន់តែមានប្រជាប្រិយភាព ប៉ុន្តែខ្ញុំនឹងមិនប្រើវាសម្រាប់គម្រោងនេះទេ៖ NAND មិនដូច NOR តម្រូវឱ្យប្រើលេខកូដកែកំហុស តារាងប្លុកអាក្រក់ជាដើម ហើយថែមទាំងជើងរបស់ បន្ទះឈីប NAND ជាធម្មតាមានច្រើនទៀត។

គុណវិបត្តិនៃ NOR រួមមាន:

• បរិមាណតូច (ហើយតាមនោះតម្លៃខ្ពស់ក្នុងមួយមេកាបៃ);
• ល្បឿនទំនាក់ទំនងទាប (ភាគច្រើនដោយសារតែការពិតដែលថាចំណុចប្រទាក់សៀរៀលត្រូវបានប្រើជាធម្មតា SPI ឬ I2C);
• ការលុបយឺត (អាស្រ័យលើទំហំប្លុក វាចំណាយពេលពីមួយវិនាទីទៅច្រើនវិនាទី)។

វាហាក់ដូចជាគ្មានអ្វីសំខាន់សម្រាប់យើងទេ ដូច្នេះយើងបន្ត។

ប្រសិនបើព័ត៌មានលម្អិតគួរឱ្យចាប់អារម្មណ៍នោះ microcircuit ត្រូវបានជ្រើសរើស នៅ 25df321a (ទោះជាយ៉ាងនេះក្តី វាមិនសំខាន់ទេ មាន analogues ជាច្រើននៅលើទីផ្សារ ដែលអាចប្រើបាននៅក្នុង pinout និង command system ទោះបីជាយើងចង់ដំឡើង microcircuit ពីក្រុមហ៊ុនផលិតផ្សេងគ្នា និង/ឬទំហំខុសគ្នាក៏ដោយ អ្វីៗនឹងដំណើរការដោយមិនផ្លាស់ប្តូរ។ កូដ).

ខ្ញុំប្រើកម្មវិធីបញ្ជាដែលបានបង្កើតឡើងនៅក្នុងខឺណែលលីនុច; នៅលើ Raspberry អរគុណចំពោះការគាំទ្រការជាន់លើមែកធាងឧបករណ៍ អ្វីគ្រប់យ៉ាងគឺសាមញ្ញណាស់ - អ្នកត្រូវដាក់ស្រទាប់ដែលបានចងក្រងនៅក្នុង /boot/overlays ហើយកែប្រែបន្តិច /boot/config.txt ។

ឧទាហរណ៍ឯកសារ dts

និយាយឱ្យត្រង់ទៅ ខ្ញុំមិនប្រាកដថាវាត្រូវបានសរសេរដោយគ្មានកំហុសទេ ប៉ុន្តែវាដំណើរការ។

/*
 * Device tree overlay for at25 at spi0.1
 */

/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2708", "brcm,bcm2709"; 

    /* disable spi-dev for spi0.1 */
    fragment@0 {
        target = <&spi0>;
        __overlay__ {
            status = "okay";
            spidev@1{
                status = "disabled";
            };
        };
    };

    /* the spi config of the at25 */
    fragment@1 {
        target = <&spi0>;
        __overlay__ {
            #address-cells = <1>;
            #size-cells = <0>;
            flash: m25p80@1 {
                    compatible = "atmel,at25df321a";
                    reg = <1>;
                    spi-max-frequency = <50000000>;

                    /* default to false:
                    m25p,fast-read ;
                    */
            };
        };
    };

    __overrides__ {
        spimaxfrequency = <&flash>,"spi-max-frequency:0";
        fastread = <&flash>,"m25p,fast-read?";
    };
};

និងបន្ទាត់មួយទៀតនៅក្នុង config.txt

dtoverlay=at25:spimaxfrequency=50000000

ខ្ញុំនឹងលុបចោលការពិពណ៌នាអំពីការភ្ជាប់បន្ទះឈីបទៅ Raspberry Pi ។ ម៉្យាងវិញទៀត ខ្ញុំមិនមែនជាអ្នកជំនាញខាងអេឡិចត្រូនិចទេ ផ្ទុយទៅវិញ អ្វីៗនៅទីនេះគឺអាក្រក់សូម្បីតែសម្រាប់ខ្ញុំ៖ មីក្រូសៀគ្វីមានជើងត្រឹមតែ 8 ប៉ុណ្ណោះ ដែលយើងត្រូវការដី ថាមពល SPI (CS, SI, SO, SCK ); កម្រិតគឺដូចគ្នានឹង Raspberry Pi មិនចាំបាច់មានខ្សែភ្លើងបន្ថែមទេ - គ្រាន់តែភ្ជាប់ 6 pins ដែលបានចង្អុលបង្ហាញ។

ការបង្កើតបញ្ហា

ដូចធម្មតា សេចក្តីថ្លែងការណ៍បញ្ហាត្រូវឆ្លងកាត់ច្រើនដង ហើយវាហាក់ដូចជាខ្ញុំថាវាដល់ពេលហើយសម្រាប់រឿងបន្ទាប់។ ដូច្នេះ ចូរយើងឈប់ដាក់បញ្ចូលគ្នានូវអ្វីដែលបានសរសេររួចមកហើយ ហើយបញ្ជាក់ព័ត៌មានលម្អិតដែលនៅតែមាននៅក្នុងស្រមោល។

ដូច្នេះ យើងបានសម្រេចចិត្តថាកំណត់ហេតុនឹងត្រូវបានរក្សាទុកនៅក្នុង SPI NOR Flash។

អ្វី​ទៅ​ជា NOR Flash សម្រាប់​អ្នក​មិន​ដឹង?

នេះគឺជាអង្គចងចាំដែលមិនងាយនឹងបង្កជាហេតុ ដែលអ្នកអាចធ្វើប្រតិបត្តិការបីយ៉ាង៖

1. ការអាន៖
   ការអានធម្មតាបំផុត៖ យើងបញ្ជូនអាសយដ្ឋាន និងអានច្រើនបៃតាមដែលយើងត្រូវការ។
2. កំណត់ត្រា៖
   ការសរសេរទៅ NOR flash មើលទៅដូចជាធម្មតា ប៉ុន្តែវាមានលក្ខណៈពិសេសមួយ៖ អ្នកអាចផ្លាស់ប្តូរបានត្រឹមតែ 1 ដល់ 0 ប៉ុណ្ណោះ ប៉ុន្តែមិនផ្ទុយមកវិញទេ។ ឧទាហរណ៍ ប្រសិនបើយើងមាន 0x55 នៅក្នុងកោសិកាមេម៉ូរី បន្ទាប់មកបន្ទាប់ពីសរសេរ 0x0f ទៅវា 0x05 នឹងត្រូវបានរក្សាទុកនៅទីនោះរួចហើយ (សូមមើលតារាងខាងក្រោម);
3. លុប៖
   ជាការពិតណាស់ យើងត្រូវតែអាចធ្វើប្រតិបត្តិការផ្ទុយ - ផ្លាស់ប្តូរ 0 ទៅ 1 នេះគឺជាអ្វីដែលប្រតិបត្តិការលុបគឺសម្រាប់។ មិនដូចពីរដំបូងទេ វាដំណើរការមិនមែនជាមួយបៃទេប៉ុន្តែជាមួយប្លុក (ប្លុកលុបអប្បបរមានៅក្នុងបន្ទះឈីបដែលបានជ្រើសរើសគឺ 4kb) ។ លុបបំផ្លាញប្លុកទាំងមូល ហើយជាមធ្យោបាយតែមួយគត់ដើម្បីផ្លាស់ប្តូរ 0 ទៅ 1។ ដូច្នេះហើយ នៅពេលធ្វើការជាមួយអង្គចងចាំពន្លឺ ជារឿយៗអ្នកត្រូវតម្រឹមរចនាសម្ព័ន្ធទិន្នន័យទៅនឹងព្រំដែនប្លុក លុប។
   ថតក្នុង NOR Flash៖

ទិន្នន័យគោលពីរ

គឺ
01010101

កត់ត្រា
00001111

បាន​ក្លាយជា
00000101

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

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

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

តើប្រភពនៃបញ្ហាអ្វីខ្លះអាចត្រូវបានពិចារណា?

• បិទកំឡុងពេលប្រតិបត្តិការសរសេរ/លុប។ នេះគឺមកពីប្រភេទនៃ "មិនមានល្បិចប្រឆាំងនឹង crowbar" ។
  ព័ត៌មានពី ការពិភាក្សា នៅលើ stackexchange: នៅពេលដែលថាមពលត្រូវបានបិទខណៈពេលធ្វើការជាមួយ flash ទាំងការលុប (កំណត់ទៅ 1) និងសរសេរ (កំណត់ទៅ 0) នាំឱ្យមានអាកប្បកិរិយាដែលមិនបានកំណត់: ទិន្នន័យអាចត្រូវបានសរសេរ សរសេរដោយផ្នែក (និយាយថាយើងបានផ្ទេរ 10 បៃ / 80 ប៊ីត។ ប៉ុន្តែមិនមែនត្រឹមតែ 45 ប៊ីតទេដែលអាចសរសេរបាន) វាក៏អាចទៅរួចដែលថាប៊ីតមួយចំនួននឹងស្ថិតក្នុងស្ថានភាព "កម្រិតមធ្យម" (ការអានអាចបង្កើតបានទាំង 0 និង 1);
• កំហុសនៅក្នុងអង្គចងចាំពន្លឺ។
  BER ទោះបីជាទាបខ្លាំងក៏ដោយ មិនអាចស្មើនឹងសូន្យបានទេ។
• កំហុសឡានក្រុង
  ទិន្នន័យដែលបានបញ្ជូនតាមរយៈ SPI មិនត្រូវបានការពារតាមមធ្យោបាយណាមួយឡើយ ទាំងកំហុសប៊ីតតែមួយ និងកំហុសក្នុងការធ្វើសមកាលកម្មអាចកើតឡើង - ការបាត់បង់ឬការបញ្ចូលប៊ីត (ដែលនាំឱ្យមានការបង្ខូចទ្រង់ទ្រាយទិន្នន័យដ៏ធំ);
• កំហុស/បញ្ហាផ្សេងៗ
  កំហុសក្នុងកូដ ភាពមិនប្រក្រតី Raspberry ការជ្រៀតជ្រែកពីជនបរទេស...

ខ្ញុំបានបង្កើតតម្រូវការ ការបំពេញដែលតាមគំនិតរបស់ខ្ញុំ គឺចាំបាច់ដើម្បីធានានូវភាពជឿជាក់៖

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

គំនិត, វិធីសាស្រ្ត, ការឆ្លុះបញ្ចាំង

ពេល​ខ្ញុំ​ចាប់​ផ្តើម​គិត​អំពី​បញ្ហា​នេះ គំនិត​ជា​ច្រើន​បាន​លេច​ចេញ​មក​ក្នុង​ក្បាល​របស់​ខ្ញុំ ឧទាហរណ៍៖

• ប្រើការបង្ហាប់ទិន្នន័យ;
• ប្រើរចនាសម្ព័ន្ធទិន្នន័យដ៏ឆ្លាតវៃ ឧទាហរណ៍ រក្សាទុកបឋមកថាដាច់ដោយឡែកពីកំណត់ត្រាដោយខ្លួនឯង ដូច្នេះប្រសិនបើមានកំហុសនៅក្នុងកំណត់ត្រាណាមួយ អ្នកអាចអាននៅសល់ដោយគ្មានបញ្ហាអ្វីឡើយ។
• ប្រើវាលប៊ីតដើម្បីគ្រប់គ្រងការបញ្ចប់នៃការថតនៅពេលដែលថាមពលត្រូវបានបិទ។
• រក្សាទុក checksum សម្រាប់អ្វីគ្រប់យ៉ាង;
• ប្រើប្រភេទកូដដែលធន់នឹងសំឡេងមួយចំនួន។

គំនិត​ទាំងនេះ​ខ្លះ​ត្រូវ​បាន​គេ​ប្រើ ខណៈ​ខ្លះ​ទៀត​ត្រូវ​បាន​គេ​សម្រេច​ចិត្ត​បោះបង់។ តោះទៅតាមលំដាប់។

ការបង្រួមទិន្នន័យ

ព្រឹត្តិការណ៍ដែលខ្លួនយើងកត់ត្រានៅក្នុងទិនានុប្បវត្តិគឺស្រដៀងគ្នា និងអាចកើតឡើងវិញបាន ("បោះកាក់ 5 រូប្លិ" "ចុចប៊ូតុងសម្រាប់ផ្តល់ការផ្លាស់ប្តូរ" ... ) ។ ដូច្នេះការបង្ហាប់គួរតែមានប្រសិទ្ធភាពណាស់។

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

បំណែកនៃកំណត់ហេតុត្រូវបានយកចេញពីឧបករណ៍ធ្វើការ (1.7 MB, 70 ពាន់ធាតុ) ហើយបានពិនិត្យជាលើកដំបូងសម្រាប់ការបង្ហាប់ដោយប្រើ gzip, lz4, lzop, bzip2, xz, zstd ដែលមាននៅលើកុំព្យូទ័រ។

• gzip, xz, zstd បានបង្ហាញលទ្ធផលស្រដៀងគ្នា (40Kb) ។
  ខ្ញុំភ្ញាក់ផ្អើលដែល xz ម៉ូតបង្ហាញខ្លួនឯងនៅទីនេះក្នុងកម្រិត gzip ឬ zstd;
• lzip ជាមួយនឹងការកំណត់លំនាំដើមបានផ្តល់លទ្ធផលអាក្រក់បន្តិច។
• lz4 និង lzop បង្ហាញលទ្ធផលមិនសូវល្អ (150Kb);
• bzip2 បានបង្ហាញលទ្ធផលល្អគួរឱ្យភ្ញាក់ផ្អើល (18Kb) ។

ដូច្នេះទិន្នន័យត្រូវបានបង្ហាប់យ៉ាងល្អ។
ដូច្នេះ (ប្រសិនបើយើងមិនរកឃើញកំហុសធ្ងន់ធ្ងរ) វានឹងមានការបង្ហាប់! ដោយ​សារ​តែ​ទិន្នន័យ​កាន់​តែ​ច្រើន​អាច​មាន​នៅ​លើ flash drive ដូច​គ្នា។

ចូរយើងគិតអំពីគុណវិបត្តិ។

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

ខ្ញុំឃើញវិធីបីយ៉ាង៖

1. បង្រួមកំណត់ត្រានីមួយៗដោយប្រើការបង្ហាប់វចនានុក្រមជំនួសឱ្យក្បួនដោះស្រាយដែលបានពិភាក្សាខាងលើ។
   វាជាជម្រើសដែលអាចដំណើរការបានទាំងស្រុង ប៉ុន្តែខ្ញុំមិនចូលចិត្តវាទេ។ ដើម្បីធានាបាននូវកម្រិតនៃការបង្ហាប់ដែលសមរម្យច្រើន ឬតិច វចនានុក្រមត្រូវតែ "កែសម្រួល" ទៅនឹងទិន្នន័យជាក់លាក់ ការផ្លាស់ប្តូរណាមួយនឹងនាំឱ្យកម្រិតបង្ហាប់ធ្លាក់ចុះយ៉ាងមហន្តរាយ។ បាទ បញ្ហាអាចត្រូវបានដោះស្រាយដោយការបង្កើតវចនានុក្រមកំណែថ្មី ប៉ុន្តែនេះគឺជាការឈឺក្បាល - យើងនឹងត្រូវការរក្សាទុកគ្រប់កំណែនៃវចនានុក្រម។ នៅ​ក្នុង​ធាតុ​នីមួយៗ យើង​នឹង​ត្រូវ​បញ្ជាក់​ជាមួយ​នឹង​កំណែ​វចនានុក្រម​ណា​ដែល​វា​ត្រូវ​បាន​បង្ហាប់...
2. បង្រួមកំណត់ត្រានីមួយៗដោយប្រើក្បួនដោះស្រាយ "បុរាណ" ប៉ុន្តែដោយឯករាជ្យពីអ្នកដទៃ។
   ក្បួនដោះស្រាយការបង្ហាប់ដែលកំពុងពិចារណាមិនត្រូវបានរចនាឡើងដើម្បីធ្វើការជាមួយកំណត់ត្រានៃទំហំនេះ (រាប់សិបបៃ) សមាមាត្រការបង្ហាប់នឹងតិចជាង 1 យ៉ាងច្បាស់ (នោះគឺការបង្កើនបរិមាណទិន្នន័យជំនួសឱ្យការបង្ហាប់);
3. ធ្វើ FLUSH បន្ទាប់ពីថតនីមួយៗ។
   បណ្ណាល័យបង្ហាប់ជាច្រើនមានការគាំទ្រសម្រាប់ FLUSH ។ នេះ​ជា​ពាក្យ​បញ្ជា (ឬ​ប៉ារ៉ាម៉ែត្រ​នៃ​ដំណើរ​ការ​បង្ហាប់) ពេល​ទទួល​បណ្ណសារ​បង្កើត​ជា​ស្ទ្រីម​ដែល​បាន​បង្ហាប់ ដូច្នេះ​វា​អាច​ត្រូវ​បាន​ប្រើ​ដើម្បី​ស្ដារ ទាំងអស់ ទិន្នន័យ​ដែល​មិន​បាន​បង្ហាប់ ដែល​ត្រូវ​បាន​ទទួល​រួច​ហើយ។ analogue បែបនេះ sync នៅក្នុងប្រព័ន្ធឯកសារឬ commit ក្នុង sql ។
   អ្វីដែលសំខាន់នោះគឺថាប្រតិបត្តិការបង្ហាប់ជាបន្តបន្ទាប់នឹងអាចប្រើវចនានុក្រមបង្គរ ហើយសមាមាត្រការបង្ហាប់នឹងមិនរងទុក្ខច្រើនដូចនៅក្នុងកំណែមុនទេ។

ខ្ញុំ​គិត​ថា​វា​ច្បាស់​ណាស់​ដែល​ខ្ញុំ​ជ្រើសរើស​ជម្រើស​ទី​បី សូម​មើល​វា​ឱ្យ​កាន់តែ​លម្អិត។

បានរកឃើញ អត្ថបទអស្ចារ្យ អំពី FLUSH ក្នុង zlib ។

ខ្ញុំបានធ្វើតេស្តជង្គង់ដោយផ្អែកលើអត្ថបទបានយក 70 ពាន់ធាតុកំណត់ហេតុពីឧបករណ៍ពិតដែលមានទំហំទំព័រ 60Kb (យើងនឹងត្រលប់ទៅទំហំទំព័រនៅពេលក្រោយ) បានទទួល៖

ទិន្នន័យដំបូង
ការបង្ហាប់ gzip -9 (គ្មាន FLUSH)
zlib ជាមួយ Z_PARTIAL_FLUSH
zlib ជាមួយ Z_SYNC_FLUSH

កម្រិតសំឡេង, KB
1692
40
352
604

នៅ glance ដំបូង តម្លៃដែលរួមចំណែកដោយ FLUSH គឺខ្ពស់ហួសហេតុ ប៉ុន្តែតាមពិតយើងមានជម្រើសតិចតួច - ទាំងមិនបង្ហាប់ទាល់តែសោះ ឬបង្ហាប់ (និងមានប្រសិទ្ធភាពខ្លាំង) ជាមួយ FLUSH ។ យើងមិនត្រូវភ្លេចថាយើងមានកំណត់ត្រាចំនួន 70 ទេ ការលែងត្រូវការតទៅទៀតដែលណែនាំដោយ Z_PARTIAL_FLUSH គឺត្រឹមតែ 4-5 បៃក្នុងមួយកំណត់ត្រាប៉ុណ្ណោះ។ ហើយសមាមាត្របង្ហាប់បានប្រែទៅជាស្ទើរតែ 5: 1 ដែលច្រើនជាងលទ្ធផលដ៏ល្អ។

វាអាចជាការភ្ញាក់ផ្អើលមួយ ប៉ុន្តែ Z_SYNC_FLUSH តាមពិតគឺជាវិធីដែលមានប្រសិទ្ធភាពជាងដើម្បីធ្វើ FLUSH

នៅពេលប្រើ Z_SYNC_FLUSH 4 បៃចុងក្រោយនៃធាតុនីមួយៗនឹងតែងតែជា 0x00, 0x00, 0xff, 0xff ។ ហើយប្រសិនបើយើងស្គាល់ពួកវា នោះយើងមិនចាំបាច់រក្សាទុកវាទេ ដូច្នេះទំហំចុងក្រោយគឺត្រឹមតែ 324Kb ប៉ុណ្ណោះ។

អត្ថបទ​ដែល​ខ្ញុំ​បាន​ភ្ជាប់​ទៅ​នឹង​មាន​ការ​ពន្យល់៖

ប្លុកប្រភេទ 0 ថ្មីដែលមានមាតិកាទទេត្រូវបានបន្ថែម។

ប្លុកប្រភេទ 0 ដែលមានមាតិកាទទេមាន៖

• បឋមកថាប្លុកបីប៊ីត;
• 0 ទៅ 7 ប៊ីតស្មើនឹងសូន្យ ដើម្បីសម្រេចបានការតម្រឹមបៃ;
• លំដាប់បួនបៃ 00 00 FF FF ។

ដូចដែលអ្នកអាចមើលឃើញយ៉ាងងាយស្រួលនៅក្នុងប្លុកចុងក្រោយមុនពេល 4 បៃទាំងនេះមានពី 3 ទៅ 10 សូន្យប៊ីត។ ទោះយ៉ាងណាក៏ដោយ ការអនុវត្តបានបង្ហាញថាពិតជាមានយ៉ាងហោចណាស់ 10 សូន្យប៊ីត។

វាប្រែថាបណ្តុំទិន្នន័យខ្លីៗបែបនេះជាធម្មតា (ជានិច្ចកាល?) ត្រូវបានអ៊ិនកូដដោយប្រើប្លុកនៃប្រភេទទី 1 (ប្លុកថេរ) ដែលចាំបាច់បញ្ចប់ដោយ 7 សូន្យប៊ីត ផ្តល់ចំនួនសរុបចំនួន 10-17 ដែលត្រូវបានធានាសូន្យប៊ីត (ហើយនៅសល់នឹង សូន្យជាមួយនឹងប្រូបាប៊ីលីតេប្រហែល 50%) ។

ដូច្នេះនៅលើទិន្នន័យសាកល្បង ក្នុង 100% នៃករណីមានសូន្យបៃមុន 0x00, 0x00, 0xff, 0xff ហើយក្នុងច្រើនជាងមួយភាគបីនៃករណីមានសូន្យបៃចំនួនពីរ។ (ប្រហែលជាការពិតគឺថាខ្ញុំប្រើ CBOR គោលពីរ ហើយនៅពេលប្រើអត្ថបទ JSON ប្លុកនៃប្រភេទទី 2 - ប្លុកថាមវន្តនឹងជារឿងធម្មតាជាង រៀងគ្នា ប្លុកដោយគ្មានសូន្យបៃបន្ថែមមុន 0x00, 0x00, 0xff, 0xff នឹងត្រូវបានជួបប្រទះ).

សរុបមក ដោយប្រើទិន្នន័យសាកល្បងដែលមាន វាអាចបញ្ចូលទៅក្នុងទិន្នន័យដែលបានបង្ហាប់តិចជាង 250Kb ។

អ្នកអាចសន្សំបានបន្តិចទៀតដោយការលេងសើចបន្តិច៖ សម្រាប់ពេលនេះ យើងព្រងើយកន្តើយចំពោះវត្តមានរបស់សូន្យប៊ីតមួយចំនួននៅចុងបញ្ចប់នៃប្លុក ប៊ីតពីរបីនៅដើមប្លុកក៏មិនផ្លាស់ប្តូរដែរ...
ប៉ុន្តែបន្ទាប់មកខ្ញុំបានធ្វើការសម្រេចចិត្តដោយឆន្ទៈដ៏មុតមាំមួយដើម្បីបញ្ឈប់ បើមិនដូច្នេះទេក្នុងអត្រានេះ ខ្ញុំអាចបញ្ចប់ការបង្កើតបណ្ណសារផ្ទាល់ខ្លួនរបស់ខ្ញុំបាន។

សរុបមក ពីទិន្នន័យសាកល្បងរបស់ខ្ញុំ ខ្ញុំបានទទួល 3-4 បៃក្នុងមួយការសរសេរ សមាមាត្របង្ហាប់បានប្រែទៅជាច្រើនជាង 6:1 ។ ខ្ញុំនឹងនិយាយដោយស្មោះត្រង់៖ ខ្ញុំមិនរំពឹងលទ្ធផលបែបនេះទេ តាមគំនិតរបស់ខ្ញុំ អ្វីដែលប្រសើរជាង 2:1 គឺជាលទ្ធផលដែលបង្ហាញអំពីភាពត្រឹមត្រូវនៃការប្រើប្រាស់ការបង្ហាប់។

អ្វីគ្រប់យ៉ាងគឺល្អ ប៉ុន្តែ zlib (deflate) នៅតែជាក្បួនដោះស្រាយការបង្ហាប់ដែលមានលក្ខណៈបុរាណ សមនឹងទទួលបាន និងចាស់បន្តិច។ ការពិតដែលថា 32Kb ចុងក្រោយនៃស្ទ្រីមទិន្នន័យដែលមិនបានបង្ហាប់ត្រូវបានប្រើជាវចនានុក្រមមើលទៅចម្លែកសព្វថ្ងៃនេះ (នោះគឺប្រសិនបើប្លុកទិន្នន័យខ្លះស្រដៀងនឹងអ្វីដែលមាននៅក្នុងស្ទ្រីមបញ្ចូលកាលពី 40Kb ពីមុន នោះវានឹងចាប់ផ្តើមរក្សាទុកម្តងទៀត។ ហើយនឹងមិនសំដៅទៅលើការកើតឡើងពីមុនទេ)។ នៅក្នុងបណ្ណសារទំនើបទាន់សម័យ ទំហំវចនានុក្រមជារឿយៗត្រូវបានវាស់ជាមេកាបៃជាជាងគីឡូបៃ។

ដូច្នេះ យើងបន្តការសិក្សាខ្នាតតូចរបស់យើងអំពីបណ្ណសារ។

បន្ទាប់យើងបានសាកល្បង bzip2 (កុំភ្លេចថាដោយគ្មាន FLUSH វាបង្ហាញពីសមាមាត្រការបង្ហាប់ដ៏អស្ចារ្យស្ទើរតែ 100: 1) ។ ជាអកុសល វាដំណើរការមិនល្អជាមួយ FLUSH ទំហំនៃទិន្នន័យដែលបានបង្ហាប់បានប្រែទៅជាធំជាងទិន្នន័យដែលមិនបានបង្ហាប់។

ការសន្មត់របស់ខ្ញុំអំពីមូលហេតុនៃការបរាជ័យ

Libbz2 ផ្តល់ជម្រើស flush តែមួយគត់ដែលហាក់ដូចជាជម្រះវចនានុក្រម (ស្រដៀងទៅនឹង Z_FULL_FLUSH ក្នុង zlib); មិនមានការនិយាយអំពីការបង្ហាប់ដែលមានប្រសិទ្ធភាពណាមួយបន្ទាប់ពីនេះទេ។

ហើយចុងក្រោយដែលត្រូវសាកល្បងគឺ zstd ។ អាស្រ័យលើប៉ារ៉ាម៉ែត្រ វាបង្ហាប់នៅកម្រិត gzip ប៉ុន្តែលឿនជាង ឬប្រសើរជាង gzip។

Alas ជាមួយនឹង FLUSH វាមិនដំណើរការល្អទេ: ទំហំនៃទិន្នន័យដែលបានបង្ហាប់គឺប្រហែល 700Kb ។

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

ខ្ញុំបានសម្រេចចិត្តឈប់នៅចំណុចនេះក្នុងការពិសោធន៍របស់ខ្ញុំជាមួយបណ្ណសារ (ខ្ញុំសូមរំលឹកអ្នកថា xz, lzip, lzo, lz4 មិនបានបង្ហាញខ្លួនឯងសូម្បីតែនៅដំណាក់កាលសាកល្បងដោយគ្មាន FLUSH ហើយខ្ញុំមិនបានគិតពីក្បួនដោះស្រាយការបង្ហាប់កម្រនិងអសកម្មជាងនេះទេ) ។

ចូរយើងត្រលប់ទៅបញ្ហាក្នុងប័ណ្ណសារវិញ។

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

មានវិធីសាស្រ្តក្នុងការដោះស្រាយបញ្ហានេះ៖

1. ការពារកុំឱ្យបញ្ហាកើតឡើង - បន្ថែមភាពច្របូកច្របល់ទៅនឹងទិន្នន័យដែលបានបង្ហាប់ដែលនឹងអនុញ្ញាតឱ្យអ្នកកំណត់អត្តសញ្ញាណនិងកែកំហុស។ យើងនឹងនិយាយអំពីរឿងនេះនៅពេលក្រោយ។
2. កាត់បន្ថយផលវិបាក ប្រសិនបើមានបញ្ហាកើតឡើង
   យើងបាននិយាយរួចមកហើយថា អ្នកអាចបង្ហាប់ប្លុកទិន្នន័យនីមួយៗដោយឯករាជ្យ ហើយបញ្ហានឹងរលាយបាត់ដោយខ្លួនឯង (ការខូចខាតចំពោះទិន្នន័យនៃប្លុកមួយនឹងនាំឱ្យបាត់បង់ទិន្នន័យសម្រាប់តែប្លុកនេះប៉ុណ្ណោះ)។ ទោះជាយ៉ាងណាក៏ដោយ នេះគឺជាករណីធ្ងន់ធ្ងរដែលការបង្ហាប់ទិន្នន័យនឹងគ្មានប្រសិទ្ធភាព។ ភាពផ្ទុយគ្នាខ្លាំង៖ ប្រើបន្ទះឈីប 4MB ទាំងអស់របស់យើងជាបណ្ណសារតែមួយ ដែលនឹងផ្តល់ឱ្យយើងនូវការបង្ហាប់ដ៏ល្អ ប៉ុន្តែផលវិបាកដ៏មហន្តរាយនៅក្នុងករណីនៃទិន្នន័យខូច។
   បាទ/ចាស ការសម្របសម្រួលគឺត្រូវការជាចាំបាច់ក្នុងលក្ខខណ្ឌនៃភាពអាចជឿជាក់បាន។ ប៉ុន្តែយើងត្រូវតែចងចាំថាយើងកំពុងបង្កើតទម្រង់ផ្ទុកទិន្នន័យសម្រាប់អង្គចងចាំដែលមិនងាយនឹងបង្កជាហេតុជាមួយនឹង BER ទាបបំផុត និងរយៈពេលផ្ទុកទិន្នន័យដែលបានប្រកាស 20 ឆ្នាំ។

ក្នុងអំឡុងពេលនៃការពិសោធន៍ ខ្ញុំបានរកឃើញថាការបាត់បង់គួរឱ្យកត់សម្គាល់តិច ឬច្រើននៅក្នុងកម្រិតនៃការបង្ហាប់ចាប់ផ្តើមនៅលើប្លុកនៃទិន្នន័យដែលបានបង្ហាប់ដែលមានទំហំតិចជាង 10 KB ។
វាត្រូវបានលើកឡើងពីមុនថាអង្គចងចាំដែលបានប្រើត្រូវបានសរសេរជាទំព័រ ខ្ញុំឃើញហេតុផលថាហេតុអ្វីបានជាការឆ្លើយឆ្លង "ទំព័រមួយ - ប្លុកមួយនៃទិន្នន័យដែលបានបង្ហាប់" មិនគួរត្រូវបានប្រើទេ។

នោះគឺទំហំទំព័រសមហេតុផលអប្បបរមាគឺ 16Kb (ជាមួយទុនបំរុងសម្រាប់ព័ត៌មានសេវាកម្ម)។ ទោះយ៉ាងណាក៏ដោយ ទំហំទំព័រតូចបែបនេះដាក់កម្រិតយ៉ាងសំខាន់លើទំហំកំណត់ត្រាអតិបរមា។

ទោះបីជាខ្ញុំមិនទាន់រំពឹងថាកំណត់ត្រាធំជាងពីរបីគីឡូបៃក្នុងទម្រង់បង្ហាប់ក៏ដោយ ខ្ញុំបានសម្រេចចិត្តប្រើទំព័រ 32Kb (សម្រាប់សរុប 128 ទំព័រក្នុងមួយបន្ទះ)។

សង្ខេប៖

• យើងរក្សាទុកទិន្នន័យដែលបានបង្ហាប់ដោយប្រើ zlib (deflate);
• សម្រាប់ធាតុនីមួយៗ យើងកំណត់ Z_SYNC_FLUSH;
• សម្រាប់​កំណត់ត្រា​ដែល​បាន​បង្ហាប់​នីមួយៗ យើង​កាត់​តាម​បៃ​ (ឧទាហរណ៍ 0x00, 0x00, 0xff, 0xff); នៅក្នុងបឋមកថាយើងបង្ហាញពីចំនួនបៃដែលយើងកាត់ចេញ។
• យើងរក្សាទុកទិន្នន័យក្នុងទំព័រ 32Kb; មានស្ទ្រីមតែមួយនៃទិន្នន័យដែលបានបង្ហាប់នៅខាងក្នុងទំព័រ។ នៅលើទំព័រនីមួយៗ យើងចាប់ផ្តើមបង្ហាប់ម្តងទៀត។

ហើយមុននឹងបញ្ចប់ដោយការបង្ហាប់ ខ្ញុំចង់ទាក់ទាញការយកចិត្តទុកដាក់របស់អ្នកចំពោះការពិតដែលថាយើងមានទិន្នន័យដែលបានបង្ហាប់ពីរបីបៃក្នុងមួយកំណត់ត្រា ដូច្នេះវាមានសារៈសំខាន់ខ្លាំងណាស់ដែលមិនត្រូវបំប៉ោងព័ត៌មានសេវាកម្មនោះទេ រាល់បៃរាប់នៅទីនេះ។

ការរក្សាទុកបឋមកថាទិន្នន័យ

ដោយសារយើងមានកំណត់ត្រានៃប្រវែងអថេរ យើងត្រូវកំណត់ទីកន្លែង/ព្រំដែននៃកំណត់ត្រា។

ខ្ញុំដឹងពីវិធីសាស្រ្តបីយ៉ាង៖

1. កំណត់ត្រាទាំងអស់ត្រូវបានរក្សាទុកក្នុងចរន្តបន្ត ទីមួយមានក្បាលកំណត់ត្រាដែលមានប្រវែង ហើយបន្ទាប់មកកំណត់ត្រាខ្លួនឯង។
   នៅក្នុងតំណាងនេះ ទាំងបឋមកថា និងទិន្នន័យអាចមានប្រវែងអថេរ។
   សំខាន់ យើងទទួលបានបញ្ជីភ្ជាប់តែមួយដែលត្រូវបានប្រើគ្រប់ពេលវេលា។
2. បឋមកថា និងកំណត់ត្រាខ្លួនឯងត្រូវបានរក្សាទុកក្នុងស្ទ្រីមដាច់ដោយឡែក។
   ដោយប្រើបឋមកថានៃប្រវែងថេរ យើងធានាថាការខូចខាតក្បាលមួយមិនប៉ះពាល់ដល់ផ្នែកផ្សេងទៀតទេ។
   វិធីសាស្រ្តស្រដៀងគ្នានេះត្រូវបានគេប្រើឧទាហរណ៍នៅក្នុងប្រព័ន្ធឯកសារជាច្រើន;
3. កំណត់ត្រាត្រូវបានរក្សាទុកក្នុងចរន្តបន្ត ព្រំដែនកំណត់ត្រាត្រូវបានកំណត់ដោយសញ្ញាសម្គាល់ជាក់លាក់មួយ (តួអក្សរ/លំដាប់នៃតួអក្សរដែលត្រូវបានហាមឃាត់នៅក្នុងប្លុកទិន្នន័យ)។ ប្រសិនបើមានសញ្ញាសម្គាល់នៅក្នុងកំណត់ត្រានោះ យើងជំនួសវាដោយលំដាប់មួយចំនួន (គេចវា)។
   ជាឧទាហរណ៍ វិធីសាស្រ្តស្រដៀងគ្នានេះត្រូវបានគេប្រើនៅក្នុងពិធីការ PPP ។

ខ្ញុំនឹងបង្ហាញ។

ជម្រើស 1:

អ្វីគ្រប់យ៉ាងគឺសាមញ្ញណាស់នៅទីនេះ: ដោយដឹងពីប្រវែងនៃកំណត់ត្រាយើងអាចគណនាអាសយដ្ឋាននៃបឋមកថាបន្ទាប់។ ដូច្នេះ​យើង​ផ្លាស់ទី​តាម​ក្បាល​រហូត​ដល់​យើង​ជួប​នឹង​ផ្ទៃ​ដែល​ពេញ​ដោយ 0xff (តំបន់​ទំនេរ) ឬ​ចុង​ទំព័រ។

ជម្រើស 2:

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

ជម្រើស 3:

មិនចាំបាច់រក្សាទុកប្រវែង ឬព័ត៌មានផ្សេងទៀតអំពីទីតាំងនៃទិន្នន័យនៅក្នុងបឋមកថាទេ សញ្ញាសម្គាល់ដែលបង្ហាញពីព្រំដែននៃកំណត់ត្រាគឺគ្រប់គ្រាន់ហើយ។ ទោះយ៉ាងណាក៏ដោយ ទិន្នន័យត្រូវតែដំណើរការនៅពេលសរសេរ/អាន។
ខ្ញុំនឹងប្រើ 0xff ជាសញ្ញាសម្គាល់ (ដែលបំពេញទំព័របន្ទាប់ពីការលុប) ដូច្នេះតំបន់ឥតគិតថ្លៃនឹងមិនត្រូវបានចាត់ទុកជាទិន្នន័យទេ។

តារាងប្រៀបធៀប៖

ជម្រើស 1
ជម្រើស 2
ជម្រើស 3

ការអត់ធ្មត់កំហុស
-
+
+

បង្រួម
+
-
+

ភាពស្មុគស្មាញនៃការអនុវត្ត
*
**
**

ជម្រើសទី 1 មានកំហុសធ្ងន់ធ្ងរ៖ ប្រសិនបើក្បាលណាមួយត្រូវបានខូចខាត ខ្សែសង្វាក់បន្តបន្ទាប់ទាំងមូលត្រូវបានបំផ្លាញ។ ជម្រើសដែលនៅសេសសល់អនុញ្ញាតឱ្យអ្នកសង្គ្រោះទិន្នន័យមួយចំនួនសូម្បីតែក្នុងករណីមានការខូចខាតដ៏ធំក៏ដោយ។
ប៉ុន្តែនៅទីនេះវាជាការសមរម្យក្នុងការចងចាំថាយើងបានសម្រេចចិត្តរក្សាទុកទិន្នន័យក្នុងទម្រង់ដែលបានបង្ហាប់ ហើយដូច្នេះយើងបាត់បង់ទិន្នន័យទាំងអស់នៅលើទំព័របន្ទាប់ពីកំណត់ត្រា "ខូច" ដូច្នេះទោះបីជាមានដកនៅក្នុងតារាងក៏ដោយ យើងមិន យកវាទៅក្នុងគណនី។

បង្រួម៖

• នៅក្នុងជម្រើសទីមួយ យើងត្រូវរក្សាទុកតែប្រវែងនៅក្នុងបឋមកថា ប្រសិនបើយើងប្រើចំនួនគត់ប្រវែងអថេរ នោះក្នុងករណីភាគច្រើនយើងអាចទទួលបានដោយមួយបៃ។
• នៅក្នុងជម្រើសទីពីរ យើងត្រូវរក្សាទុកអាសយដ្ឋានចាប់ផ្តើម និងប្រវែង។ កំណត់ត្រាត្រូវតែមានទំហំថេរ ខ្ញុំប៉ាន់ស្មាន 4 បៃក្នុងមួយកំណត់ត្រា (ពីរបៃសម្រាប់អុហ្វសិត និងពីរបៃសម្រាប់ប្រវែង);
• ជម្រើសទីបីត្រូវការតែតួអក្សរមួយប៉ុណ្ណោះដើម្បីបង្ហាញពីការចាប់ផ្តើមនៃការថត បូកនឹងការថតដោយខ្លួនឯងនឹងកើនឡើង 1-2% ដោយសារតែការការពារ។ ជាទូទៅ ប្រហាក់ប្រហែលនឹងជម្រើសទីមួយ។

ដំបូងខ្ញុំបានចាត់ទុកជម្រើសទីពីរជាជម្រើសសំខាន់ (ហើយថែមទាំងបានសរសេរការអនុវត្ត) ។ ខ្ញុំបានបោះបង់ចោលវាតែនៅពេលដែលខ្ញុំសម្រេចចិត្តប្រើការបង្ហាប់។

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

សម្រាប់ជម្រើសទីបី៖ ខ្ញុំបានឲ្យផ្កាយពីរសម្រាប់ការលំបាកក្នុងការអនុវត្ត ដោយគ្រាន់តែខ្ញុំមិនចូលចិត្តរញ៉េរញ៉ៃជាមួយរបាំងការពារ ការផ្លាស់ប្តូររយៈពេលនៅក្នុងដំណើរការ។ល។ បាទ/ចាស ប្រហែលជាខ្ញុំលំអៀង ប៉ុន្តែខ្ញុំនឹងត្រូវសរសេរកូដ ហេតុអ្វីបានជាបង្ខំខ្លួនឯងឱ្យធ្វើអ្វីមួយដែលអ្នកមិនចូលចិត្ត។

សង្ខេប៖ យើងជ្រើសរើសជម្រើសផ្ទុកក្នុងទម្រង់ជាខ្សែសង្វាក់ "បឋមកថាជាមួយប្រវែង - ទិន្នន័យនៃប្រវែងអថេរ" ដោយសារតែប្រសិទ្ធភាព និងភាពងាយស្រួលនៃការអនុវត្ត។

ការប្រើប្រាស់ Bit Fields ដើម្បីតាមដានភាពជោគជ័យនៃប្រតិបត្តិការសរសេរ

ខ្ញុំ​មិន​ចាំ​ថា​ឥឡូវ​នេះ​ខ្ញុំ​បាន​គំនិត​ពី​ណា​ទេ ប៉ុន្តែ​វា​មើល​ទៅ​ដូច​នេះ៖
សម្រាប់ធាតុនីមួយៗ យើងបែងចែកប៊ីតជាច្រើនដើម្បីរក្សាទុកទង់។
ដូចដែលយើងបាននិយាយកាលពីដើមថាបន្ទាប់ពីលុបប៊ីតទាំងអស់ត្រូវបានបំពេញដោយ 1s ហើយយើងអាចផ្លាស់ប្តូរពី 1 ទៅ 0 ប៉ុន្តែមិនមែនផ្ទុយមកវិញទេ។ ដូច្នេះសម្រាប់ "ទង់មិនត្រូវបានកំណត់" យើងប្រើ 1 សម្រាប់ "ទង់ត្រូវបានកំណត់" យើងប្រើ 0 ។

នេះជាអ្វីដែលការដាក់កំណត់ត្រាប្រវែងអថេរទៅក្នុងពន្លឺអាចមើលទៅដូច៖

1. កំណត់ទង់ "ការថតប្រវែងបានចាប់ផ្តើម";
2. កត់ត្រាប្រវែង;
3. កំណត់ទង់ "ការកត់ត្រាទិន្នន័យបានចាប់ផ្តើម";
4. យើងកត់ត្រាទិន្នន័យ;
5. កំណត់ទង់ "ការកត់ត្រាបានបញ្ចប់" ។

លើសពីនេះទៀតយើងនឹងមានទង់ "កំហុសបានកើតឡើង" សម្រាប់ទង់សរុបចំនួន 4 ប៊ីត។

ក្នុងករណីនេះយើងមានស្ថានភាពស្ថេរភាពពីរ "1111" - ការថតមិនទាន់បានចាប់ផ្តើមហើយ "1000" - ការថតបានជោគជ័យ។ ក្នុងករណីមានការរំខានដោយមិនបានរំពឹងទុកនៃដំណើរការថត យើងនឹងទទួលបានរដ្ឋកម្រិតមធ្យម ដែលបន្ទាប់មកយើងអាចរកឃើញ និងដំណើរការបាន។

វិធីសាស្រ្តនេះគឺគួរឱ្យចាប់អារម្មណ៍ប៉ុន្តែវាការពារតែការដាច់ចរន្តអគ្គិសនីភ្លាមៗនិងការបរាជ័យស្រដៀងគ្នាដែលជាការពិតណាស់មានសារៈសំខាន់ប៉ុន្តែនេះគឺនៅឆ្ងាយពីហេតុផលតែមួយគត់ (ឬសូម្បីតែសំខាន់) សម្រាប់ការបរាជ័យដែលអាចកើតមាន។

សង្ខេប៖ ចូរបន្តស្វែងរកដំណោះស្រាយដ៏ល្អ។

មូលប្បទានប័ត្រ

Checksums ក៏ធ្វើឱ្យវាអាចប្រាកដថា (ជាមួយនឹងប្រូបាប៊ីលីតេសមហេតុផល) ថាយើងកំពុងអានអ្វីដែលគួរត្រូវបានសរសេរ។ ហើយមិនដូចវាលប៊ីតដែលបានពិភាក្សាខាងលើទេ ពួកវាតែងតែដំណើរការ។

ប្រសិនបើយើងពិចារណាលើបញ្ជីនៃប្រភពសក្តានុពលនៃបញ្ហាដែលយើងបានពិភាក្សាខាងលើ នោះ checksum អាចទទួលស្គាល់កំហុសដោយមិនគិតពីប្រភពដើមរបស់វា (លើកលែងតែ ប្រហែលជាសម្រាប់ជនបរទេសដែលមានគំនិតអាក្រក់ - ពួកគេអាចក្លែងបន្លំមូលប្បទានប័ត្របានផងដែរ).

ដូច្នេះប្រសិនបើគោលដៅរបស់យើងគឺដើម្បីផ្ទៀងផ្ទាត់ថាទិន្នន័យនៅដដែលនោះ checksums គឺជាគំនិតដ៏ល្អ។

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

ឧទាហរណ៍នៃការសិក្សាបរិមាណ៖ ផ្នែកទី ២, ផ្នែកទី ២ (តំណភ្ជាប់ទៅ narod.ru សូមអភ័យទោស).

ទោះយ៉ាងណាក៏ដោយ ភារកិច្ចជ្រើសរើសមូលប្បទានប័ត្រមិនពេញលេញទេ CRC គឺជាគ្រួសារមូលប្បទានប័ត្រទាំងមូល។ អ្នកត្រូវសម្រេចចិត្តលើប្រវែង ហើយបន្ទាប់មកជ្រើសរើសពហុធា។

ការជ្រើសរើសប្រវែង checksum គឺមិនមែនជាសំណួរសាមញ្ញដូចដែលវាហាក់ដូចជានៅ glance ដំបូង។

ខ្ញុំសូមលើកឧទាហរណ៍៖
អនុញ្ញាតឱ្យយើងមានប្រូបាប៊ីលីតេនៃកំហុសក្នុងបៃនីមួយៗ និងការពិនិត្យដ៏ល្អមួយ ចូរយើងគណនាចំនួនមធ្យមនៃកំហុសក្នុងមួយលានកំណត់ត្រា៖

ទិន្នន័យ, បៃ
Checksum, បៃ
កំហុសដែលមិនបានរកឃើញ
ការរកឃើញកំហុសមិនពិត
វិជ្ជមានមិនពិតសរុប

1
0
1000
0
1000

1
1
4
999
1003

1
2
≈ xNUMX
1997
1997

1
4
≈ xNUMX
3990
3990

10
0
9955
0
9955

10
1
39
990
1029

10
2
≈ xNUMX
1979
1979

10
4
≈ xNUMX
3954
3954

1000
0
632305
0
632305

1000
1
2470
368
2838

1000
2
10
735
745

1000
4
≈ xNUMX
1469
1469

វាហាក់ដូចជាអ្វីៗទាំងអស់គឺសាមញ្ញ - អាស្រ័យលើប្រវែងនៃទិន្នន័យដែលត្រូវបានការពារ ជ្រើសរើសប្រវែងនៃ checksum ជាមួយនឹងអប្បរមានៃវិជ្ជមានមិនត្រឹមត្រូវ - ហើយល្បិចគឺនៅក្នុងកាបូប។

ទោះជាយ៉ាងណាក៏ដោយ បញ្ហាកើតឡើងជាមួយការឆែកឆេរខ្លីៗ៖ ទោះបីជាពួកគេល្អក្នុងការរកឃើញកំហុសប៊ីតតែមួយក៏ដោយ ពួកគេអាចជាមួយនឹងប្រូបាប៊ីលីតេខ្ពស់ក្នុងការទទួលយកទិន្នន័យចៃដន្យទាំងស្រុងថាត្រឹមត្រូវ។ មាន​អត្ថបទ​មួយ​រួច​ទៅ​ហើយ​នៅ​លើ Habre កំពុង​រៀប​រាប់ បញ្ហានៅក្នុងជីវិតពិត.

ដូច្នេះ ដើម្បីធ្វើឱ្យការផ្គូផ្គង checksum ចៃដន្យស្ទើរតែមិនអាចទៅរួច អ្នកត្រូវប្រើ checksums ដែលមានប្រវែង 32 ប៊ីត ឬយូរជាងនេះ។ (សម្រាប់ប្រវែងធំជាង 64 ប៊ីត មុខងារកូដសម្ងាត់ត្រូវបានប្រើជាធម្មតា).

ទោះបីជាការពិតដែលខ្ញុំបានសរសេរមុននេះថាយើងត្រូវសន្សំទំហំគ្រប់មធ្យោបាយក៏ដោយ យើងនឹងនៅតែប្រើ checksum 32-bit (16 bits មិនគ្រប់គ្រាន់ទេ ប្រូបាប៊ីលីតេនៃការប៉ះទង្គិចគឺច្រើនជាង 0.01% និង 24 bits ដូចដែលពួកគេ និយាយថាមិននៅទីនេះឬនៅទីនោះ) ។

ការជំទាស់អាចកើតឡើងនៅទីនេះ៖ តើយើងបានរក្សាទុករាល់បៃនៅពេលជ្រើសរើសការបង្ហាប់ដើម្បីផ្តល់ 4 បៃក្នុងពេលតែមួយទេ? តើវាមិនប្រសើរជាងកុំបង្ហាប់ ឬបន្ថែមមូលប្បទានប័ត្រទេ? ជាការពិតណាស់មិនមានការបង្ហាប់ទេ។ មិនមានន័យថាយើងមិនត្រូវការការត្រួតពិនិត្យសុចរិតភាពទេ។

នៅពេលជ្រើសរើសពហុនាម យើងនឹងមិនបង្កើតកង់ឡើងវិញទេ ប៉ុន្តែយក CRC-32C ដែលពេញនិយមឥឡូវនេះ។
លេខកូដនេះរកឃើញកំហុស 6 ប៊ីតនៅលើកញ្ចប់រហូតដល់ 22 បៃ (ប្រហែលជាករណីទូទៅបំផុតសម្រាប់យើង) កំហុស 4 ប៊ីតលើកញ្ចប់រហូតដល់ 655 បៃ (ក៏ជាករណីធម្មតាសម្រាប់យើង) 2 ឬចំនួនសេសនៃកំហុសប៊ីតណាមួយនៅលើកញ្ចប់ព័ត៌មាន នៃប្រវែងសមរម្យណាមួយ។

បើមានអ្នកណាចាប់អារម្មណ៍ ពត៌មានលំអិត

អត្ថបទវិគីភីឌា អំពី CRC ។

ប៉ារ៉ាម៉ែត្រកូដ CRC-32c នៅលើ គេហទំព័រ Koopman - ប្រហែលជាអ្នកឯកទេស CRC ឈានមុខគេនៅលើភពផែនដី។

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

ដូចគ្នានេះផងដែរ ដោយសារទិន្នន័យរបស់យើងត្រូវបានបង្ហាប់ សំណួរកើតឡើង៖ តើយើងគួរគណនាមូលប្បទានប័ត្រនៃទិន្នន័យដែលបានបង្ហាប់ ឬមិនបានបង្ហាប់ទេ?

អាគុយម៉ង់ក្នុងការពេញចិត្តនៃការគណនា checksum នៃទិន្នន័យដែលមិនបានបង្ហាប់៖

• ទីបំផុតយើងត្រូវពិនិត្យមើលសុវត្ថិភាពនៃការផ្ទុកទិន្នន័យ ដូច្នេះយើងពិនិត្យវាដោយផ្ទាល់ (ក្នុងពេលជាមួយគ្នានេះ កំហុសដែលអាចកើតមានក្នុងការអនុវត្តការបង្ហាប់/បង្រួម ការខូចខាតដែលបណ្តាលមកពីអង្គចងចាំខូច។ល។ នឹងត្រូវបានពិនិត្យ);
• ក្បួនដោះស្រាយ deflate នៅក្នុង zlib មានការអនុវត្តមានភាពចាស់ទុំ និង មិន​គួរ ធ្លាក់ចុះជាមួយនឹងទិន្នន័យបញ្ចូល "ច្រលំ" លើសពីនេះ វាជាញឹកញាប់អាចរកឃើញកំហុសនៅក្នុងស្ទ្រីមបញ្ចូលដោយឯករាជ្យ ដោយកាត់បន្ថយប្រូបាប៊ីលីតេទាំងមូលនៃការមិនអាចរកឃើញកំហុស (បានអនុវត្តការសាកល្បងជាមួយនឹងការដាក់បញ្ច្រាសបន្តិចក្នុងកំណត់ត្រាខ្លី zlib បានរកឃើញកំហុស ប្រហែលមួយភាគបីនៃករណី)។

អាគុយម៉ង់ប្រឆាំងនឹងការគណនា checksum នៃទិន្នន័យដែលមិនបានបង្ហាប់៖

• CRC ត្រូវបាន "កែសម្រួល" ជាពិសេសសម្រាប់កំហុសឆ្គងមួយចំនួនដែលជាលក្ខណៈនៃអង្គចងចាំពន្លឺ (កំហុសបន្តិចនៅក្នុងស្ទ្រីមដែលបានបង្ហាប់អាចបណ្តាលឱ្យមានការផ្លាស់ប្តូរដ៏ធំនៅក្នុងស្ទ្រីមទិន្នផល ដែលតាមទ្រឹស្តីសុទ្ធសាធ យើងអាច "ចាប់" ការប៉ះទង្គិចគ្នាបាន) ។
• ខ្ញុំពិតជាមិនចូលចិត្តគំនិតនៃការបញ្ជូនទិន្នន័យដែលខូចសក្តានុពលទៅឧបករណ៍ decompressor ទេ អ្នកណាដឹងតើគាត់នឹងមានប្រតិកម្មយ៉ាងណា។

ក្នុង​គម្រោង​នេះ ខ្ញុំ​បាន​សម្រេច​ចិត្ត​ងាក​ចេញ​ពី​ការ​អនុវត្ត​ដែល​ទទួល​បាន​ជា​ទូទៅ​ក្នុង​ការ​រក្សាទុក​ទិន្នន័យ​ដែល​មិន​បាន​បង្ហាប់។

សង្ខេប៖ យើងប្រើ CRC-32C យើងគណនា checksum ពីទិន្នន័យក្នុងទម្រង់ដែលពួកគេត្រូវបានសរសេរទៅ flash (បន្ទាប់ពីការបង្ហាប់) ។

លែងត្រូវការតទៅទៀត។

ជាការពិតណាស់ ការប្រើប្រាស់ការសរសេរកូដដដែលៗមិនលុបបំបាត់ការបាត់បង់ទិន្នន័យនោះទេ ទោះជាយ៉ាងណាក៏ដោយ វាអាចកាត់បន្ថយយ៉ាងខ្លាំង (ជាញឹកញាប់ដោយការបញ្ជាទិញច្រើន) កាត់បន្ថយលទ្ធភាពនៃការបាត់បង់ទិន្នន័យដែលមិនអាចយកមកវិញបាន។

យើង​អាច​ប្រើ​ប្រភេទ​ផ្សេង​គ្នា​នៃ​ការ​ប្រើ​ដដែលៗ​ដើម្បី​កែ​កំហុស។
លេខកូដ Hamming អាចកែកំហុសប៊ីតតែមួយ កូដតួអក្សរ Reed-Solomon ច្បាប់ចម្លងទិន្នន័យជាច្រើនដែលរួមបញ្ចូលគ្នាជាមួយនឹងការឆែកឆេរ ឬការអ៊ិនកូដដូចជា RAID-6 អាចជួយស្ដារទិន្នន័យឡើងវិញ សូម្បីតែក្នុងករណីមានអំពើពុករលួយដ៏ធំក៏ដោយ។
ដំបូងឡើយ ខ្ញុំបានប្តេជ្ញាចិត្តចំពោះការប្រើប្រាស់យ៉ាងទូលំទូលាយនៃការសរសេរកូដដែលធន់ទ្រាំនឹងកំហុស ប៉ុន្តែបន្ទាប់មកខ្ញុំបានដឹងថាដំបូងយើងត្រូវមានគំនិតអំពីអ្វីដែលយើងចង់ការពារខ្លួនយើងពីកំហុស ហើយបន្ទាប់មកជ្រើសរើសការសរសេរកូដ។

យើងបាននិយាយមុននេះថា កំហុសចាំបាច់ត្រូវចាប់ឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន។ តើ​យើង​អាច​ជួប​បញ្ហា​ត្រង់​ចំណុច​ណា​ខ្លះ?

1. ការថតមិនទាន់ចប់ (សម្រាប់ហេតុផលមួយចំនួននៅពេលថតថាមពលត្រូវបានបិទ Raspberry បង្កក ... )
   Alas, នៅក្នុងព្រឹត្តិការណ៍នៃកំហុសបែបនេះ, អ្វីទាំងអស់ដែលនៅសល់គឺដើម្បីមិនអើពើកំណត់ត្រាមិនត្រឹមត្រូវនិងពិចារណាទិន្នន័យដែលបានបាត់បង់;
2. សរសេរកំហុស (សម្រាប់ហេតុផលមួយចំនួនអ្វីដែលត្រូវបានសរសេរទៅអង្គចងចាំពន្លឺមិនមែនជាអ្វីដែលត្រូវបានសរសេរ)
   យើង​អាច​រក​ឃើញ​កំហុស​បែប​នេះ​ភ្លាមៗ​ប្រសិន​បើ​យើង​ធ្វើ​តេស្ត​អាន​ភ្លាមៗ​បន្ទាប់​ពី​ថត។
3. ការបង្ខូចទ្រង់ទ្រាយទិន្នន័យនៅក្នុងអង្គចងចាំអំឡុងពេលផ្ទុក;
4. កំហុសក្នុងការអាន
   ដើម្បីកែវា ប្រសិនបើ checksum មិនត្រូវគ្នា វាគ្រប់គ្រាន់ក្នុងការអានឡើងវិញច្រើនដង។

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

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

Прочее

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

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

បានជួយច្រើន។ ម៉ាស៊ីនភ្លើងតាមអ៊ីនធឺណិត លេខកូដ Huffman ។ ក្នុងរយៈពេលតែប៉ុន្មាននាទីប៉ុណ្ណោះ យើងអាចជ្រើសរើសកូដប្រវែងអថេរដែលត្រូវការ។

ការពិពណ៌នាអំពីទ្រង់ទ្រាយផ្ទុកទិន្នន័យ

លំដាប់បៃ

វាលដែលធំជាងមួយបៃត្រូវបានរក្សាទុកជាទម្រង់ big-endian (លំដាប់បៃបណ្តាញ) ពោលគឺ 0x1234 ត្រូវបានសរសេរជា 0x12, 0x34។

ការបិទភ្ជាប់

អង្គចងចាំពន្លឺទាំងអស់ត្រូវបានបែងចែកទៅជាទំព័រដែលមានទំហំស្មើគ្នា។

ទំហំទំព័រលំនាំដើមគឺ 32Kb ប៉ុន្តែមិនលើសពី 1/4 នៃទំហំសរុបនៃបន្ទះឈីបអង្គចងចាំ (សម្រាប់បន្ទះឈីប 4MB ទទួលបាន 128 ទំព័រ)។

ទំព័រនីមួយៗរក្សាទុកទិន្នន័យដោយឯករាជ្យពីទំព័រផ្សេងទៀត (នោះគឺទិន្នន័យនៅលើទំព័រមួយមិនយោងទិន្នន័យនៅលើទំព័រផ្សេងទៀត)។

ទំព័រទាំងអស់ត្រូវបានដាក់លេខតាមលំដាប់ធម្មជាតិ (តាមលំដាប់ឡើងនៃអាស័យដ្ឋាន) ដោយចាប់ផ្តើមដោយលេខ 0 (ទំព័រសូន្យចាប់ផ្តើមនៅអាសយដ្ឋាន 0 ទំព័រទីមួយចាប់ផ្តើមនៅ 32Kb ទំព័រទីពីរចាប់ផ្តើមនៅ 64Kb ។ល។)

បន្ទះឈីបអង្គចងចាំត្រូវបានគេប្រើជាសតិបណ្ដោះអាសន្នរង្វិល (ring buffer) ពោលគឺការសរសេរដំបូងទៅកាន់ទំព័រលេខ 0 បន្ទាប់មកលេខ 1, ... នៅពេលដែលយើងបំពេញទំព័រចុងក្រោយ វដ្តថ្មីមួយចាប់ផ្តើម ហើយការថតបន្តពីទំព័រសូន្យ។ .

នៅខាងក្នុងទំព័រ

នៅដើមទំព័រ បឋមកថាទំព័រ 4 បៃត្រូវបានរក្សាទុក បន្ទាប់មកពិនិត្យបឋមកថា (CRC-32C) បន្ទាប់មកកំណត់ត្រាត្រូវបានរក្សាទុកក្នុងទម្រង់ "បឋមកថា ទិន្នន័យ មូលប្បទានប័ត្រ" ។

ចំណងជើងទំព័រ (ពណ៌បៃតងកខ្វក់នៅក្នុងដ្យាក្រាម) មាន៖

• វាលលេខវេទមន្តពីរបៃ (ក៏ជាសញ្ញានៃកំណែទម្រង់)
  សម្រាប់កំណែបច្ចុប្បន្ននៃទ្រង់ទ្រាយវាត្រូវបានគណនាជា 0xed00 ⊕ номер страницы;
• ការរាប់ពីរបៃ "កំណែទំព័រ" (លេខវដ្តសរសេរឡើងវិញអង្គចងចាំ) ។

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

កំណត់ត្រានីមួយៗនឹងត្រូវបានបង្ហាប់ដោយទង់ Z_SYNC_FLUSH ហើយនៅចុងបញ្ចប់នៃស្ទ្រីមដែលបានបង្ហាប់នឹងមាន 4 បៃ 0x00, 0x00, 0xff, 0xff ដែលអាចនាំមុខដោយសូន្យបៃមួយ ឬពីរទៀត។
យើងបោះបង់លំដាប់នេះ (ប្រវែង 4, 5 ឬ 6 បៃ) នៅពេលសរសេរទៅអង្គចងចាំពន្លឺ។

ក្បាលកំណត់ត្រាគឺ 1, 2 ឬ 3 បៃរក្សាទុក៖

• មួយប៊ីត (T) បង្ហាញពីប្រភេទនៃកំណត់ត្រា: 0 - បរិបទ, 1 - កំណត់ហេតុ;
• វាលប្រវែងអថេរ (S) ពី 1 ទៅ 7 ប៊ីត កំណត់ប្រវែងនៃបឋមកថា និង "កន្ទុយ" ដែលត្រូវតែបន្ថែមទៅក្នុងកំណត់ត្រាសម្រាប់ការបង្រួម។
• ប្រវែងកំណត់ត្រា (L) ។

តារាងតម្លៃ៖

S
ប្រវែងបឋមកថា, បៃ
បោះបង់ចោលនៅពេលសរសេរ, បៃ

0
1
5 (00 00 00 ff ff)

10
1
6 (00 00 00 00 ff ff)

110
2
4 (00 00 ff ff)

1110
2
5 (00 00 00 ff ff)

11110
2
6 (00 00 00 00 ff ff)

1111100
3
4 (00 00 ff ff)

1111101
3
5 (00 00 00 ff ff)

1111110
3
6 (00 00 00 00 ff ff)

ខ្ញុំ​បាន​ព្យាយាម​បង្ហាញ ខ្ញុំ​មិន​ដឹង​ច្បាស់​ថា​វា​បង្ហាញ​យ៉ាង​ណា​ទេ៖

ពណ៌លឿងនៅទីនេះបង្ហាញពីវាល T, វាល S ពណ៌ស, ពណ៌បៃតង L (ប្រវែងនៃទិន្នន័យដែលបានបង្ហាប់ជាបៃ) ពណ៌ខៀវនៃទិន្នន័យដែលបានបង្ហាប់ ពណ៌ក្រហមនៃបៃចុងក្រោយនៃទិន្នន័យដែលបានបង្ហាប់ដែលមិនត្រូវបានសរសេរទៅអង្គចងចាំពន្លឺ។

ដូច្នេះយើងអាចសរសេរបឋមកថានៃប្រវែងទូទៅបំផុត (រហូតដល់ 63 + 5 បៃក្នុងទម្រង់បង្ហាប់) ក្នុងមួយបៃ។

បន្ទាប់ពីកំណត់ត្រានីមួយៗ មូលប្បទានប័ត្រ CRC-32C ត្រូវបានរក្សាទុក ដែលក្នុងនោះតម្លៃដាក់បញ្ច្រាសនៃ checksum មុនត្រូវបានប្រើជាតម្លៃដំបូង (init) ។

CRC មានទ្រព្យសម្បត្តិនៃ "រយៈពេល" រូបមន្តខាងក្រោមដំណើរការ (បូកឬដកការបញ្ច្រាសប៊ីតនៅក្នុងដំណើរការ)៖ .
នោះជាការពិត យើងគណនា CRC នៃបៃមុនទាំងអស់នៃបឋមកថា និងទិន្នន័យនៅលើទំព័រនេះ។

ដោយផ្ទាល់តាម checksum គឺជាបឋមកថានៃកំណត់ត្រាបន្ទាប់។

បឋមកថាត្រូវបានរចនាឡើងតាមរបៀបដែលបៃទីមួយរបស់វាតែងតែខុសពី 0x00 និង 0xff (ប្រសិនបើជំនួសឱ្យបៃទីមួយនៃបឋមកថាយើងជួប 0xff នោះមានន័យថានេះជាតំបន់ដែលមិនប្រើ 0x00 បង្ហាញកំហុស)។

ក្បួនដោះស្រាយឧទាហរណ៍

ការអានពី Flash Memory

ការអានណាមួយមកជាមួយការឆែកឆេរ។
ប្រសិនបើ checksum មិនផ្គូផ្គង ការអានត្រូវបានធ្វើម្តងទៀតច្រើនដងដោយសង្ឃឹមថានឹងអានទិន្នន័យត្រឹមត្រូវ។

(វាសមហេតុផល លីនុចមិនប្រើឃ្លាំងសម្ងាត់អានពី NOR Flash សាកល្បងទេ)

សរសេរទៅអង្គចងចាំពន្លឺ

យើងកត់ត្រាទិន្នន័យ។
តោះអានពួកគេ។

ប្រសិនបើទិន្នន័យដែលបានអានមិនត្រូវគ្នានឹងទិន្នន័យដែលបានសរសេរនោះ យើងបំពេញផ្ទៃដោយលេខសូន្យ ហើយបង្ហាញសញ្ញាអំពីកំហុស។

កំពុងរៀបចំ microcircuit ថ្មីសម្រាប់ប្រតិបត្តិការ

សម្រាប់ការចាប់ផ្តើម បឋមកថាដែលមានកំណែ 1 ត្រូវបានសរសេរទៅទំព័រដំបូង (ឬសូន្យ)។
បន្ទាប់ពីនោះ បរិបទដំបូងត្រូវបានសរសេរទៅកាន់ទំព័រនេះ (មាន UUID របស់ម៉ាស៊ីន និងការកំណត់លំនាំដើម)។

នោះហើយជាវាអង្គចងចាំពន្លឺគឺរួចរាល់សម្រាប់ការប្រើប្រាស់។

កំពុងផ្ទុកម៉ាស៊ីន

នៅពេលផ្ទុក 8 បៃដំបូងនៃទំព័រនីមួយៗ (បឋមកថា + CRC) ត្រូវបានអាន ទំព័រដែលមានលេខវេទមន្តមិនស្គាល់ ឬ CRC មិនត្រឹមត្រូវមិនត្រូវបានអើពើ។
ពីទំព័រ "ត្រឹមត្រូវ" ទំព័រដែលមានកំណែអតិបរិមាត្រូវបានជ្រើសរើស ហើយទំព័រដែលមានលេខខ្ពស់បំផុតត្រូវបានយកចេញពីពួកគេ។
កំណត់ត្រាដំបូងត្រូវបានអាន ភាពត្រឹមត្រូវនៃកាកបាទក្រហមកម្ពុជា និងវត្តមាននៃទង់ "បរិបទ" ត្រូវបានពិនិត្យ។ ប្រសិនបើអ្វីៗគ្រប់យ៉ាងល្អ ទំព័រនេះត្រូវបានចាត់ទុកថាបច្ចុប្បន្ន។ បើមិនដូច្នោះទេ យើងត្រលប់ទៅទំព័រមុនវិញ រហូតដល់យើងរកឃើញទំព័រ "ផ្ទាល់"។
ហើយនៅលើទំព័រដែលបានរកឃើញ យើងអានកំណត់ត្រាទាំងអស់ ដែលយើងប្រើជាមួយទង់ "បរិបទ"។
រក្សាទុកវចនានុក្រម zlib (វានឹងត្រូវការសម្រាប់ការបន្ថែមទៅទំព័រនេះ)។

នោះហើយជាវា ការទាញយកបានបញ្ចប់ បរិបទត្រូវបានស្ដារឡើងវិញ អ្នកអាចដំណើរការបាន។

ការបន្ថែមធាតុទិនានុប្បវត្តិ

យើងបង្ហាប់កំណត់ត្រាដោយប្រើវចនានុក្រមត្រឹមត្រូវ ដោយបញ្ជាក់ Z_SYNC_FLUSH ។ យើងមើលថាតើកំណត់ត្រាដែលបានបង្ហាប់សមនឹងនៅលើទំព័របច្ចុប្បន្នដែរឬទេ។
ប្រសិនបើវាមិនសម (ឬមានកំហុស CRC នៅលើទំព័រ) សូមចាប់ផ្តើមទំព័រថ្មី (សូមមើលខាងក្រោម)។
យើងសរសេរកំណត់ហេតុ និងកាកបាទក្រហមកម្ពុជា ។ ប្រសិនបើមានកំហុសកើតឡើង សូមចាប់ផ្តើមទំព័រថ្មី។

ទំព័រថ្មី។

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

ភាពអាចអនុវត្តបាននៃទម្រង់

តាមគំនិតរបស់ខ្ញុំ វាប្រែទៅជាទម្រង់ដ៏ល្អសម្រាប់រក្សាទុកស្ទ្រីមព័ត៌មានដែលអាចបង្ហាប់បានច្រើន ឬតិច (អត្ថបទធម្មតា JSON, MessagePack, CBOR អាចជា protobuf) នៅក្នុង NOR Flash ។

ជា​ការ​ពិត​ណាស់ ទ្រង់ទ្រាយ​ត្រូវ​បាន "តម្រូវ​តាម" សម្រាប់ SLC NOR Flash ។

វាមិនគួរប្រើជាមួយមេឌៀ BER ខ្ពស់ដូចជា NAND ឬ MLC NOR ទេ។ (តើអង្គចងចាំបែបនេះមានសម្រាប់លក់ទេ?.

លើសពីនេះទៅទៀត វាមិនគួរប្រើជាមួយឧបករណ៍ដែលមាន FTL ផ្ទាល់ខ្លួននោះទេ៖ USB flash, SD, MicroSD ជាដើម។ (សម្រាប់អង្គចងចាំបែបនេះ ខ្ញុំបានបង្កើតទម្រង់ដែលមានទំហំទំព័រ 512 បៃ ហត្ថលេខានៅដើមទំព័រនីមួយៗ និងលេខកំណត់ត្រាតែមួយគត់ - ពេលខ្លះវាអាចទៅរួចក្នុងការសង្គ្រោះទិន្នន័យទាំងអស់ពី flash drive "មិនប្រក្រតី" ដោយការអានតាមលំដាប់លំដោយសាមញ្ញ).

អាស្រ័យលើភារកិច្ច ទ្រង់ទ្រាយអាចប្រើដោយគ្មានការផ្លាស់ប្តូរនៅលើ flash drives ពី 128Kbit (16Kb) ទៅ 1Gbit (128MB)។ ប្រសិនបើចង់បាន អ្នកអាចប្រើវានៅលើបន្ទះសៀគ្វីធំជាង ប៉ុន្តែអ្នកប្រហែលជាត្រូវកែតម្រូវទំហំទំព័រ (ប៉ុន្តែនៅទីនេះសំណួរនៃលទ្ធភាពសេដ្ឋកិច្ចបានកើតឡើងរួចហើយ តម្លៃសម្រាប់បរិមាណធំ NOR Flash មិនលើកទឹកចិត្តទេ).

ប្រសិនបើនរណាម្នាក់រកឃើញទម្រង់គួរឱ្យចាប់អារម្មណ៍ ហើយចង់ប្រើវានៅក្នុងគម្រោងបើកចំហ សរសេរ ខ្ញុំនឹងព្យាយាមស្វែងរកពេលវេលា ដុសខាត់កូដ ហើយបង្ហោះវានៅលើ github ។

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

ដូចដែលអ្នកអាចឃើញនៅទីបញ្ចប់ទ្រង់ទ្រាយប្រែទៅជាសាមញ្ញ និងសូម្បីតែគួរឱ្យធុញ.

វាពិបាកក្នុងការឆ្លុះបញ្ចាំងពីការវិវត្តនៃទស្សនៈរបស់ខ្ញុំនៅក្នុងអត្ថបទមួយ ប៉ុន្តែជឿខ្ញុំ៖ ដំបូងខ្ញុំចង់បង្កើតអ្វីដែលទំនើប មិនអាចបំផ្លាញបាន មានសមត្ថភាពរស់រានមានជីវិត សូម្បីតែការផ្ទុះនុយក្លេអ៊ែរនៅជិតៗក៏ដោយ។ ទោះជាយ៉ាងណាក៏ដោយហេតុផល (ខ្ញុំសង្ឃឹមថា) នៅតែឈ្នះ ហើយអាទិភាពបន្តិចម្តងៗបានផ្លាស់ប្តូរឆ្ពោះទៅរកភាពសាមញ្ញ និងបង្រួម។

វាអាចថាខ្ញុំខុស? ប្រាកដហើយ។ ជាឧទាហរណ៍ វាអាចនឹងប្រែក្លាយថាយើងបានទិញបណ្តុំនៃ microcircuits ដែលមានគុណភាពទាប។ ឬសម្រាប់ហេតុផលផ្សេងទៀត ឧបករណ៍នឹងមិនបំពេញតាមការរំពឹងទុកដែលអាចជឿជាក់បាន។

តើខ្ញុំមានគម្រោងសម្រាប់រឿងនេះទេ? ខ្ញុំ​គិត​ថា​បន្ទាប់​ពី​បាន​អាន​អត្ថបទ​អ្នក​មិន​មាន​ការ​សង្ស័យ​ទេ​ថា​មាន​ផែនការ​មួយ​។ ហើយមិនមែនតែម្នាក់ឯងទេ។

នៅលើកំណត់ចំណាំដ៏ធ្ងន់ធ្ងរជាងនេះបន្តិច ទម្រង់ត្រូវបានបង្កើតឡើងទាំងជាជម្រើសធ្វើការ និងជា "ប៉េងប៉ោងសាកល្បង"។

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

ប្រសិនបើផ្អែកលើលទ្ធផលនៃការប្រើប្រាស់ បញ្ហាធ្ងន់ធ្ងរត្រូវបានរកឃើញ ហើយការកែលម្អត្រូវបានទាមទារ នោះខ្ញុំនឹងសរសេរអំពីវា។

អក្សរសាស្រ្ត

ខ្ញុំ​មិន​ចង់​បង្កើត​បញ្ជី​ការងារ​ដែល​បាន​ប្រើ​យូរ​គួរ​ឱ្យ​ធុញទ្រាន់​ទេ បន្ទាប់​មក អ្នក​រាល់​គ្នា​មាន Google ។

នៅទីនេះខ្ញុំបានសម្រេចចិត្តចាកចេញពីបញ្ជីនៃការរកឃើញដែលហាក់ដូចជាគួរឱ្យចាប់អារម្មណ៍ជាពិសេសសម្រាប់ខ្ញុំ ប៉ុន្តែបន្តិចម្ដងៗពួកគេបានធ្វើចំណាកស្រុកដោយផ្ទាល់ទៅក្នុងអត្ថបទនៃអត្ថបទ ហើយធាតុមួយនៅតែស្ថិតក្នុងបញ្ជី៖

1. ឧបករណ៍ប្រើប្រាស់ infgen ពីអ្នកនិពន្ធ zlib ។ អាចបង្ហាញខ្លឹមសារនៃបណ្ណសារ deflate/zlib/gzip យ៉ាងច្បាស់។ ប្រសិនបើអ្នកត្រូវដោះស្រាយជាមួយរចនាសម្ព័ន្ធខាងក្នុងនៃទម្រង់ deflate (ឬ gzip) ខ្ញុំសូមណែនាំវាយ៉ាងខ្លាំង។

ប្រភព: www.habr.com