ປະວັດສາດ

ມີເຄື່ອງຂາຍຂອງການອອກແບບຂອງພວກເຮົາເອງ. ພາຍໃນ Raspberry Pi ແລະສາຍໄຟບາງອັນຢູ່ໃນກະດານແຍກຕ່າງຫາກ. ເຄື່ອງຮັບຫຼຽນ, ໃບຮັບເງິນ, ສະຖານີທະນາຄານຖືກເຊື່ອມຕໍ່ ... ທຸກສິ່ງທຸກຢ່າງແມ່ນຄວບຄຸມໂດຍໂຄງການຂຽນດ້ວຍຕົນເອງ. ປະຫວັດການເຮັດວຽກທັງຫມົດຖືກຂຽນໄວ້ໃນບັນທຶກໃນ flash drive (MicroSD), ເຊິ່ງຖືກສົ່ງຜ່ານອິນເຕີເນັດ (ໃຊ້ໂມເດັມ USB) ໄປຫາເຄື່ອງແມ່ຂ່າຍ, ບ່ອນທີ່ມັນຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນ. ຂໍ້ມູນການຂາຍຖືກໂຫລດເຂົ້າໄປໃນ 1c, ຍັງມີການໂຕ້ຕອບເວັບໄຊຕ໌ທີ່ງ່າຍດາຍສໍາລັບການຕິດຕາມ, ແລະອື່ນໆ.

ນັ້ນແມ່ນ, ວາລະສານແມ່ນມີຄວາມສໍາຄັນ - ສໍາລັບການບັນຊີ (ລາຍຮັບ, ການຂາຍ, ແລະອື່ນໆ), ການຕິດຕາມ (ທຸກປະເພດຂອງຄວາມລົ້ມເຫລວແລະສະຖານະການອື່ນໆທີ່ບັງຄັບໃຊ້); ນີ້, ຫນຶ່ງອາດຈະເວົ້າວ່າ, ແມ່ນຂໍ້ມູນທັງຫມົດທີ່ພວກເຮົາມີກ່ຽວກັບເຄື່ອງນີ້.

ບັນຫາ

Flash drives ສະແດງຕົວເອງວ່າເປັນອຸປະກອນທີ່ບໍ່ຫນ້າເຊື່ອຖືຫຼາຍ. ພວກ​ເຂົາ​ເຈົ້າ​ລົ້ມ​ເຫຼວ​ກັບ​ຄວາມ​ເປັນ​ປົກ​ກະ​ຕິ enviable. ນີ້ເຮັດໃຫ້ທັງສອງເຄື່ອງຢຸດເຮັດວຽກແລະ (ຖ້າສໍາລັບເຫດຜົນບາງຢ່າງ, ບັນທຶກບໍ່ສາມາດຖືກໂອນອອນໄລນ໌) ກັບການສູນເສຍຂໍ້ມູນ.

ນີ້ບໍ່ແມ່ນປະສົບການຄັ້ງທໍາອິດຂອງການນໍາໃຊ້ flash drive, ກ່ອນຫນ້ານີ້ມີໂຄງການອື່ນທີ່ມີຫຼາຍກ່ວາຮ້ອຍອຸປະກອນ, ບ່ອນທີ່ວາລະສານຖືກເກັບໄວ້ໃນ USB flash drive, ຍັງມີບັນຫາກ່ຽວກັບຄວາມຫນ້າເຊື່ອຖື, ບາງຄັ້ງຈໍານວນຂອງຜູ້ທີ່ລົ້ມເຫລວໃນ. ເດືອນໜຶ່ງຢູ່ໃນຫຼາຍສິບຄົນ. ພວກເຮົາໄດ້ພະຍາຍາມ flash drive ທີ່ແຕກຕ່າງກັນ, ລວມທັງຍີ່ຫໍ້ທີ່ມີຫນ່ວຍຄວາມຈໍາ SLC, ແລະບາງຮຸ່ນມີຄວາມຫນ້າເຊື່ອຖືຫຼາຍກ່ວາຄົນອື່ນ, ແຕ່ການປ່ຽນ flash drives ບໍ່ໄດ້ແກ້ໄຂບັນຫາຢ່າງຫຼວງຫຼາຍ.

ລະ​ມັດ​ລະ​ວັງ ອ່ານແລ້ວ! ຖ້າທ່ານບໍ່ສົນໃຈໃນ "ເປັນຫຍັງ", ແຕ່ວ່າພຽງແຕ່ "ເຮັດແນວໃດ", ທ່ານສາມາດໄປກົງ ໃນທີ່ສຸດ ບົດຄວາມ.

ການຕັດສິນໃຈ

ສິ່ງທໍາອິດທີ່ຢູ່ໃນໃຈແມ່ນ: ຍົກເລີກ MicroSD, ຕິດຕັ້ງ, ຕົວຢ່າງ, SSD, ແລະ boot ຈາກມັນ. ເປັນໄປໄດ້ທາງທິດສະດີ, ອາດຈະເປັນ, ແຕ່ຂ້ອນຂ້າງແພງ, ແລະບໍ່ຫນ້າເຊື່ອຖືໄດ້ (ອະແດບເຕີ USB-SATA ໄດ້ຖືກເພີ່ມ; ສະຖິຕິຄວາມລົ້ມເຫຼວສໍາລັບ SSDs ງົບປະມານແມ່ນບໍ່ສະຫນັບສະຫນູນ).

USB HDD ຍັງບໍ່ເບິ່ງຄືວ່າເປັນການແກ້ໄຂທີ່ຫນ້າສົນໃຈໂດຍສະເພາະ.

ດັ່ງນັ້ນ, ພວກເຮົາມາຮອດທາງເລືອກນີ້: ອອກຈາກການ booting ຈາກ MicroSD, ແຕ່ໃຊ້ພວກມັນໃນຮູບແບບອ່ານເທົ່ານັ້ນ, ແລະເກັບຮັກສາບັນທຶກການເຮັດວຽກ (ແລະຂໍ້ມູນອື່ນໆທີ່ເປັນເອກະລັກສະເພາະຂອງຮາດແວບາງສ່ວນ - ເລກລໍາດັບ, ການປັບຕົວເຊັນເຊີ, ແລະອື່ນໆ) ຢູ່ບ່ອນອື່ນ. .

ຫົວຂໍ້ຂອງ FS ອ່ານເທົ່ານັ້ນສໍາລັບ raspberries ໄດ້ຖືກສຶກສາແລ້ວໃນແລະນອກ, ຂ້າພະເຈົ້າຈະບໍ່ຢູ່ໃນລາຍລະອຽດການປະຕິບັດໃນບົດຄວາມນີ້. (ແຕ່ຖ້າມີຄວາມສົນໃຈ, ບາງທີຂ້ອຍຈະຂຽນບົດຄວາມນ້ອຍໆກ່ຽວກັບຫົວຂໍ້ນີ້). ຈຸດດຽວທີ່ຂ້ອຍຢາກສັງເກດແມ່ນວ່າທັງຈາກປະສົບການສ່ວນຕົວແລະຈາກການທົບທວນຄືນຂອງຜູ້ທີ່ໄດ້ປະຕິບັດແລ້ວ, ມີຄວາມຫນ້າເຊື່ອຖື. ແມ່ນແລ້ວ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະກໍາຈັດການແຕກຫັກຢ່າງສົມບູນ, ແຕ່ການຫຼຸດຜ່ອນຄວາມຖີ່ຂອງພວກເຂົາຢ່າງຫຼວງຫຼາຍແມ່ນເປັນໄປໄດ້. ແລະບັດໄດ້ກາຍເປັນເອກະພາບ, ເຊິ່ງເຮັດໃຫ້ການທົດແທນທີ່ງ່າຍຂຶ້ນຫຼາຍສໍາລັບພະນັກງານບໍລິການ.

Hardware

ບໍ່ມີຄວາມສົງໃສໂດຍສະເພາະກ່ຽວກັບການເລືອກປະເພດຂອງຫນ່ວຍຄວາມຈໍາ - NOR Flash.
ການໂຕ້ຖຽງ:

• ການເຊື່ອມຕໍ່ແບບງ່າຍໆ (ສ່ວນຫຼາຍແມ່ນລົດເມ SPI, ທີ່ທ່ານມີປະສົບການໃຊ້ແລ້ວ, ດັ່ງນັ້ນບໍ່ມີບັນຫາກ່ຽວກັບຮາດແວແມ່ນຄາດຄະເນ);
• ລາຄາ ridiculous;
• ໂປໂຕຄອນປະຕິບັດການມາດຕະຖານ (ການຈັດຕັ້ງປະຕິບັດແມ່ນຢູ່ໃນເຄີເນລແລ້ວ) Linux, ຖ້າທ່ານຕ້ອງການ, ທ່ານສາມາດໃຊ້ພາກສ່ວນທີສາມ, ເຊິ່ງຍັງມີຢູ່, ຫຼືແມ່ນແຕ່ຂຽນຂອງທ່ານເອງ, ໂຊກດີ, ທຸກຢ່າງແມ່ນງ່າຍດາຍ);
• ຄວາມຫນ້າເຊື່ອຖືແລະຊັບພະຍາກອນ:
  ຈາກ​ແຜ່ນ​ຂໍ້​ມູນ​ປົກ​ກະ​ຕິ​: ຂໍ້​ມູນ​ແມ່ນ​ເກັບ​ຮັກ​ສາ​ໄວ້​ສໍາ​ລັບ 20 ປີ​, 100000 erase cycles ສໍາ​ລັບ​ແຕ່​ລະ​ຕັນ​;
  ຈາກແຫຼ່ງພາກສ່ວນທີສາມ: BER ຕ່ໍາທີ່ສຸດ, postulates ບໍ່ຈໍາເປັນຕ້ອງສໍາລັບລະຫັດການແກ້ໄຂຄວາມຜິດພາດ (ບາງວຽກພິຈາລະນາ ECC ສໍາລັບ NOR, ແຕ່ປົກກະຕິແລ້ວພວກມັນຍັງຫມາຍຄວາມວ່າ MLC NOR; ນີ້ກໍ່ເກີດຂຶ້ນ).

ໃຫ້ປະເມີນຄວາມຕ້ອງການສໍາລັບປະລິມານແລະຊັບພະຍາກອນ.

ຂ້ອຍຢາກໃຫ້ຂໍ້ມູນຖືກຮັບປະກັນວ່າຈະຖືກບັນທຶກໄວ້ເປັນເວລາຫຼາຍມື້. ນີ້ແມ່ນມີຄວາມຈໍາເປັນເພື່ອວ່າໃນກໍລະນີຂອງບັນຫາໃດໆກັບການສື່ສານ, ປະຫວັດການຂາຍບໍ່ໄດ້ສູນເສຍ. ພວກເຮົາຈະສຸມໃສ່ 5 ມື້, ໃນໄລຍະນີ້ (ເຖິງ​ແມ່ນ​ວ່າ​ຄໍາ​ນຶງ​ເຖິງ​ທ້າຍ​ອາ​ທິດ​ແລະ​ວັນ​ພັກ​) ບັນຫາສາມາດແກ້ໄຂໄດ້.

ໃນປັດຈຸບັນພວກເຮົາເກັບກໍາປະມານ 100kb ຂອງບັນທຶກຕໍ່ມື້ (3-4 ພັນລາຍການ), ແຕ່ຄ່ອຍໆຕົວເລກນີ້ແມ່ນການຂະຫຍາຍຕົວ - ລາຍລະອຽດແມ່ນເພີ່ມຂຶ້ນ, ເຫດການໃຫມ່ກໍາລັງຖືກເພີ່ມ. ນອກຈາກນັ້ນ, ບາງຄັ້ງກໍ່ມີການລະເບີດ (ບາງເຊັນເຊີເລີ່ມຕົ້ນ spamming ກັບຜົນບວກທີ່ບໍ່ຖືກຕ້ອງ, ສໍາລັບການຍົກຕົວຢ່າງ). ພວກເຮົາຈະຄິດໄລ່ສໍາລັບ 10 ພັນບັນທຶກ 100 bytes ແຕ່ລະຄົນ - megabytes ຕໍ່ມື້.

ໃນຈໍານວນທັງຫມົດ, 5MB ຂອງຂໍ້ມູນທີ່ສະອາດ (ຖືກບີບອັດດີ) ອອກມາ. ເພີ່ມເຕີມຕໍ່ກັບເຂົາເຈົ້າ (ການ​ຄາດ​ຄະ​ເນ​ໂດຍ​ກົງ​) 1MB ຂອງຂໍ້ມູນການບໍລິການ.

ນັ້ນແມ່ນ, ພວກເຮົາຕ້ອງການຊິບ 8MB ຖ້າພວກເຮົາບໍ່ໃຊ້ການບີບອັດ, ຫຼື 4MB ຖ້າພວກເຮົາໃຊ້ມັນ. ຕົວເລກທີ່ແທ້ຈິງສໍາລັບປະເພດຂອງຄວາມຊົງຈໍານີ້.

ສໍາລັບຊັບພະຍາກອນ: ຖ້າພວກເຮົາວາງແຜນວ່າຫນ່ວຍຄວາມຈໍາທັງຫມົດຈະຖືກຂຽນຄືນໃຫມ່ບໍ່ເກີນຫນຶ່ງຄັ້ງໃນທຸກໆ 5 ມື້, ຫຼັງຈາກນັ້ນຫຼາຍກວ່າ 10 ປີຂອງການບໍລິການພວກເຮົາໄດ້ຮັບຫນ້ອຍກວ່າຫນຶ່ງພັນຮອບການຂຽນຄືນໃຫມ່.
ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າຜູ້ຜະລິດສັນຍາຫນຶ່ງຮ້ອຍພັນ.

ເລັກນ້ອຍກ່ຽວກັບ NOR vs NAND

ມື້ນີ້, ແນ່ນອນ, ຄວາມຊົງຈໍາ NAND ແມ່ນມີຄວາມນິຍົມຫຼາຍ, ແຕ່ຂ້ອຍບໍ່ໄດ້ໃຊ້ມັນສໍາລັບໂຄງການນີ້: NAND, ບໍ່ເຫມືອນກັບ NOR, ຈໍາເປັນຕ້ອງໃຊ້ລະຫັດການແກ້ໄຂຂໍ້ຜິດພາດ, ຕາຕະລາງຂອງບລັອກທີ່ບໍ່ດີ, ແລະອື່ນໆ, ແລະຂາຂອງ. ຊິບ NAND ປົກກະຕິແລ້ວມີຫຼາຍຫຼາຍ.

ຂໍ້ເສຍຂອງ NOR ປະກອບມີ:

• ປະລິມານຂະຫນາດນ້ອຍ (ແລະ, ຕາມຄວາມເຫມາະສົມ, ລາຄາສູງຕໍ່ megabyte);
• ຄວາມໄວການສື່ສານຕ່ໍາ (ສ່ວນໃຫຍ່ແມ່ນຍ້ອນຄວາມຈິງທີ່ວ່າການໂຕ້ຕອບ serial ຖືກນໍາໃຊ້, ປົກກະຕິແລ້ວ SPI ຫຼື I2C);
• ການລຶບຊ້າ (ຂຶ້ນກັບຂະຫນາດຂອງຕັນ, ມັນໃຊ້ເວລາຈາກສ່ວນຫນຶ່ງຂອງວິນາທີຫາຫຼາຍວິນາທີ).

ມັນເບິ່ງຄືວ່າບໍ່ມີຫຍັງສໍາຄັນສໍາລັບພວກເຮົາ, ດັ່ງນັ້ນພວກເຮົາສືບຕໍ່.

ຖ້າລາຍລະອຽດແມ່ນຫນ້າສົນໃຈ, microcircuit ໄດ້ຖືກເລືອກ ທີ່ 25df321a (ຢ່າງໃດກໍ່ຕາມ, ນີ້ແມ່ນບໍ່ສໍາຄັນ, ມີຫຼາຍ analogues ໃນຕະຫຼາດທີ່ເຂົ້າກັນໄດ້ໃນ pinout ແລະລະບົບຄໍາສັ່ງ; ເຖິງແມ່ນວ່າພວກເຮົາຕ້ອງການຕິດຕັ້ງ microcircuit ຈາກຜູ້ຜະລິດທີ່ແຕກຕ່າງກັນແລະ / ຫຼືຂະຫນາດທີ່ແຕກຕ່າງກັນ, ທຸກສິ່ງທຸກຢ່າງຈະເຮັດວຽກໂດຍບໍ່ມີການປ່ຽນແປງ. ລະຫັດ).

ຂ້ອຍໃຊ້ອັນທີ່ສ້າງຢູ່ໃນ kernel Linux ໄດຣເວີ, ໃນ 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. ໃນອີກດ້ານຫນຶ່ງ, ຂ້າພະເຈົ້າບໍ່ແມ່ນຜູ້ຊ່ຽວຊານດ້ານເອເລັກໂຕຣນິກ, ໃນທາງກົງກັນຂ້າມ, ທຸກສິ່ງທຸກຢ່າງຢູ່ທີ່ນີ້ແມ່ນ banal ເຖິງແມ່ນວ່າສໍາລັບຂ້າພະເຈົ້າ: microcircuit ມີພຽງແຕ່ 8 ຂາ, ເຊິ່ງພວກເຮົາຕ້ອງການດິນ, ພະລັງງານ, SPI (CS, SI, SO, SCK. ); ລະດັບແມ່ນຄືກັນກັບຂອງ Raspberry Pi, ບໍ່ຈໍາເປັນຕ້ອງມີສາຍໄຟເພີ່ມເຕີມ - ພຽງແຕ່ເຊື່ອມຕໍ່ 6 pins ທີ່ລະບຸໄວ້.

ການສ້າງບັນຫາ

ຕາມປົກກະຕິ, ຄໍາຖະແຫຼງການບັນຫາຈະຜ່ານຫຼາຍໆຄັ້ງ, ແລະມັນເບິ່ງຄືວ່າຂ້ອຍເຖິງເວລາຕໍ່ໄປ. ສະນັ້ນໃຫ້ຢຸດເຊົາ, ເອົາສິ່ງທີ່ຂຽນໄວ້ແລ້ວ, ແລະຊີ້ແຈງລາຍລະອຽດທີ່ຍັງຄົງຢູ່ໃນເງົາ.

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຕັດສິນໃຈວ່າບັນທຶກຈະຖືກເກັບໄວ້ໃນ SPI NOR Flash.

NOR Flash ແມ່ນຫຍັງສໍາລັບຜູ້ທີ່ບໍ່ຮູ້?

ນີ້​ແມ່ນ​ຄວາມ​ຊົງ​ຈໍາ​ທີ່​ບໍ່​ລະ​ເຫີຍ​ທີ່​ທ່ານ​ສາ​ມາດ​ເຮັດ​ໄດ້​ສາມ​ການ​ດໍາ​ເນີນ​ງານ​:

1. ການອ່ານ:
   ການອ່ານທົ່ວໄປທີ່ສຸດ: ພວກເຮົາສົ່ງທີ່ຢູ່ແລະອ່ານຫຼາຍ bytes ຕາມທີ່ພວກເຮົາຕ້ອງການ;
2. ບັນທຶກ:
   ການຂຽນ NOR flash ເບິ່ງຄືວ່າເປັນແບບປົກກະຕິ, ແຕ່ມັນມີຄວາມແປກປະຫລາດຫນຶ່ງ: ທ່ານສາມາດປ່ຽນພຽງແຕ່ 1 ຫາ 0, ແຕ່ບໍ່ແມ່ນໃນທາງກັບກັນ. ຕົວຢ່າງ: ຖ້າພວກເຮົາມີ 0x55 ໃນເຊລຫນ່ວຍຄວາມຈໍາ, ຫຼັງຈາກນັ້ນຫຼັງຈາກຂຽນ 0x0f ກັບມັນ, 0x05 ຈະຖືກເກັບໄວ້ຢູ່ທີ່ນັ້ນ. (ເບິ່ງຕາຕະລາງຂ້າງລຸ່ມນີ້);
3. ລຶບ:
   ແນ່ນອນ, ພວກເຮົາຈໍາເປັນຕ້ອງສາມາດປະຕິບັດການກົງກັນຂ້າມ - ການປ່ຽນແປງ 0 ຫາ 1, ນີ້ແມ່ນສິ່ງທີ່ການປະຕິບັດການລຶບແມ່ນແທ້ໆ. ບໍ່ເຫມືອນກັບສອງອັນທໍາອິດ, ມັນບໍ່ໄດ້ດໍາເນີນການກັບ bytes, ແຕ່ມີຕັນ (ຕັນລົບຕໍາ່ສຸດທີ່ໃນຊິບເລືອກແມ່ນ 4kb). Erase ທໍາລາຍທ່ອນໄມ້ທັງຫມົດແລະເປັນວິທີດຽວທີ່ຈະປ່ຽນ 0 ຫາ 1. ດັ່ງນັ້ນ, ເມື່ອເຮັດວຽກກັບຫນ່ວຍຄວາມຈໍາ flash, ທ່ານມັກຈະຕ້ອງຈັດວາງໂຄງສ້າງຂໍ້ມູນໃຫ້ກັບເຂດແດນຂອງ block ລົບ.
   ການບັນທຶກໃນ NOR Flash:

ຂໍ້ມູນຖານສອງ

ມັນແມ່ນ
01010101

ບັນທຶກ
00001111

ໄດ້ກາຍເປັນ
00000101

ບັນທຶກຕົວມັນເອງເປັນຕົວແທນຂອງລໍາດັບຂອງບັນທຶກຂອງຄວາມຍາວຕົວແປ. ຄວາມຍາວປົກກະຕິຂອງບັນທຶກແມ່ນປະມານ 30 ໄບຕ໌ (ເຖິງແມ່ນວ່າບັນທຶກທີ່ມີຄວາມຍາວຫຼາຍກິໂລໄບຕ໌ເກີດຂຶ້ນບາງຄັ້ງ). ໃນກໍລະນີນີ້, ພວກເຮົາເຮັດວຽກກັບພວກມັນພຽງແຕ່ເປັນຊຸດຂອງ bytes, ແຕ່, ຖ້າທ່ານສົນໃຈ, CBOR ຖືກນໍາໃຊ້ພາຍໃນບັນທຶກ.

ນອກ​ຈາກ​ບັນ​ທຶກ​ການ​, ພວກ​ເຮົາ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ເກັບ​ຮັກ​ສາ​ຂໍ້​ມູນ "ການ​ຕັ້ງ​ຄ່າ​" ບາງ​, ທັງ​ປັບ​ປຸງ​ແລະ​ບໍ່​: ID ອຸ​ປະ​ກອນ​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​, ການ​ປັບ​ເຊັນ​ເຊີ​, ທຸງ "ອຸ​ປະ​ກອນ​ແມ່ນ​ຊົ່ວ​ຄາວ​" ແລະ​ອື່ນໆ​.
ຂໍ້​ມູນ​ນີ້​ແມ່ນ​ຊຸດ​ຂອງ​ການ​ບັນ​ທຶກ​ທີ່​ມີ​ມູນ​ຄ່າ​, ຍັງ​ເກັບ​ຮັກ​ສາ​ໄວ້​ໃນ CBOR ພວກ​ເຮົາ​ບໍ່​ມີ​ຫຼາຍ​ຂອງ​ຂໍ້​ມູນ​ນີ້ (ບໍ່​ຫຼາຍ​ປານ​ໃດ​ກິ​ໂລ​ໄບ​)​, ແລະ​ມັນ​ມີ​ການ​ປັບ​ປຸງ​ເລື້ອຍໆ​.
ໃນສິ່ງທີ່ຕໍ່ໄປນີ້ພວກເຮົາຈະເອີ້ນມັນວ່າສະພາບການ.

ຖ້າພວກເຮົາຈື່ຈໍາບ່ອນທີ່ບົດຄວາມນີ້ເລີ່ມຕົ້ນ, ມັນເປັນສິ່ງສໍາຄັນຫຼາຍເພື່ອຮັບປະກັນການເກັບຮັກສາຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້ແລະ, ຖ້າເປັນໄປໄດ້, ການດໍາເນີນງານຢ່າງຕໍ່ເນື່ອງເຖິງແມ່ນວ່າໃນກໍລະນີຮາດແວລົ້ມເຫລວ / ຂໍ້ມູນເສຍຫາຍ.

ແຫຼ່ງຂອງບັນຫາໃດທີ່ສາມາດພິຈາລະນາໄດ້?

• ປິດເຄື່ອງໃນລະຫວ່າງການດຳເນີນການຂຽນ/ລຶບ. ນີ້ແມ່ນມາຈາກປະເພດຂອງ "ບໍ່ມີ trick ຕ້ານ crowbar."
  ຂໍ້ມູນຈາກ ການສົນທະນາ on stackexchange: ເມື່ອໄຟຖືກປິດໃນຂະນະທີ່ເຮັດວຽກກັບແຟດ, ທັງລົບ (ຕັ້ງເປັນ 1) ແລະຂຽນ (ຕັ້ງເປັນ 0) ນໍາໄປສູ່ພຶດຕິກໍາທີ່ບໍ່ໄດ້ກໍານົດ: ຂໍ້ມູນສາມາດຂຽນໄດ້, ຂຽນບາງສ່ວນ (ເວົ້າວ່າ, ພວກເຮົາໂອນ 10 bytes / 80 bits. , ແຕ່ຍັງບໍ່ທັນສາມາດຂຽນໄດ້ພຽງແຕ່ 45 bits), ມັນກໍ່ເປັນໄປໄດ້ວ່າບາງ bits ຈະຢູ່ໃນສະຖານະ "ປານກາງ" (ການອ່ານສາມາດຜະລິດໄດ້ທັງ 0 ແລະ 1);
• ຄວາມຜິດພາດໃນຫນ່ວຍຄວາມຈໍາ flash ຕົວຂອງມັນເອງ.
  BER, ເຖິງແມ່ນວ່າຕໍ່າຫຼາຍ, ບໍ່ສາມາດເທົ່າກັບສູນ;
• ຄວາມຜິດພາດລົດເມ
  ຂໍ້ມູນທີ່ຖືກສົ່ງຜ່ານ SPI ບໍ່ໄດ້ຖືກປົກປ້ອງໃນທາງໃດກໍ່ຕາມ, ທັງຄວາມຜິດພາດບິດດຽວແລະຄວາມຜິດພາດ synchronization ອາດຈະເກີດຂື້ນ - ການສູນເສຍຫຼືການແຊກບິດ (ເຊິ່ງນໍາໄປສູ່ການບິດເບືອນຂໍ້ມູນຂະຫນາດໃຫຍ່);
• ຄວາມ​ຜິດ​ພາດ / ຜິດ​ພາດ​ອື່ນໆ​
  ຄວາມ​ຜິດ​ພາດ​ໃນ​ລະ​ຫັດ​, Raspberry glitches​, ການ​ແຊກ​ແຊງ​ມະ​ນຸດ​ຕ່າງ​ດາວ ...

ຂ້າພະເຈົ້າໄດ້ສ້າງຂໍ້ກໍານົດ, ການປະຕິບັດທີ່, ໃນຄວາມຄິດເຫັນຂອງຂ້າພະເຈົ້າ, ແມ່ນມີຄວາມຈໍາເປັນເພື່ອຮັບປະກັນຄວາມຫນ້າເຊື່ອຖື:

• ບັນທຶກຕ້ອງເຂົ້າໄປໃນຫນ່ວຍຄວາມຈໍາແຟດທັນທີ, ການຂຽນທີ່ຊັກຊ້າບໍ່ໄດ້ຖືກພິຈາລະນາ - ຖ້າມີຂໍ້ຜິດພາດເກີດຂື້ນ, ມັນຕ້ອງໄດ້ຮັບການກວດພົບແລະປຸງແຕ່ງໄວເທົ່າທີ່ຈະໄວໄດ້ - ລະບົບຕ້ອງ, ຖ້າເປັນໄປໄດ້, ຟື້ນຕົວຈາກຄວາມຜິດພາດ.
  (ຕົວຢ່າງຈາກຊີວິດ "ມັນບໍ່ຄວນເປັນ", ທີ່ຂ້ອຍຄິດວ່າທຸກຄົນໄດ້ພົບ: ຫຼັງຈາກ reboot ສຸກເສີນ, ລະບົບໄຟລ໌ແມ່ນ "ແຕກ" ແລະລະບົບປະຕິບັດການບໍ່ boot).

ແນວຄວາມຄິດ, ວິທີການ, ສະທ້ອນໃຫ້ເຫັນ

ເມື່ອຂ້ອຍເລີ່ມຄິດກ່ຽວກັບບັນຫານີ້, ຄວາມຄິດຫຼາຍຢ່າງໄດ້ເຂົ້າໄປໃນຫົວຂອງຂ້ອຍ, ຕົວຢ່າງ:

• ໃຊ້ການບີບອັດຂໍ້ມູນ;
• ການນໍາໃຊ້ໂຄງສ້າງຂໍ້ມູນທີ່ສະຫລາດ, ສໍາລັບການຍົກຕົວຢ່າງ, ການເກັບຮັກສາ headers ບັນທຶກແຍກຕ່າງຫາກຈາກບັນທຶກດ້ວຍຕົນເອງ, ດັ່ງນັ້ນຖ້າຫາກວ່າມີຄວາມຜິດພາດໃນບັນທຶກໃດຫນຶ່ງ, ທ່ານສາມາດອ່ານສ່ວນທີ່ເຫຼືອໂດຍບໍ່ມີບັນຫາໃດໆ;
• ໃຊ້ຊ່ອງຂໍ້ມູນນ້ອຍເພື່ອຄວບຄຸມການສໍາເລັດການບັນທຶກໃນເວລາທີ່ປິດພະລັງງານ;
• ເກັບຮັກສາ checksums ສໍາລັບທຸກສິ່ງທຸກຢ່າງ;
• ໃຊ້ລະຫັດບາງປະເພດທີ່ທົນທານຕໍ່ສຽງ.

ບາງແນວຄວາມຄິດເຫຼົ່ານີ້ໄດ້ຖືກນໍາໃຊ້, ໃນຂະນະທີ່ຄົນອື່ນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະປະຖິ້ມ. ໃຫ້ໄປຢູ່ໃນຄໍາສັ່ງ.

ການບີບອັດຂໍ້ມູນ

ເຫດການຕົວມັນເອງທີ່ພວກເຮົາບັນທຶກໄວ້ໃນວາລະສານແມ່ນຂ້ອນຂ້າງຄ້າຍຄືກັນແລະເຮັດຊ້ໍາໄດ້ ("ຖິ້ມຫຼຽນ 5 ຮູເບີນ", "ກົດປຸ່ມເພື່ອໃຫ້ການປ່ຽນແປງ", ...). ດັ່ງນັ້ນ, ການບີບອັດຄວນຈະມີປະສິດທິພາບດີ.

ການບີບອັດ overhead ແມ່ນບໍ່ສໍາຄັນ (ໂປເຊດເຊີຂອງພວກເຮົາແມ່ນຂ້ອນຂ້າງມີອໍານາດ, ເຖິງແມ່ນວ່າ Pi ທໍາອິດມີແກນຫນຶ່ງທີ່ມີຄວາມຖີ່ຂອງ 700 MHz, ຮຸ່ນປະຈຸບັນມີຫຼາຍແກນທີ່ມີຄວາມຖີ່ເກີນ gigahertz), ອັດຕາແລກປ່ຽນກັບການເກັບຮັກສາແມ່ນຕໍ່າ (ຫຼາຍ. megabytes ຕໍ່ວິນາທີ), ຂະຫນາດຂອງການບັນທຶກແມ່ນຂະຫນາດນ້ອຍ. ໂດຍທົ່ວໄປ, ຖ້າການບີບອັດມີຜົນກະທົບຕໍ່ການປະຕິບັດ, ມັນຈະເປັນບວກເທົ່ານັ້ນ. (ບໍ່​ມີ​ຄວາມ​ວິ​ຈານ​ຢ່າງ​ແທ້​ຈິງ​, ພຽງ​ແຕ່​ກ່າວ​)ຍິ່ງໄປກວ່ານັ້ນ, ພວກເຮົາບໍ່ມີອັນທີ່ຝັງຢູ່ໃນຕົວຈິງ, ແຕ່ເປັນອັນທຳມະດາ. Linux — ສະນັ້ນການຈັດຕັ້ງປະຕິບັດບໍ່ຄວນຕ້ອງການຄວາມພະຍາຍາມຫຼາຍ (ມັນພຽງພໍທີ່ຈະເຊື່ອມຕໍ່ຫ້ອງສະໝຸດ ແລະ ໃຊ້ຟັງຊັນບາງຢ່າງຈາກມັນ).

ຊິ້ນສ່ວນຂອງບັນທຶກໄດ້ຖືກເອົາມາຈາກອຸປະກອນທີ່ເຮັດວຽກ (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 ດຽວກັນ.

ຂໍໃຫ້ຄິດກ່ຽວກັບຂໍ້ເສຍ.

ບັນ​ຫາ​ທໍາ​ອິດ​: ພວກ​ເຮົາ​ໄດ້​ຕົກ​ລົງ​ແລ້ວ​ວ່າ​ທຸກ​ບັນ​ທຶກ​ການ​ທັນ​ທີ​ທັນ​ໃດ​ຕ້ອງ​ໄປ flash​. ໂດຍປົກກະຕິ, archiver ເກັບກໍາຂໍ້ມູນຈາກກະແສການປ້ອນຂໍ້ມູນຈົນກ່ວາມັນຕັດສິນໃຈວ່າມັນແມ່ນເວລາທີ່ຈະຂຽນໃນທ້າຍອາທິດ. ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ທັນທີໄດ້ຮັບການບີບອັດຂອງຂໍ້ມູນແລະເກັບຮັກສາໄວ້ໃນຫນ່ວຍຄວາມຈໍາທີ່ບໍ່ມີການລະເຫີຍ.

ຂ້ອຍເຫັນສາມວິທີ:

1. ບີບອັດແຕ່ລະບັນທຶກໂດຍໃຊ້ການບີບອັດວັດຈະນານຸກົມແທນທີ່ຈະເປັນສູດການຄິດໄລ່ທີ່ໄດ້ກ່າວມາຂ້າງເທິງ.
   ມັນເປັນທາງເລືອກທີ່ເຮັດວຽກຢ່າງສົມບູນ, ແຕ່ຂ້ອຍບໍ່ມັກມັນ. ເພື່ອຮັບປະກັນການບີບອັດໃນລະດັບທີ່ເໝາະສົມຫຼາຍ ຫຼືໜ້ອຍ, ວັດຈະນານຸກົມຕ້ອງຖືກ “ປັບ” ໃຫ້ເຂົ້າກັບຂໍ້ມູນສະເພາະ, ການປ່ຽນແປງຈະນຳໄປສູ່ລະດັບການບີບອັດຫຼຸດລົງຢ່າງຮ້າຍແຮງ. ແມ່ນແລ້ວ, ບັນຫາສາມາດແກ້ໄຂໄດ້ໂດຍການສ້າງວັດຈະນານຸກົມສະບັບໃຫມ່, ແຕ່ນີ້ແມ່ນການເຈັບຫົວ - ພວກເຮົາຈະຕ້ອງເກັບຮັກສາທຸກສະບັບຂອງວັດຈະນານຸກົມ; ໃນ​ແຕ່​ລະ​ບົດ​ທີ່​ພວກ​ເຮົາ​ຈະ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຊີ້​ບອກ​ວ່າ​ສະ​ບັບ​ຂອງ​ວັດ​ຈະ​ນາ​ນຸ​ກົມ​ທີ່​ມັນ​ໄດ້​ຖືກ​ບີບ​ອັດ ...
2. ບີບອັດແຕ່ລະບັນທຶກໂດຍໃຊ້ສູດການຄິດໄລ່ "ຄລາສສິກ", ແຕ່ເປັນເອກະລາດຂອງຄົນອື່ນ.
   ສູດການບີບອັດພາຍໃຕ້ການພິຈາລະນາບໍ່ໄດ້ຖືກອອກແບບມາເພື່ອເຮັດວຽກກັບບັນທຶກຂອງຂະຫນາດນີ້ (ສິບຂອງ bytes), ອັດຕາສ່ວນການບີບອັດຢ່າງຊັດເຈນຈະຫນ້ອຍກວ່າ 1 (ນັ້ນແມ່ນ, ການເພີ່ມປະລິມານຂໍ້ມູນແທນທີ່ຈະບີບອັດ);
3. ເຮັດ FLUSH ຫຼັງຈາກແຕ່ລະການບັນທຶກ.
   ຫ້ອງສະຫມຸດບີບອັດຫຼາຍມີການສະຫນັບສະຫນູນ FLUSH. ນີ້ແມ່ນຄໍາສັ່ງ (ຫຼືຕົວກໍານົດການຂອງຂັ້ນຕອນການບີບອັດ), ເມື່ອໄດ້ຮັບທີ່ archiver ປະກອບເປັນນ້ໍາ compressed ເພື່ອໃຫ້ມັນສາມາດຖືກນໍາໃຊ້ເພື່ອຟື້ນຟູ. ທັງ​ຫມົດ ຂໍ້ມູນທີ່ບໍ່ໄດ້ບີບອັດທີ່ໄດ້ຮັບແລ້ວ. ການປຽບທຽບດັ່ງກ່າວ 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 bytes ຕໍ່ບັນທຶກ. ແລະອັດຕາສ່ວນການບີບອັດໄດ້ກາຍເປັນເກືອບ 5: 1, ເຊິ່ງຫຼາຍກວ່າຜົນໄດ້ຮັບທີ່ດີເລີດ.

ມັນອາດຈະເປັນເລື່ອງແປກ, ແຕ່ Z_SYNC_FLUSH ຕົວຈິງແລ້ວແມ່ນວິທີທີ່ມີປະສິດທິພາບກວ່າທີ່ຈະເຮັດ FLUSH

ເມື່ອໃຊ້ Z_SYNC_FLUSH, 4 bytes ສຸດທ້າຍຂອງແຕ່ລະລາຍການຈະເປັນ 0x00, 0x00, 0xff, 0xff. ແລະຖ້າພວກເຮົາຮູ້ຈັກພວກມັນ, ພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງເກັບຮັກສາພວກມັນ, ດັ່ງນັ້ນຂະຫນາດສຸດທ້າຍແມ່ນພຽງແຕ່ 324Kb.

ບົດຄວາມທີ່ຂ້ອຍເຊື່ອມຕໍ່ມີຄໍາອະທິບາຍ:

ບລັອກປະເພດ 0 ໃໝ່ທີ່ມີເນື້ອຫາຫວ່າງເປົ່າຖືກຕໍ່ທ້າຍ.

ບລັອກປະເພດ 0 ທີ່ມີເນື້ອໃນຫວ່າງເປົ່າປະກອບດ້ວຍ:

• ຫົວບລັອກສາມບິດ;
• 0 ຫາ 7 bits ເທົ່າກັບສູນ, ເພື່ອບັນລຸການສອດຄ່ອງ byte;
• ລໍາດັບສີ່ໄບຕ໌ 00 00 FF FF.

ດັ່ງທີ່ທ່ານສາມາດເບິ່ງເຫັນໄດ້, ໃນບລັອກສຸດທ້າຍກ່ອນ 4 bytes ເຫຼົ່ານີ້ມີຈາກ 3 ຫາ 10 ບິດສູນ. ຢ່າງໃດກໍຕາມ, ການປະຕິບັດໄດ້ສະແດງໃຫ້ເຫັນວ່າຕົວຈິງແລ້ວມີຢ່າງຫນ້ອຍ 10 ສູນ.

ມັນ turns ໃຫ້​ເຫັນ​ວ່າ blocks ສັ້ນ​ຂອງ​ຂໍ້​ມູນ​ດັ່ງ​ກ່າວ​ໂດຍ​ປົກ​ກະ​ຕິ (ສະ​ເຫມີ​?) ເຂົ້າ​ລະ​ຫັດ​ໂດຍ​ການ​ນໍາ​ໃຊ້ block ຂອງ​ປະ​ເພດ 1 (ຕັນ​ຄົງ​ທີ່​)​, ເຊິ່ງ​ຈໍາ​ເປັນ​ຕ້ອງ​ສິ້ນ​ສຸດ​ດ້ວຍ 7 ສູນ​ບິດ​, ໃຫ້​ທັງ​ຫມົດ​ຂອງ 10-17 ການ​ຮັບ​ປະ​ກັນ zero bits (ແລະ​ສ່ວນ​ທີ່​ເຫຼືອ​ຈະ ເປັນສູນທີ່ມີຄວາມເປັນໄປໄດ້ປະມານ 50%).

ດັ່ງນັ້ນ, ໃນຂໍ້ມູນການທົດສອບ, ໃນ 100% ຂອງກໍລະນີມີສູນຫນຶ່ງ byte ກ່ອນ 0x00, 0x00, 0xff, 0xff, ແລະໃນຫຼາຍກວ່າຫນຶ່ງສ່ວນສາມຂອງກໍລະນີມີສອງສູນ bytes. (ບາງທີຄວາມຈິງແມ່ນວ່າຂ້ອຍໃຊ້ CBOR binary, ແລະເມື່ອໃຊ້ຂໍ້ຄວາມ JSON, ບລັອກຂອງປະເພດ 2 - ບລັອກແບບເຄື່ອນໄຫວຈະເປັນເລື່ອງທົ່ວໄປຫຼາຍ, ຕາມລໍາດັບ, ບລັອກທີ່ບໍ່ມີສູນ bytes ເພີ່ມເຕີມກ່ອນທີ່ຈະພົບ 0x00, 0x00, 0xff, 0xff).

ໂດຍລວມແລ້ວ, ການນໍາໃຊ້ຂໍ້ມູນການທົດສອບທີ່ມີຢູ່, ມັນເປັນໄປໄດ້ທີ່ຈະເຫມາະກັບຂໍ້ມູນທີ່ຖືກບີບອັດຫນ້ອຍກວ່າ 250Kb.

ທ່ານສາມາດປະຫຍັດໄດ້ອີກເລັກນ້ອຍໂດຍການເຮັດ juggling ເລັກນ້ອຍ: ສໍາລັບໃນປັດຈຸບັນພວກເຮົາບໍ່ສົນໃຈການມີສູນສອງສາມບິດໃນຕອນທ້າຍຂອງຕັນ, ສອງສາມບິດໃນຕອນຕົ້ນຂອງຕັນຍັງບໍ່ປ່ຽນແປງ ...
ແຕ່ຫຼັງຈາກນັ້ນຂ້ອຍໄດ້ຕັດສິນໃຈຢ່າງແຂງແຮງທີ່ຈະຢຸດ, ຖ້າບໍ່ດັ່ງນັ້ນໃນອັດຕານີ້ຂ້ອຍສາມາດສິ້ນສຸດການພັດທະນາ archiver ຂອງຂ້ອຍເອງ.

ໃນຈໍານວນທັງຫມົດ, ຈາກຂໍ້ມູນການທົດສອບຂອງຂ້ອຍຂ້ອຍໄດ້ຮັບ 3-4 bytes ຕໍ່ການຂຽນ, ອັດຕາສ່ວນການບີບອັດໄດ້ກາຍມາເປັນຫຼາຍກ່ວາ 6: 1. ຂ້ອຍຈະຊື່ສັດ: ຂ້ອຍບໍ່ໄດ້ຄາດຫວັງຜົນໄດ້ຮັບດັ່ງກ່າວ;

ທຸກສິ່ງທຸກຢ່າງແມ່ນດີ, ແຕ່ zlib (deflate) ຍັງຄົງເປັນສູດການບີບອັດແບບເກົ່າ, ສົມຄວນແລະເກົ່າແກ່ເລັກນ້ອຍ. ຄວາມຈິງທີ່ວ່າ 32Kb ສຸດທ້າຍຂອງການຖ່າຍທອດຂໍ້ມູນທີ່ບໍ່ໄດ້ບີບອັດຖືກນໍາໃຊ້ເປັນວັດຈະນານຸກົມເບິ່ງຄືວ່າແປກປະຫລາດໃນມື້ນີ້ (ນັ້ນແມ່ນ, ຖ້າບາງບລັອກຂໍ້ມູນແມ່ນຄ້າຍຄືກັນກັບສິ່ງທີ່ຢູ່ໃນກະແສຂໍ້ມູນ 40Kb ກ່ອນຫນ້ານີ້, ມັນຈະເລີ່ມຖືກເກັບໄວ້ອີກເທື່ອຫນຶ່ງ, ແລະຈະບໍ່ອ້າງອີງເຖິງເຫດການທີ່ຜ່ານມາ). ໃນ archivers ທີ່ທັນສະໄຫມທີ່ທັນສະໄຫມ, ຂະຫນາດວັດຈະນານຸກົມມັກຈະຖືກວັດແທກເປັນ megabytes ແທນທີ່ຈະເປັນກິໂລໄບ.

ດັ່ງນັ້ນພວກເຮົາສືບຕໍ່ການສຶກສາ mini-archivers ຂອງພວກເຮົາ.

ຕໍ່ໄປພວກເຮົາໄດ້ທົດສອບ bzip2 (ຈື່ໄວ້, ໂດຍບໍ່ມີການ FLUSH ມັນສະແດງໃຫ້ເຫັນອັດຕາສ່ວນການບີບອັດທີ່ດີເລີດເກືອບ 100: 1). ແຕ່ຫນ້າເສຍດາຍ, ມັນປະຕິບັດໄດ້ບໍ່ດີຫຼາຍກັບ FLUSH;

ສົມມຸດຕິຖານຂອງຂ້ອຍກ່ຽວກັບເຫດຜົນສໍາລັບຄວາມລົ້ມເຫລວ

Libbz2 ສະເຫນີພຽງແຕ່ຫນຶ່ງທາງເລືອກ flush, ເຊິ່ງເບິ່ງຄືວ່າຈະລ້າງພົດຈະນານຸກົມ (ປຽບທຽບກັບ Z_FULL_FLUSH ໃນ zlib);

ແລະອັນສຸດທ້າຍທີ່ຈະທົດສອບແມ່ນ zstd. ອີງຕາມຕົວກໍານົດການ, ມັນບີບອັດຢູ່ໃນລະດັບຂອງ gzip, ແຕ່ໄວກວ່າຫຼາຍ, ຫຼືດີກວ່າ gzip.

ອະນິຈາ, ດ້ວຍ FLUSH ມັນບໍ່ໄດ້ປະຕິບັດໄດ້ດີຫຼາຍ: ຂະຫນາດຂອງຂໍ້ມູນທີ່ຖືກບີບອັດແມ່ນປະມານ 700Kb.

Я ຖາມຄໍາຖາມ ໃນຫນ້າ github ຂອງໂຄງການ, ຂ້າພະເຈົ້າໄດ້ຮັບຄໍາຕອບວ່າທ່ານຄວນນັບເຖິງ 10 bytes ຂອງຂໍ້ມູນການບໍລິການສໍາລັບແຕ່ລະບລັອກຂອງຂໍ້ມູນທີ່ຖືກບີບອັດ, ເຊິ່ງຢູ່ໃກ້ກັບຜົນໄດ້ຮັບທີ່ໄດ້ຮັບ;

ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈຢຸດຢູ່ໃນຈຸດນີ້ໃນການທົດລອງຂອງຂ້ອຍກັບ archivers (ໃຫ້ຂ້ອຍເຕືອນເຈົ້າວ່າ xz, lzip, lzo, lz4 ບໍ່ໄດ້ສະແດງຕົວເອງເຖິງແມ່ນວ່າຢູ່ໃນຂັ້ນຕອນການທົດສອບໂດຍບໍ່ມີ FLUSH, ແລະຂ້ອຍບໍ່ໄດ້ພິຈາລະນາວິທີການບີບອັດ exotic ຫຼາຍ).

ໃຫ້ກັບຄືນຫາບັນຫາການຈັດເກັບເຂົ້າແຟ້ມ.

ບັນຫາທີສອງ (ຍ້ອນວ່າພວກເຂົາເວົ້າວ່າຢູ່ໃນຄໍາສັ່ງ, ບໍ່ແມ່ນມູນຄ່າ) ແມ່ນວ່າຂໍ້ມູນທີ່ຖືກບີບອັດແມ່ນສາຍນ້ໍາດຽວ, ເຊິ່ງມີການອ້າງອີງຢ່າງຕໍ່ເນື່ອງກັບພາກສ່ວນທີ່ຜ່ານມາ. ດັ່ງນັ້ນ, ຖ້າພາກສ່ວນຂອງຂໍ້ມູນທີ່ຖືກບີບອັດເສຍຫາຍ, ພວກເຮົາຈະສູນເສຍບໍ່ພຽງແຕ່ບລັອກທີ່ກ່ຽວຂ້ອງຂອງຂໍ້ມູນທີ່ບໍ່ຖືກບີບອັດ, ແຕ່ຍັງເປັນຂໍ້ມູນຕໍ່ໄປທັງຫມົດ.

ມີວິທີການແກ້ໄຂບັນຫານີ້:

1. ປ້ອງກັນບໍ່ໃຫ້ບັນຫາເກີດຂຶ້ນ - ເພີ່ມການຊ້ໍາຊ້ອນກັບຂໍ້ມູນທີ່ຖືກບີບອັດ, ເຊິ່ງຈະຊ່ວຍໃຫ້ທ່ານສາມາດກໍານົດແລະແກ້ໄຂຂໍ້ຜິດພາດ; ພວກເຮົາຈະສົນທະນາກ່ຽວກັບເລື່ອງນີ້ຕໍ່ມາ;
2. ຫຼຸດຜ່ອນຜົນສະທ້ອນຖ້າບັນຫາເກີດຂຶ້ນ
   ພວກເຮົາໄດ້ເວົ້າກ່ອນຫນ້ານີ້ວ່າທ່ານສາມາດບີບອັດແຕ່ລະບລັອກຂໍ້ມູນເປັນເອກະລາດ, ແລະບັນຫາຈະຫາຍໄປດ້ວຍຕົວມັນເອງ (ຄວາມເສຍຫາຍຕໍ່ຂໍ້ມູນຂອງຫນຶ່ງບລັອກຈະນໍາໄປສູ່ການສູນເສຍຂໍ້ມູນພຽງແຕ່ສໍາລັບບລັອກນີ້). ຢ່າງໃດກໍ່ຕາມ, ນີ້ແມ່ນກໍລະນີທີ່ຮຸນແຮງທີ່ການບີບອັດຂໍ້ມູນຈະບໍ່ມີປະສິດທິພາບ. ກົງກັນຂ້າມທີ່ສຸດ: ໃຊ້ຊິບທັງຫມົດ 4MB ຂອງພວກເຮົາເປັນບ່ອນເກັບມ້ຽນອັນດຽວ, ເຊິ່ງຈະເຮັດໃຫ້ພວກເຮົາບີບອັດທີ່ດີເລີດ, ແຕ່ຜົນສະທ້ອນທີ່ຮ້າຍແຮງໃນກໍລະນີຂອງຂໍ້ມູນເສຍຫາຍ.
   ແມ່ນແລ້ວ, ການປະນີປະນອມແມ່ນຈໍາເປັນໃນແງ່ຂອງຄວາມຫນ້າເຊື່ອຖື. ແຕ່ພວກເຮົາຕ້ອງຈື່ໄວ້ວ່າພວກເຮົາກໍາລັງພັດທະນາຮູບແບບການເກັບຮັກສາຂໍ້ມູນສໍາລັບຫນ່ວຍຄວາມຈໍາທີ່ບໍ່ມີການເຫນັງຕີງທີ່ມີ BER ຕ່ໍາທີ່ສຸດແລະໄລຍະເວລາການເກັບຮັກສາຂໍ້ມູນທີ່ຖືກປະກາດ 20 ປີ.

ໃນລະຫວ່າງການທົດລອງ, ຂ້າພະເຈົ້າໄດ້ຄົ້ນພົບວ່າການສູນເສຍທີ່ສັງເກດເຫັນຫຼາຍຫຼືຫນ້ອຍໃນລະດັບການບີບອັດເລີ່ມຕົ້ນຢູ່ໃນບລັອກຂອງຂໍ້ມູນທີ່ບີບອັດຫນ້ອຍກວ່າ 10 KB ໃນຂະຫນາດ.
ມັນໄດ້ຖືກກ່າວເຖິງກ່ອນຫນ້ານີ້ວ່າຫນ່ວຍຄວາມຈໍາທີ່ໃຊ້ແມ່ນ paged;

ນັ້ນແມ່ນ, ຂະຫນາດຫນ້າທີ່ເຫມາະສົມຕໍາ່ສຸດທີ່ແມ່ນ 16Kb (ມີສະຫງວນສໍາລັບຂໍ້ມູນການບໍລິການ). ຢ່າງໃດກໍຕາມ, ຂະຫນາດຫນ້າຂະຫນາດນ້ອຍດັ່ງກ່າວ imposes ຂໍ້ຈໍາກັດທີ່ສໍາຄັນກ່ຽວກັບຂະຫນາດບັນທຶກສູງສຸດ.

ເຖິງແມ່ນວ່າຂ້ອຍບໍ່ໄດ້ຄາດຫວັງວ່າບັນທຶກຂະຫນາດໃຫຍ່ກວ່າສອງສາມກິໂລໄບໃນຮູບແບບທີ່ຖືກບີບອັດ, ຂ້ອຍໄດ້ຕັດສິນໃຈໃຊ້ຫນ້າ 32Kb (ສໍາລັບຈໍານວນທັງຫມົດ 128 ຫນ້າຕໍ່ຊິບ).

ສະຫຼຸບສັງລວມ:

• ພວກເຮົາເກັບຂໍ້ມູນທີ່ຖືກບີບອັດໂດຍໃຊ້ zlib (deflate);
• ສໍາລັບແຕ່ລະລາຍການພວກເຮົາກໍານົດ Z_SYNC_FLUSH;
• ສໍາລັບແຕ່ລະບັນທຶກທີ່ຖືກບີບອັດ, ພວກເຮົາຕັດໄບຕ໌ຕໍ່ທ້າຍ (ເຊັ່ນ: 0x00, 0x00, 0xff, 0xff); ໃນ header ພວກເຮົາຊີ້ບອກຈໍານວນ bytes ທີ່ພວກເຮົາຕັດອອກ;
• ພວກເຮົາເກັບຮັກສາຂໍ້ມູນໃນ 32Kb ຫນ້າ; ມີກະແສດຽວຂອງຂໍ້ມູນທີ່ຖືກບີບອັດພາຍໃນຫນ້າ; ໃນແຕ່ລະຫນ້າພວກເຮົາເລີ່ມຕົ້ນການບີບອັດອີກເທື່ອຫນຶ່ງ.

ແລະ, ກ່ອນທີ່ຈະສໍາເລັດການບີບອັດ, ຂ້າພະເຈົ້າຢາກຈະເອົາໃຈໃສ່ກັບຄວາມຈິງທີ່ວ່າພວກເຮົາມີພຽງແຕ່ສອງສາມ bytes ຂອງຂໍ້ມູນທີ່ຖືກບີບອັດຕໍ່ບັນທຶກ, ດັ່ງນັ້ນມັນເປັນສິ່ງສໍາຄັນທີ່ສຸດທີ່ຈະບໍ່ຂະຫຍາຍຂໍ້ມູນການບໍລິການ, ທຸກໆ byte ນັບຢູ່ທີ່ນີ້.

ການເກັບຮັກສາຫົວຂໍ້ມູນ

ເນື່ອງຈາກພວກເຮົາມີບັນທຶກຂອງຄວາມຍາວຕົວແປ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ກໍານົດການຈັດວາງ / ຂອບເຂດຂອງບັນທຶກ.

ຂ້ອຍຮູ້ສາມວິທີ:

1. ບັນທຶກທັງຫມົດຖືກເກັບໄວ້ໃນນ້ໍາຢ່າງຕໍ່ເນື່ອງ, ທໍາອິດມີຫົວບັນທຶກທີ່ມີຄວາມຍາວ, ແລະຫຼັງຈາກນັ້ນບັນທຶກຕົວມັນເອງ.
   ໃນຮູບແບບນີ້, ທັງສ່ວນຫົວ ແລະຂໍ້ມູນສາມາດມີຄວາມຍາວປ່ຽນແປງໄດ້.
   ໂດຍພື້ນຖານແລ້ວ, ພວກເຮົາໄດ້ຮັບບັນຊີລາຍຊື່ທີ່ເຊື່ອມຕໍ່ດຽວທີ່ຖືກນໍາໃຊ້ຕະຫຼອດເວລາ;
2. ສ່ວນຫົວ ແລະບັນທຶກຕົວມັນເອງຖືກເກັບໄວ້ໃນສະຕຣີມແຍກຕ່າງຫາກ.
   ໂດຍການນໍາໃຊ້ສ່ວນຫົວຂອງຄວາມຍາວຄົງທີ່, ພວກເຮົາຮັບປະກັນວ່າຄວາມເສຍຫາຍຕໍ່ຫົວຫນຶ່ງບໍ່ມີຜົນຕໍ່ຄົນອື່ນ.
   ວິທີການທີ່ຄ້າຍຄືກັນແມ່ນຖືກນໍາໃຊ້, ສໍາລັບການຍົກຕົວຢ່າງ, ໃນລະບົບໄຟລ໌ຈໍານວນຫຼາຍ;
3. ບັນທຶກຖືກເກັບໄວ້ໃນສາຍນ້ໍາຢ່າງຕໍ່ເນື່ອງ, ຂອບເຂດການບັນທຶກແມ່ນຖືກກໍານົດໂດຍເຄື່ອງຫມາຍສະເພາະໃດຫນຶ່ງ (ລັກສະນະ / ລໍາດັບຂອງຕົວອັກສອນທີ່ຫ້າມພາຍໃນບລັອກຂໍ້ມູນ). ຖ້າມີເຄື່ອງຫມາຍຢູ່ໃນບັນທຶກ, ພວກເຮົາແທນທີ່ມັນດ້ວຍລໍາດັບບາງຢ່າງ (ຫນີຈາກມັນ).
   ວິທີການທີ່ຄ້າຍຄືກັນແມ່ນຖືກນໍາໃຊ້, ສໍາລັບຕົວຢ່າງ, ໃນພິທີການ PPP.

ຂ້ອຍຈະຍົກຕົວຢ່າງ.

ທາງເລືອກ 1:

ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍຫຼາຍຢູ່ທີ່ນີ້: ຮູ້ຄວາມຍາວຂອງບັນທຶກ, ພວກເຮົາສາມາດຄິດໄລ່ທີ່ຢູ່ຂອງຫົວຕໍ່ໄປ. ດັ່ງນັ້ນພວກເຮົາຍ້າຍຜ່ານຫົວຂໍ້ຈົນກ່ວາພວກເຮົາພົບກັບພື້ນທີ່ທີ່ເຕັມໄປດ້ວຍ 0xff (ພື້ນທີ່ຟຣີ) ຫຼືໃນຕອນທ້າຍຂອງຫນ້າ.

ທາງເລືອກ 2:

ເນື່ອງຈາກຄວາມຍາວຂອງບັນທຶກທີ່ປ່ຽນແປງໄດ້, ພວກເຮົາບໍ່ສາມາດເວົ້າລ່ວງຫນ້າວ່າພວກເຮົາຈະຕ້ອງການຈໍານວນບັນທຶກ (ແລະດັ່ງນັ້ນ headers) ຕໍ່ຫນ້າ. ທ່ານສາມາດເຜີຍແຜ່ສ່ວນຫົວແລະຂໍ້ມູນດ້ວຍຕົນເອງໃນທົ່ວຫນ້າຕ່າງໆ, ແຕ່ຂ້ອຍມັກວິທີການທີ່ແຕກຕ່າງກັນ: ພວກເຮົາວາງສ່ວນຫົວແລະຂໍ້ມູນໃນຫນ້າດຽວ, ແຕ່ສ່ວນຫົວ (ຂະຫນາດຄົງທີ່) ມາຈາກຕົ້ນຫນ້າ, ແລະ ຂໍ້ມູນ (ຂອງຄວາມຍາວຕົວແປ) ມາຈາກທ້າຍ. ທັນທີທີ່ພວກເຂົາ "ພົບ" (ບໍ່ມີພື້ນທີ່ຫວ່າງພຽງພໍສໍາລັບການເຂົ້າໃຫມ່), ພວກເຮົາພິຈາລະນາຫນ້ານີ້ສໍາເລັດ.

ທາງເລືອກ 3:

ບໍ່ຈໍາເປັນຕ້ອງເກັບຮັກສາຄວາມຍາວຫຼືຂໍ້ມູນອື່ນໆກ່ຽວກັບສະຖານທີ່ຂອງຂໍ້ມູນໃນສ່ວນຫົວ; ຢ່າງໃດກໍຕາມ, ຂໍ້ມູນຕ້ອງໄດ້ຮັບການປະມວນຜົນໃນເວລາຂຽນ / ອ່ານ.
ຂ້ອຍຈະໃຊ້ 0xff ເປັນເຄື່ອງຫມາຍ (ເຊິ່ງຕື່ມຂໍ້ມູນໃສ່ຫນ້າຫຼັງຈາກລຶບ), ດັ່ງນັ້ນພື້ນທີ່ຟຣີຈະບໍ່ຖືກປະຕິບັດຢ່າງແນ່ນອນ.

ຕາຕະລາງປຽບທຽບ:

Option 1
Option 2
Option 3

ຄວາມທົນທານຕໍ່ຄວາມຜິດພາດ
-
+
+

ຄວາມຫນາແຫນ້ນ
+
-
+

ຄວາມສັບສົນຂອງການປະຕິບັດ
*
**
**

ທາງ​ເລືອກ 1 ມີ​ຂໍ້​ບົກ​ພ່ອງ​ທີ່​ຮ້າຍ​ແຮງ​: ຖ້າ​ຫາກ​ວ່າ​ຫົວ​ຂໍ້​ໃດ​ຫນຶ່ງ​ໄດ້​ຮັບ​ຄວາມ​ເສຍ​ຫາຍ​, ຕ່ອງ​ໂສ້​ຕໍ່​ມາ​ທັງ​ຫມົດ​ຈະ​ຖືກ​ທໍາ​ລາຍ​. ທາງເລືອກທີ່ຍັງເຫຼືອອະນຸຍາດໃຫ້ທ່ານສາມາດຟື້ນຕົວຂໍ້ມູນບາງຢ່າງເຖິງແມ່ນວ່າໃນກໍລະນີຂອງຄວາມເສຍຫາຍຂະຫນາດໃຫຍ່.
ແຕ່ໃນທີ່ນີ້ມັນເຫມາະສົມທີ່ຈະຈື່ຈໍາວ່າພວກເຮົາໄດ້ຕັດສິນໃຈທີ່ຈະເກັບຂໍ້ມູນໃນຮູບແບບທີ່ຖືກບີບອັດ, ແລະດັ່ງນັ້ນພວກເຮົາສູນເສຍຂໍ້ມູນທັງຫມົດໃນຫນ້າຫຼັງຈາກບັນທຶກ "ແຕກ", ດັ່ງນັ້ນເຖິງແມ່ນວ່າມີເຄື່ອງຫມາຍລົບຢູ່ໃນຕາຕະລາງ, ພວກເຮົາບໍ່ໄດ້ເຮັດ. ເອົາມັນເຂົ້າໄປໃນບັນຊີ.

ຄວາມຫນາແຫນ້ນ:

• ໃນຕົວເລືອກທໍາອິດ, ພວກເຮົາຕ້ອງການເກັບຄວາມຍາວພຽງແຕ່ຢູ່ໃນສ່ວນຫົວ;
• ໃນທາງເລືອກທີສອງພວກເຮົາຈໍາເປັນຕ້ອງເກັບຮັກສາທີ່ຢູ່ເລີ່ມຕົ້ນແລະຄວາມຍາວ; ບັນທຶກຕ້ອງເປັນຂະຫນາດຄົງທີ່, ຂ້າພະເຈົ້າຄາດຄະເນ 4 bytes ຕໍ່ບັນທຶກ (ສອງ bytes ສໍາລັບ offset, ແລະສອງ bytes ສໍາລັບຄວາມຍາວ);
• ທາງເລືອກທີສາມພຽງແຕ່ຕ້ອງການຕົວລະຄອນຫນຶ່ງເພື່ອຊີ້ໃຫ້ເຫັນເຖິງການເລີ່ມຕົ້ນຂອງການບັນທຶກ, ບວກກັບການບັນທຶກຕົວມັນເອງຈະເພີ່ມຂຶ້ນ 1-2% ເນື່ອງຈາກການປ້ອງກັນ. ໂດຍທົ່ວໄປ, ປະມານ parity ກັບທາງເລືອກທໍາອິດ.

ໃນເບື້ອງຕົ້ນ, ຂ້າພະເຈົ້າໄດ້ພິຈາລະນາທາງເລືອກທີສອງເປັນທາງເລືອກຕົ້ນຕໍ (ແລະແມ້ກະທັ້ງຂຽນການປະຕິບັດ). ຂ້າພະເຈົ້າໄດ້ປະຖິ້ມມັນພຽງແຕ່ໃນເວລາທີ່ຂ້າພະເຈົ້າສຸດທ້າຍໄດ້ຕັດສິນໃຈທີ່ຈະນໍາໃຊ້ການບີບອັດ.

ບາງທີມື້ຫນຶ່ງຂ້ອຍຍັງຈະໃຊ້ທາງເລືອກທີ່ຄ້າຍຄືກັນ. ຕົວຢ່າງ, ຖ້າຂ້ອຍຕ້ອງຈັດການກັບການເກັບຮັກສາຂໍ້ມູນສໍາລັບເຮືອທີ່ເດີນທາງລະຫວ່າງໂລກແລະດາວອັງຄານ, ຈະມີຄວາມຕ້ອງການທີ່ແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງສໍາລັບຄວາມຫນ້າເຊື່ອຖື, ລັງສີ cosmic, ...

ສໍາລັບທາງເລືອກທີສາມ: ຂ້າພະເຈົ້າໄດ້ໃຫ້ມັນສອງດາວສໍາລັບຄວາມຫຍຸ້ງຍາກໃນການປະຕິບັດພຽງແຕ່ຍ້ອນວ່າຂ້ອຍບໍ່ມັກການຂັດຂວາງ, ການປ່ຽນແປງຄວາມຍາວໃນຂະບວນການ, ແລະອື່ນໆ. ແມ່ນແລ້ວ, ບາງທີຂ້ອຍມີຄວາມລໍາອຽງ, ແຕ່ຂ້ອຍຈະຕ້ອງຂຽນລະຫັດ - ເປັນຫຍັງບັງຄັບຕົວເອງໃຫ້ເຮັດບາງສິ່ງທີ່ເຈົ້າບໍ່ມັກ.

ສະຫຼຸບສັງລວມ: ພວກເຮົາເລືອກທາງເລືອກໃນການເກັບຮັກສາໃນຮູບແບບຂອງລະບົບຕ່ອງໂສ້ "header ກັບຄວາມຍາວ - ຂໍ້ມູນຂອງຄວາມຍາວຕົວແປ" ເນື່ອງຈາກປະສິດທິພາບແລະຄວາມສະດວກໃນການປະຕິບັດ.

ການນໍາໃຊ້ Bit Fields ເພື່ອຕິດຕາມຄວາມສໍາເລັດຂອງການປະຕິບັດການຂຽນ

ຂ້ອຍບໍ່ຈື່ວ່າຂ້ອຍໄດ້ແນວຄວາມຄິດຢູ່ໃສ, ແຕ່ມັນເບິ່ງຄືວ່າ:
ສໍາລັບແຕ່ລະລາຍການ, ພວກເຮົາຈັດສັນຫຼາຍບິດເພື່ອເກັບຮັກສາທຸງ.
ດັ່ງທີ່ພວກເຮົາໄດ້ກ່າວກ່ອນຫນ້ານີ້, ຫຼັງຈາກລຶບ bits ທັງຫມົດແມ່ນເຕັມໄປດ້ວຍ 1s, ແລະພວກເຮົາສາມາດປ່ຽນ 1 ຫາ 0, ແຕ່ບໍ່ແມ່ນກົງກັນຂ້າມ. ດັ່ງນັ້ນ, ສໍາລັບ "ທຸງບໍ່ໄດ້ຕັ້ງ" ພວກເຮົາໃຊ້ 1, ສໍາລັບ "ທຸງຖືກຕັ້ງ" ພວກເຮົາໃຊ້ 0.

ນີ້ແມ່ນສິ່ງທີ່ການວາງບັນທຶກຄວາມຍາວຕົວແປເຂົ້າໄປໃນແຟດອາດເບິ່ງຄືວ່າ:

1. ກໍານົດທຸງ “ການບັນທຶກຄວາມຍາວໄດ້ເລີ່ມຕົ້ນແລ້ວ”;
2. ບັນທຶກຄວາມຍາວ;
3. ກໍານົດ "ການບັນທຶກຂໍ້ມູນໄດ້ເລີ່ມຕົ້ນ" ທຸງ;
4. ພວກເຮົາບັນທຶກຂໍ້ມູນ;
5. ກໍານົດທຸງ "ການບັນທຶກສິ້ນສຸດລົງ".

ນອກຈາກນັ້ນ, ພວກເຮົາຈະມີທຸງ "ເກີດຄວາມຜິດພາດ", ສໍາລັບຈໍານວນທັງຫມົດ 4 ທຸງບິດ.

ໃນກໍລະນີນີ້, ພວກເຮົາມີສອງສະຖານະທີ່ຫມັ້ນຄົງ "1111" - ການບັນທຶກບໍ່ໄດ້ເລີ່ມຕົ້ນແລະ "1000" - ການບັນທຶກສົບຜົນສໍາເລັດ; ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ການ​ຂັດ​ຂວາງ​ທີ່​ບໍ່​ຄາດ​ຄິດ​ຂອງ​ຂະ​ບວນ​ການ​ການ​ບັນ​ທຶກ​, ພວກ​ເຮົາ​ຈະ​ໄດ້​ຮັບ​ລັດ​ປານ​ກາງ​, ທີ່​ພວກ​ເຮົາ​ສາ​ມາດ​ກວດ​ພົບ​ແລະ​ປຸງ​ແຕ່ງ​.

ວິທີການແມ່ນຫນ້າສົນໃຈ, ແຕ່ມັນພຽງແຕ່ປົກປ້ອງການປິດໄຟຟ້າຢ່າງກະທັນຫັນແລະຄວາມລົ້ມເຫຼວທີ່ຄ້າຍຄືກັນ, ເຊິ່ງ, ແນ່ນອນ, ແມ່ນສໍາຄັນ, ແຕ່ນີ້ແມ່ນຢູ່ໄກຈາກເຫດຜົນດຽວ (ຫຼືແມ້ກະທັ້ງຕົ້ນຕໍ) ສໍາລັບຄວາມລົ້ມເຫຼວທີ່ເປັນໄປໄດ້.

ສະຫຼຸບສັງລວມ: ຂໍໃຫ້ກ້າວຕໍ່ໄປໃນການຊອກຫາທາງອອກທີ່ດີ.

ເຊັກsums

Checksums ຍັງເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະໃຫ້ແນ່ໃຈວ່າ (ມີຄວາມເປັນໄປໄດ້ທີ່ສົມເຫດສົມຜົນ) ວ່າພວກເຮົາກໍາລັງອ່ານສິ່ງທີ່ຄວນຂຽນ. ແລະ, ບໍ່ເຫມືອນກັບພາກສະຫນາມນ້ອຍທີ່ສົນທະນາຂ້າງເທິງ, ພວກມັນເຮັດວຽກຢູ່ສະເຫມີ.

ຖ້າພວກເຮົາພິຈາລະນາບັນຊີລາຍຊື່ຂອງແຫຼ່ງທີ່ເປັນໄປໄດ້ຂອງບັນຫາທີ່ພວກເຮົາໄດ້ສົນທະນາຂ້າງເທິງ, ຫຼັງຈາກນັ້ນ checksum ສາມາດຮັບຮູ້ຄວາມຜິດພາດໄດ້ໂດຍບໍ່ຄໍານຶງເຖິງຕົ້ນກໍາເນີດຂອງມັນ. (ຍົກເວັ້ນ, ບາງທີ, ສໍາລັບມະນຸດຕ່າງດາວທີ່ເປັນອັນຕະລາຍ - ພວກເຂົາສາມາດປອມແປງເຊັກໄດ້ເຊັ່ນກັນ).

ດັ່ງນັ້ນຖ້າເປົ້າຫມາຍຂອງພວກເຮົາແມ່ນເພື່ອກວດສອບວ່າຂໍ້ມູນແມ່ນ intact, checksums ແມ່ນຄວາມຄິດທີ່ດີ.

ທາງເລືອກຂອງສູດການຄິດໄລ່ສໍາລັບການຄິດໄລ່ checksum ບໍ່ໄດ້ຍົກຄໍາຖາມໃດໆ - CRC. ໃນອີກດ້ານຫນຶ່ງ, ຄຸນສົມບັດທາງຄະນິດສາດເຮັດໃຫ້ມັນສາມາດຈັບບາງປະເພດຂອງຄວາມຜິດພາດ 100% ໃນອີກດ້ານຫນຶ່ງ, ຂໍ້ມູນແບບສຸ່ມ algorithm ນີ້ປົກກະຕິແລ້ວສະແດງໃຫ້ເຫັນຄວາມເປັນໄປໄດ້ຂອງການ collision ບໍ່ຫຼາຍກ່ວາຂອບເຂດຈໍາກັດທາງທິດສະດີ. . ມັນອາດຈະບໍ່ແມ່ນສູດການຄິດໄລ່ທີ່ໄວທີ່ສຸດ, ຫຼືວ່າມັນເປັນຕໍາ່ສຸດທີ່ກ່ຽວກັບຈໍານວນຂອງການປະທະກັນ, ແຕ່ມັນມີຄຸນນະພາບທີ່ສໍາຄັນຫຼາຍ: ໃນການທົດສອບທີ່ຂ້ອຍພົບ, ບໍ່ມີຮູບແບບໃດໆທີ່ມັນລົ້ມເຫລວຢ່າງຊັດເຈນ. ສະຖຽນລະພາບແມ່ນຄຸນນະພາບຕົ້ນຕໍໃນກໍລະນີນີ້.

ຕົວຢ່າງຂອງການສຶກສາ volumetric: ສ່ວນ 1, ສ່ວນ 2 (ການ​ເຊື່ອມ​ຕໍ່​ກັບ narod.ru​, ຂໍ​ອະ​ໄພ​).

ຢ່າງໃດກໍຕາມ, ວຽກງານຂອງການເລືອກ checksum ແມ່ນບໍ່ສໍາເລັດ; ທ່ານຈໍາເປັນຕ້ອງຕັດສິນໃຈກ່ຽວກັບຄວາມຍາວ, ແລະຫຼັງຈາກນັ້ນເລືອກ polynomial.

ການເລືອກຄວາມຍາວຂອງ checksum ບໍ່ແມ່ນຄໍາຖາມທີ່ງ່າຍດາຍຍ້ອນວ່າມັນເບິ່ງຄືວ່າຢູ່ glance ທໍາອິດ.

ໃຫ້ຂ້ອຍຍົກຕົວຢ່າງ:
ໃຫ້ພວກເຮົາມີຄວາມເປັນໄປໄດ້ຂອງຄວາມຜິດພາດໃນແຕ່ລະ byte ແລະ checksum ທີ່ເຫມາະສົມ, ໃຫ້ຄິດໄລ່ຈໍານວນຄວາມຜິດພາດໂດຍສະເລ່ຍຕໍ່ລ້ານບັນທຶກ:

ຂໍ້ມູນ, byte
Checksum, byte
ຂໍ້ຜິດພາດທີ່ບໍ່ໄດ້ກວດພົບ
ການກວດສອບຄວາມຜິດພາດທີ່ບໍ່ຖືກຕ້ອງ
ຜົນບວກທີ່ບໍ່ຖືກຕ້ອງທັງໝົດ

1
0
1000
0
1000

1
1
4
999
1003

1
2
0
1997
1997

1
4
0
3990
3990

10
0
9955
0
9955

10
1
39
990
1029

10
2
0
1979
1979

10
4
0
3954
3954

1000
0
632305
0
632305

1000
1
2470
368
2838

1000
2
10
735
745

1000
4
0
1469
1469

ມັນຈະເບິ່ງຄືວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍ - ອີງຕາມຄວາມຍາວຂອງຂໍ້ມູນທີ່ຖືກປ້ອງກັນ, ເລືອກຄວາມຍາວຂອງ checksum ທີ່ມີຕໍາ່ສຸດທີ່ຂອງຜົນບວກທີ່ບໍ່ຖືກຕ້ອງ - ແລະ trick ແມ່ນຢູ່ໃນຖົງ.

ຢ່າງໃດກໍຕາມ, ບັນຫາທີ່ເກີດຂື້ນກັບ checksums ສັ້ນ: ເຖິງແມ່ນວ່າພວກເຂົາດີໃນການກວດສອບຂໍ້ຜິດພາດເລັກນ້ອຍ, ພວກເຂົາສາມາດມີຄວາມເປັນໄປໄດ້ສູງພໍສົມຄວນທີ່ຈະຍອມຮັບຂໍ້ມູນແບບສຸ່ມຢ່າງສົມບູນ. ມີບົດຄວາມກ່ຽວກັບ Habre ອະທິບາຍຢູ່ແລ້ວ ບັນຫາໃນຊີວິດຈິງ.

ດັ່ງນັ້ນ, ເພື່ອເຮັດໃຫ້ການຈັບຄູ່ checksum ແບບສຸ່ມເກືອບເປັນໄປບໍ່ໄດ້, ທ່ານຈໍາເປັນຕ້ອງໃຊ້ checksums ທີ່ມີຄວາມຍາວ 32 bits ຫຼືຍາວກວ່າ. (ສໍາລັບຄວາມຍາວຫຼາຍກວ່າ 64 ບິດ, ຟັງຊັນ cryptographic hash ມັກຈະຖືກນໍາໃຊ້).

ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າຂ້າພະເຈົ້າໄດ້ຂຽນໄວ້ກ່ອນຫນ້ານີ້ວ່າພວກເຮົາຈໍາເປັນຕ້ອງປະຫຍັດພື້ນທີ່ໂດຍວິທີການທັງຫມົດ, ພວກເຮົາຍັງຈະໃຊ້ checksum 32-bit (16 bits ແມ່ນບໍ່ພຽງພໍ, ຄວາມເປັນໄປໄດ້ຂອງການປະທະກັນແມ່ນຫຼາຍກ່ວາ 0.01%; ແລະ 24 bits, ຍ້ອນວ່າພວກເຂົາ. ເວົ້າ, ບໍ່ຢູ່ທີ່ນີ້ຫຼືບໍ່ມີ).

ການຄັດຄ້ານອາດຈະເກີດຂື້ນຢູ່ທີ່ນີ້: ພວກເຮົາໄດ້ບັນທຶກທຸກ byte ໃນເວລາເລືອກການບີບອັດເພື່ອຕອນນີ້ໃຫ້ 4 bytes ໃນເວລາດຽວກັນບໍ? ມັນດີກວ່າທີ່ຈະບໍ່ບີບອັດຫຼືເພີ່ມ checksum ບໍ? ແນ່ນອນ, ບໍ່ມີການບີບອັດ ບໍ່ໄດ້ຫມາຍຄວາມວ່າ, ທີ່ພວກເຮົາບໍ່ຕ້ອງການການກວດສອບຄວາມຊື່ສັດ.

ໃນເວລາທີ່ເລືອກ polynomial, ພວກເຮົາຈະບໍ່ reinvent ລໍ້, ແຕ່ເອົາ CRC-32C ທີ່ນິຍົມໃນປັດຈຸບັນ.
ລະຫັດນີ້ກວດພົບຂໍ້ຜິດພາດ 6 ບິດໃນແພັກເກັດເຖິງ 22 ໄບຕ໌ (ບາງທີອາດເປັນກໍລະນີທົ່ວໄປທີ່ສຸດສຳລັບພວກເຮົາ), ຂໍ້ຜິດພາດ 4 ບິດໃນແພັກເກັດສູງເຖິງ 655 ໄບຕ໌ (ຍັງເປັນກໍລະນີທົ່ວໄປສຳລັບພວກເຮົາ), 2 ຫຼືຈຳນວນຄີກຂອງຂໍ້ຜິດພາດໃນແພັກເກັດ. ຂອງຄວາມຍາວທີ່ເຫມາະສົມໃດໆ.

ຖ້າໃຜສົນໃຈລາຍລະອຽດ

ບົດຄວາມວິກິພີເດຍ ກ່ຽວກັບ CRC.

ຕົວກໍານົດການລະຫັດ CRC-32c ສຸດ ເວັບໄຊທ໌ Koopman — ບາງທີຜູ້ຊ່ຽວຊານດ້ານ CRC ຊັ້ນນໍາໃນໂລກ.

В ບົດ​ຄວາມ​ຂອງ​ຕົນ ມີແມ່ນ ລະຫັດທີ່ຫນ້າສົນໃຈອີກອັນຫນຶ່ງ, ເຊິ່ງສະຫນອງຕົວກໍານົດການທີ່ດີກວ່າເລັກນ້ອຍສໍາລັບຄວາມຍາວຂອງແພັກເກັດທີ່ກ່ຽວຂ້ອງກັບພວກເຮົາ, ແຕ່ຂ້ອຍບໍ່ໄດ້ພິຈາລະນາຄວາມແຕກຕ່າງທີ່ສໍາຄັນ, ແລະຂ້ອຍມີຄວາມສາມາດພຽງພໍທີ່ຈະເລືອກລະຫັດທີ່ກໍາຫນົດເອງແທນທີ່ຈະເປັນມາດຕະຖານແລະການຄົ້ນຄວ້າທີ່ດີ.

ນອກຈາກນັ້ນ, ນັບຕັ້ງແຕ່ຂໍ້ມູນຂອງພວກເຮົາຖືກບີບອັດ, ຄໍາຖາມທີ່ເກີດຂື້ນ: ພວກເຮົາຄວນຄິດໄລ່ checksum ຂອງຂໍ້ມູນທີ່ບີບອັດຫຼືບໍ່ຖືກບີບອັດບໍ?

ຂໍ້ໂຕ້ແຍ້ງໃນການຄິດໄລ່ checksum ຂອງຂໍ້ມູນທີ່ບໍ່ໄດ້ບີບອັດ:

• ພວກເຮົາສຸດທ້າຍຕ້ອງກວດສອບຄວາມປອດໄພຂອງການເກັບຮັກສາຂໍ້ມູນ - ດັ່ງນັ້ນພວກເຮົາກວດເບິ່ງມັນໂດຍກົງ (ໃນເວລາດຽວກັນ, ຄວາມຜິດພາດທີ່ເປັນໄປໄດ້ໃນການປະຕິບັດການບີບອັດ / ການບີບອັດ, ຄວາມເສຍຫາຍທີ່ເກີດຈາກຄວາມຊົງຈໍາທີ່ແຕກຫັກ, ແລະອື່ນໆຈະຖືກກວດສອບ);
• ສູດການຄິດໄລ່ deflate ໃນ zlib ມີການປະຕິບັດທີ່ຂ້ອນຂ້າງໃຫຍ່ແລະ ບໍ່ຄວນ ຫຼຸດລົງດ້ວຍຂໍ້ມູນການປ້ອນຂໍ້ມູນ "crooked" ນອກຈາກນັ້ນ, ມັນມັກຈະສາມາດກວດພົບຄວາມຜິດພາດໃນກະແສການປ້ອນຂໍ້ມູນຢ່າງເປັນເອກະລາດ, ຫຼຸດຜ່ອນຄວາມເປັນໄປໄດ້ໂດຍລວມຂອງ undetecting ຄວາມຜິດພາດ (ດໍາເນີນການທົດສອບກັບ inverting ບິດດຽວໃນບັນທຶກສັ້ນ, zlib ກວດພົບຄວາມຜິດພາດ. ໃນປະມານຫນຶ່ງສ່ວນສາມຂອງກໍລະນີ).

ການໂຕ້ຖຽງຕໍ່ການຄິດໄລ່ checksum ຂອງຂໍ້ມູນທີ່ບໍ່ໄດ້ບີບອັດ:

• CRC ແມ່ນ "ປັບ" ໂດຍສະເພາະສໍາລັບຄວາມຜິດພາດເລັກນ້ອຍທີ່ເປັນລັກສະນະຂອງຫນ່ວຍຄວາມຈໍາແຟດ (ຄວາມຜິດພາດເລັກນ້ອຍໃນສາຍນ້ໍາທີ່ຖືກບີບອັດສາມາດເຮັດໃຫ້ເກີດການປ່ຽນແປງຢ່າງຫຼວງຫຼາຍໃນກະແສຜົນຜະລິດ, ເຊິ່ງ, ໃນທາງທິດສະດີ, ພວກເຮົາສາມາດ "ຈັບ" ການຂັດກັນ);
• ຂ້ອຍບໍ່ມັກຄວາມຄິດທີ່ຈະສົ່ງຂໍ້ມູນທີ່ອາດຈະແຕກຫັກໄປຫາ decompressor, ໃຜ​ຈະ​ຮູ້ລາວຈະຕອບໂຕ້ແນວໃດ.

ໃນໂຄງການນີ້, ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈ deviate ຈາກການປະຕິບັດທີ່ຍອມຮັບໂດຍທົ່ວໄປຂອງການເກັບຮັກສາ checksum ຂອງຂໍ້ມູນທີ່ບໍ່ໄດ້ບີບອັດ.

ສະຫຼຸບສັງລວມ: ພວກເຮົາໃຊ້ CRC-32C, ພວກເຮົາຄິດໄລ່ checksum ຈາກຂໍ້ມູນໃນຮູບແບບທີ່ພວກມັນຖືກຂຽນໃສ່ flash (ຫຼັງຈາກການບີບອັດ).

ຊ້ຳຊ້ອນ

ການນໍາໃຊ້ລະຫັດຊ້ໍາຊ້ອນບໍ່ໄດ້, ແນ່ນອນ, ລົບລ້າງການສູນເສຍຂໍ້ມູນ, ຢ່າງໃດກໍຕາມ, ມັນສາມາດຢ່າງຫຼວງຫຼາຍ (ໂດຍຄໍາສັ່ງຈໍານວນຫຼາຍຂອງຂະຫນາດ) ຫຼຸດຜ່ອນຄວາມເປັນໄປໄດ້ຂອງການສູນເສຍຂໍ້ມູນ irrecoverable.

ພວກເຮົາສາມາດນໍາໃຊ້ປະເພດທີ່ແຕກຕ່າງກັນຂອງຊ້ໍາຊ້ອນເພື່ອແກ້ໄຂຂໍ້ຜິດພາດ.
ລະຫັດ Hamming ສາມາດແກ້ໄຂຂໍ້ຜິດພາດເລັກນ້ອຍ, ລະຫັດຕົວອັກສອນ Reed-Solomon, ສໍາເນົາຂໍ້ມູນຫຼາຍອັນລວມກັບ checksums, ຫຼືການເຂົ້າລະຫັດເຊັ່ນ RAID-6 ສາມາດຊ່ວຍຟື້ນຕົວຂໍ້ມູນເຖິງແມ່ນວ່າໃນກໍລະນີຂອງການສໍ້ລາດບັງຫຼວງຂະຫນາດໃຫຍ່.
ໃນເບື້ອງຕົ້ນ, ຂ້າພະເຈົ້າໄດ້ມຸ່ງຫມັ້ນທີ່ຈະໃຊ້ຢ່າງແຜ່ຫຼາຍຂອງລະຫັດຕ້ານຄວາມຜິດພາດ, ແຕ່ຫຼັງຈາກນັ້ນຂ້າພະເຈົ້າຮັບຮູ້ວ່າທໍາອິດພວກເຮົາຈໍາເປັນຕ້ອງມີຄວາມຄິດຂອງຄວາມຜິດພາດທີ່ພວກເຮົາຕ້ອງການທີ່ຈະປ້ອງກັນຕົວເຮົາເອງຈາກ, ແລະຫຼັງຈາກນັ້ນເລືອກເອົາການເຂົ້າລະຫັດ.

ພວກເຮົາເວົ້າກ່ອນຫນ້ານີ້ວ່າຄວາມຜິດພາດຕ້ອງໄດ້ຮັບການຈັບໄດ້ໄວເທົ່າທີ່ຈະໄວໄດ້. ພວກເຮົາສາມາດພົບຂໍ້ຜິດພາດໃນຈຸດໃດແດ່?

1. ການ​ບັນ​ທຶກ​ທີ່​ບໍ່​ສໍາ​ເລັດ (ສໍາ​ລັບ​ເຫດ​ຜົນ​ບາງ​ຢ່າງ​ໃນ​ເວ​ລາ​ຂອງ​ການ​ບັນ​ທຶກ​ການ​ພະ​ລັງ​ງານ​ໄດ້​ປິດ​, Raspberry froze​, ... )
   ອະນິຈາ, ໃນກໍລະນີຂອງຄວາມຜິດພາດດັ່ງກ່າວ, ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນເພື່ອບໍ່ສົນໃຈບັນທຶກທີ່ບໍ່ຖືກຕ້ອງແລະພິຈາລະນາຂໍ້ມູນທີ່ສູນເສຍ;
2. ຂຽນຂໍ້ຜິດພາດ (ສໍາລັບບາງເຫດຜົນ, ສິ່ງທີ່ຂຽນໃສ່ຫນ່ວຍຄວາມຈໍາ flash ບໍ່ແມ່ນສິ່ງທີ່ຂຽນ)
   ພວກເຮົາສາມາດກວດພົບຄວາມຜິດພາດດັ່ງກ່າວໄດ້ທັນທີຖ້າພວກເຮົາເຮັດການທົດສອບອ່ານທັນທີຫຼັງຈາກບັນທຶກ;
3. ການບິດເບືອນຂໍ້ມູນໃນຫນ່ວຍຄວາມຈໍາໃນລະຫວ່າງການເກັບຮັກສາ;
4. ການອ່ານຜິດພາດ
   ເພື່ອແກ້ໄຂມັນ, ຖ້າ checksum ບໍ່ກົງກັນ, ມັນພຽງພໍທີ່ຈະເຮັດຊ້ໍາການອ່ານຫຼາຍຄັ້ງ.

ນັ້ນແມ່ນ, ຂໍ້ຜິດພາດຂອງປະເພດທີສາມເທົ່ານັ້ນ (ການສໍ້ລາດບັງຫຼວງຂອງຂໍ້ມູນໃນລະຫວ່າງການເກັບຮັກສາ) ບໍ່ສາມາດແກ້ໄຂໄດ້ໂດຍບໍ່ມີຄວາມຜິດພາດທີ່ທົນທານຕໍ່ລະຫັດ. ມັນເບິ່ງຄືວ່າຄວາມຜິດພາດດັ່ງກ່າວຍັງເປັນໄປບໍ່ໄດ້ທີ່ສຸດ.

ສະຫຼຸບສັງລວມ: ມັນໄດ້ຖືກຕັດສິນໃຈທີ່ຈະປະຖິ້ມການເຂົ້າລະຫັດທີ່ຊ້ໍາກັນ, ແຕ່ຖ້າການດໍາເນີນງານສະແດງໃຫ້ເຫັນຄວາມຜິດພາດຂອງການຕັດສິນໃຈນີ້, ຫຼັງຈາກນັ້ນກັບຄືນສູ່ການພິຈາລະນາບັນຫາ (ດ້ວຍສະຖິຕິທີ່ສະສົມແລ້ວກ່ຽວກັບຄວາມລົ້ມເຫລວ, ເຊິ່ງຈະຊ່ວຍໃຫ້ເລືອກປະເພດທີ່ດີທີ່ສຸດຂອງລະຫັດ).

ອື່ນ ໆ

ແນ່ນອນ, ຮູບແບບຂອງບົດຄວາມບໍ່ໄດ້ອະນຸຍາດໃຫ້ພວກເຮົາພຽງແຕ່ແກ້ໄຂທຸກຮູບແບບ (ແລະ​ຄວາມ​ເຂັ້ມ​ແຂງ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ຫມົດ​ໄປ​ແລ້ວ​), ສະນັ້ນຂ້າພະເຈົ້າຈະໄປໄລຍະສັ້ນໆກ່ຽວກັບບາງຈຸດທີ່ບໍ່ໄດ້ສໍາຜັດກັບກ່ອນຫນ້ານີ້.

• ມັນໄດ້ຖືກຕັດສິນໃຈເພື່ອເຮັດໃຫ້ຫນ້າທັງຫມົດ "ເທົ່າທຽມກັນ"
  ນັ້ນແມ່ນ, ຈະບໍ່ມີຫນ້າພິເສດທີ່ມີ metadata, ກະທູ້ແຍກຕ່າງຫາກ, ແລະອື່ນໆ, ແຕ່ແທນທີ່ຈະເປັນຫົວຂໍ້ດຽວທີ່ຂຽນຄືນຫນ້າທັງຫມົດ.
  ນີ້ຮັບປະກັນແມ້ກະທັ້ງໃສ່ໃນຫນ້າເວັບຕ່າງໆ, ບໍ່ມີຈຸດດຽວຂອງຄວາມລົ້ມເຫຼວ, ແລະຂ້ອຍກໍ່ມັກມັນ;
• ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະສະຫນອງການສະບັບຂອງຮູບແບບ.
  ຮູບແບບທີ່ບໍ່ມີໝາຍເລກເວີຊັນຢູ່ໃນສ່ວນຫົວແມ່ນຊົ່ວ!
  ມັນພຽງພໍທີ່ຈະເພີ່ມພາກສະຫນາມທີ່ມີຈໍານວນ Magic (ລາຍເຊັນ) ທີ່ແນ່ນອນໃສ່ຫົວຫນ້າ, ເຊິ່ງຈະຊີ້ບອກສະບັບຂອງຮູບແບບທີ່ໃຊ້. (ຂ້ອຍບໍ່ຄິດວ່າໃນທາງປະຕິບັດຈະມີຫຼາຍສິບຄົນ);
• ໃຊ້ header ຄວາມຍາວຕົວແປສໍາລັບບັນທຶກ (ຊຶ່ງໃນນັ້ນມີຈໍານວນຫລາຍ), ພະຍາຍາມເຮັດໃຫ້ມັນຍາວ 1 byte ໃນກໍລະນີຫຼາຍທີ່ສຸດ;
• ເພື່ອເຂົ້າລະຫັດຄວາມຍາວຂອງສ່ວນຫົວ ແລະຄວາມຍາວຂອງສ່ວນທີ່ຖືກຕັດອອກຂອງບັນທຶກທີ່ບີບອັດ, ໃຫ້ໃຊ້ລະຫັດສອງຄວາມຍາວຕົວແປ.

ຊ່ວຍຫຼາຍ ເຄື່ອງກໍາເນີດອອນໄລນ໌ ລະຫັດ Huffman. ໃນເວລາພຽງສອງສາມນາທີພວກເຮົາສາມາດເລືອກລະຫັດຄວາມຍາວຕົວແປທີ່ຕ້ອງການ.

ລາຍລະອຽດຂອງຮູບແບບການເກັບຮັກສາຂໍ້ມູນ

ຄໍາສັ່ງ byte

ຊ່ອງຂໍ້ມູນໃຫຍ່ກວ່າໜຶ່ງໄບຕ໌ຖືກເກັບໄວ້ໃນຮູບແບບໃຫຍ່ສຸດ (ລຳດັບໄບຕ໌ຂອງເຄືອຂ່າຍ), ນັ້ນຄື 0x1234 ຖືກຂຽນເປັນ 0x12, 0x34.

Pagination

ຫນ່ວຍຄວາມຈໍາແຟດທັງຫມົດຖືກແບ່ງອອກເປັນຫນ້າທີ່ມີຂະຫນາດເທົ່າທຽມກັນ.

ຂະຫນາດຫນ້າເລີ່ມຕົ້ນແມ່ນ 32Kb, ແຕ່ບໍ່ເກີນ 1/4 ຂອງຂະຫນາດທັງຫມົດຂອງຊິບຫນ່ວຍຄວາມຈໍາ (ສໍາລັບຊິບ 4MB, 128 ຫນ້າແມ່ນໄດ້ຮັບ).

ແຕ່ລະຫນ້າເກັບຮັກສາຂໍ້ມູນເປັນເອກະລາດຈາກຫນ້າອື່ນໆ (ນັ້ນແມ່ນ, ຂໍ້ມູນໃນຫນ້າຫນຶ່ງບໍ່ໄດ້ອ້າງອີງຂໍ້ມູນໃນຫນ້າອື່ນ).

ຫນ້າທັງຫມົດແມ່ນຕົວເລກຕາມລໍາດັບທໍາມະຊາດ (ໃນລໍາດັບຕັ້ງໄປຫາໃຫຍ່ຂອງທີ່ຢູ່), ໂດຍເລີ່ມຕົ້ນດ້ວຍເລກ 0 (ຫນ້າສູນເລີ່ມຕົ້ນທີ່ທີ່ຢູ່ 0, ຫນ້າທໍາອິດເລີ່ມຕົ້ນທີ່ 32Kb, ຫນ້າທີສອງເລີ່ມຕົ້ນທີ່ 64Kb, ແລະອື່ນໆ).

ຊິບຫນ່ວຍຄວາມຈໍາຖືກນໍາໃຊ້ເປັນວົງຈອນ buffer (ring buffer), ນັ້ນແມ່ນ, ການຂຽນຄັ້ງທໍາອິດໄປຫາຫນ້າ 0, ຫຼັງຈາກນັ້ນຫມາຍເລກ 1, ..., ເມື່ອພວກເຮົາຕື່ມຂໍ້ມູນໃສ່ຫນ້າສຸດທ້າຍ, ຮອບວຽນໃຫມ່ເລີ່ມຕົ້ນແລະການບັນທຶກສືບຕໍ່ຈາກຫນ້າສູນ. .

ພາຍໃນຫນ້າ

ໃນຕອນຕົ້ນຂອງຫນ້າ, ຫົວຫນ້າ 4-byte ຖືກເກັບໄວ້, ຫຼັງຈາກນັ້ນເປັນ header checksum (CRC-32C), ຫຼັງຈາກນັ້ນບັນທຶກຈະຖືກເກັບໄວ້ໃນຮູບແບບ "header, ຂໍ້ມູນ, checksum".

ຫົວຂໍ້ໜ້າ (ສີຂຽວເປື້ອນຢູ່ໃນແຜນວາດ) ປະກອບດ້ວຍ:

• ຊ່ອງຂໍ້ມູນເລກ Magic ສອງໄບ (ຍັງເປັນເຄື່ອງໝາຍຂອງສະບັບຮູບແບບ)
  ສໍາລັບສະບັບປະຈຸບັນຂອງຮູບແບບມັນຖືກຄິດໄລ່ເປັນ 0xed00 ⊕ номер страницы;
• ໂຕນັບສອງໄບຕ໌ “ສະບັບໜ້າ” (ໜ່ວຍຄວາມຈຳຂຽນຄືນໝາຍເລກຮອບວຽນ).

ການປ້ອນຂໍ້ມູນໃນຫນ້າເວັບຖືກເກັບໄວ້ໃນຮູບແບບບີບອັດ (ລະບົບການ deflate algorithm ຖືກນໍາໃຊ້). ບັນທຶກທັງໝົດຢູ່ໃນໜ້າດຽວຖືກບີບອັດຢູ່ໃນກະທູ້ດຽວ (ວັດຈະນານຸກົມທົ່ວໄປຖືກໃຊ້), ແລະການບີບອັດໜ້າໃໝ່ແຕ່ລະຄັ້ງຈະເລີ່ມໃໝ່. ນັ້ນແມ່ນ, ເພື່ອບີບອັດບັນທຶກໃດໆ, ບັນທຶກທີ່ຜ່ານມາທັງຫມົດຈາກຫນ້ານີ້ (ແລະພຽງແຕ່ອັນນີ້ເທົ່ານັ້ນ) ແມ່ນຕ້ອງການ.

ແຕ່ລະບັນທຶກຈະຖືກບີບອັດດ້ວຍທຸງ Z_SYNC_FLUSH, ແລະໃນຕອນທ້າຍຂອງກະແສທີ່ຖືກບີບອັດຈະມີ 4 ໄບຕ໌ 0x00, 0x00, 0xff, 0xff, ອາດຈະຖືກນຳໜ້າດ້ວຍໜຶ່ງ ຫຼື ສອງສູນໄບທ໌.
ພວກເຮົາຍົກເລີກລໍາດັບນີ້ (ຍາວ 4, 5 ຫຼື 6 ໄບຕ໌) ເມື່ອຂຽນໃສ່ຫນ່ວຍຄວາມຈໍາ flash.

ຫົວບັນທຶກແມ່ນ 1, 2 ຫຼື 3 bytes ເກັບຮັກສາ:

• one bit (T) ຊີ້ບອກປະເພດຂອງບັນທຶກ: 0 - context, 1 - log;
• ຊ່ອງຂໍ້ມູນຄວາມຍາວຕົວແປ (S) ຈາກ 1 ຫາ 7 bits, ການກໍານົດຄວາມຍາວຂອງ header ແລະ "ຫາງ" ທີ່ຕ້ອງໄດ້ຮັບການເພີ່ມເຂົ້າໃນບັນທຶກສໍາລັບການ decompression;
• ຄວາມຍາວບັນທຶກ (L).

ຕາຕະລາງມູນຄ່າ S:

S
ຄວາມຍາວສ່ວນຫົວ, ໄບຕ໌
ຍົກເລີກໃນການຂຽນ, byte

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 (ຄວາມຍາວຂອງຂໍ້ມູນທີ່ຖືກບີບອັດເປັນ bytes), ສີຟ້າຂອງຂໍ້ມູນທີ່ຖືກບີບອັດ, ສີແດງຂອງ bytes ສຸດທ້າຍຂອງຂໍ້ມູນທີ່ຖືກບີບອັດທີ່ບໍ່ໄດ້ຖືກຂຽນໃສ່ flash memory.

ດັ່ງນັ້ນ, ພວກເຮົາສາມາດຂຽນຫົວບັນທຶກຂອງຄວາມຍາວທົ່ວໄປທີ່ສຸດ (ເຖິງ 63 + 5 bytes ໃນຮູບແບບບີບອັດ) ໃນຫນຶ່ງ byte.

ຫຼັງຈາກແຕ່ລະບັນທຶກ, ເຊັກ CRC-32C ຖືກເກັບໄວ້, ເຊິ່ງຄ່າ inverted ຂອງ checksum ທີ່ຜ່ານມາຖືກນໍາໃຊ້ເປັນມູນຄ່າເບື້ອງຕົ້ນ (init).

CRC ມີຄຸນສົມບັດຂອງ "ໄລຍະເວລາ", ສູດຕໍ່ໄປນີ້ເຮັດວຽກ (ບວກຫຼືລົບບິດ inversion ໃນຂະບວນການ): .
ນັ້ນແມ່ນ, ໃນຄວາມເປັນຈິງ, ພວກເຮົາຄິດໄລ່ CRC ຂອງທຸກ bytes ທີ່ຜ່ານມາຂອງ headers ແລະຂໍ້ມູນໃນຫນ້ານີ້.

ປະຕິບັດຕາມ checksum ໂດຍກົງແມ່ນສ່ວນຫົວຂອງບັນທຶກຕໍ່ໄປ.

header ໄດ້ຖືກອອກແບບໃນລັກສະນະທີ່ byte ທໍາອິດຂອງມັນແຕກຕ່າງຈາກ 0x00 ແລະ 0xff (ຖ້າແທນທີ່ຈະ byte ທໍາອິດຂອງ header ທີ່ພວກເຮົາພົບ 0xff, ນີ້ຫມາຍຄວາມວ່ານີ້ແມ່ນພື້ນທີ່ທີ່ບໍ່ໄດ້ໃຊ້; 0x00 ສັນຍານຄວາມຜິດພາດ).

ຕົວຢ່າງ Algorithms

ການອ່ານຈາກ Flash Memory

ການອ່ານໃດໆກໍ່ມາພ້ອມກັບການກວດສອບ checksum.
ຖ້າ checksum ບໍ່ກົງກັນ, ການອ່ານຖືກຊ້ໍາຫຼາຍຄັ້ງໃນຄວາມຫວັງທີ່ຈະອ່ານຂໍ້ມູນທີ່ຖືກຕ້ອງ.

(ນັ້ນເຮັດໃຫ້ມີຄວາມໝາຍ, Linux ບໍ່ໄດ້ເກັບຂໍ້ມູນການອ່ານຈາກ NOR Flash, ຢືນຢັນແລ້ວ)

ຂຽນໃສ່ flash memory

ພວກເຮົາບັນທຶກຂໍ້ມູນ.
ໃຫ້ເຮົາອ່ານເຂົາເຈົ້າ.

ຖ້າຂໍ້ມູນທີ່ອ່ານບໍ່ກົງກັບຂໍ້ມູນທີ່ຂຽນ, ພວກເຮົາຕື່ມຂໍ້ມູນໃສ່ພື້ນທີ່ທີ່ມີສູນແລະສະແດງຂໍ້ຜິດພາດ.

ການກະກຽມ microcircuit ໃຫມ່ສໍາລັບການດໍາເນີນງານ

ສໍາລັບການເລີ່ມຕົ້ນ, ສ່ວນຫົວທີ່ມີຮຸ່ນ 1 ແມ່ນຂຽນໃສ່ຫນ້າທໍາອິດ (ຫຼືແທນທີ່ຈະເປັນສູນ).
ຫຼັງຈາກນັ້ນ, ສະພາບການເບື້ອງຕົ້ນຖືກຂຽນໃສ່ຫນ້ານີ້ (ປະກອບດ້ວຍ UUID ຂອງເຄື່ອງແລະການຕັ້ງຄ່າເລີ່ມຕົ້ນ).

ນັ້ນແມ່ນ, ຫນ່ວຍຄວາມຈໍາ flash ແມ່ນກຽມພ້ອມສໍາລັບການນໍາໃຊ້.

ກຳລັງໂຫຼດເຄື່ອງ

ເມື່ອໂຫລດ, 8 bytes ທໍາອິດຂອງແຕ່ລະຫນ້າ (header + CRC) ຖືກອ່ານ, ຫນ້າທີ່ມີ Magic Number ທີ່ບໍ່ຮູ້ຈັກຫຼື CRC ທີ່ບໍ່ຖືກຕ້ອງຈະຖືກລະເລີຍ.
ຈາກຫນ້າ "ຖືກຕ້ອງ", ຫນ້າທີ່ມີຮຸ່ນສູງສຸດແມ່ນຖືກເລືອກ, ແລະຫນ້າທີ່ມີຈໍານວນສູງສຸດແມ່ນເອົາມາຈາກພວກມັນ.
ບັນທຶກທໍາອິດຖືກອ່ານ, ຄວາມຖືກຕ້ອງຂອງ CRC ແລະການປະກົດຕົວຂອງທຸງ "ສະພາບການ" ຖືກກວດສອບ. ຖ້າທຸກສິ່ງທຸກຢ່າງດີ, ຫນ້ານີ້ຖືວ່າເປັນປັດຈຸບັນ. ຖ້າບໍ່, ພວກເຮົາກັບຄືນໄປຫາຫນ້າກ່ອນຫນ້າຈົນກ່ວາພວກເຮົາຊອກຫາຫນ້າ "ສົດ".
ແລະໃນຫນ້າທີ່ພົບເຫັນພວກເຮົາອ່ານບັນທຶກທັງຫມົດ, ທີ່ພວກເຮົາໃຊ້ກັບທຸງ "ສະພາບການ".
ບັນທຶກວັດຈະນານຸກົມ zlib (ມັນຈະຈໍາເປັນສໍາລັບການເພີ່ມໃສ່ຫນ້ານີ້).

ນັ້ນ​ແມ່ນ​ມັນ​, ການ​ດາວ​ໂຫຼດ​ແມ່ນ​ສໍາ​ເລັດ​ສົມ​ບູນ​, ສະ​ພາບ​ການ​ໄດ້​ຮັບ​ການ​ຟື້ນ​ຟູ​, ທ່ານ​ສາ​ມາດ​ເຮັດ​ວຽກ​.

ການເພີ່ມລາຍການວາລະສານ

ພວກເຮົາບີບອັດບັນທຶກດ້ວຍວັດຈະນານຸກົມທີ່ຖືກຕ້ອງ, ລະບຸ Z_SYNC_FLUSH ພວກເຮົາເບິ່ງວ່າບັນທຶກທີ່ຖືກບີບອັດນັ້ນເຫມາະກັບຫນ້າປະຈຸບັນຫຼືບໍ່.
ຖ້າມັນບໍ່ເຫມາະສົມ (ຫຼືມີຂໍ້ຜິດພາດ CRC ໃນຫນ້າ), ເລີ່ມຕົ້ນຫນ້າໃຫມ່ (ເບິ່ງຂ້າງລຸ່ມນີ້).
ພວກເຮົາຂຽນບັນທຶກແລະ CRC. ຖ້າມີຂໍ້ຜິດພາດເກີດຂຶ້ນ, ເລີ່ມຕົ້ນຫນ້າໃຫມ່.

ໜ້າໃໝ່

ພວກເຮົາເລືອກຫນ້າຟຣີທີ່ມີຈໍານວນຕໍາ່ສຸດທີ່ (ພວກເຮົາພິຈາລະນາຫນ້າຟຣີເປັນຫນ້າທີ່ມີ checksum ທີ່ບໍ່ຖືກຕ້ອງຢູ່ໃນສ່ວນຫົວຫຼືມີສະບັບຫນ້ອຍກວ່າຫນ້າປັດຈຸບັນ). ຖ້າບໍ່ມີຫນ້າດັ່ງກ່າວ, ເລືອກເອົາຫນ້າທີ່ມີຈໍານວນຕໍາ່ສຸດທີ່ຈາກຫນ້າທີ່ມີສະບັບເທົ່າກັບຫນ້າປະຈຸບັນ.
ພວກເຮົາລຶບຫນ້າທີ່ເລືອກ. ພວກເຮົາກວດສອບເນື້ອໃນດ້ວຍ 0xff. ຖ້າມີບາງຢ່າງຜິດພາດ, ເອົາຫນ້າຟຣີຕໍ່ໄປ, ແລະອື່ນໆ.
ພວກເຮົາຂຽນ header ໃນຫນ້າທີ່ຖືກລົບ, ຫນ້າທໍາອິດແມ່ນສະຖານະປະຈຸບັນຂອງສະພາບການ, ຕໍ່ໄປແມ່ນການເຂົ້າບັນທຶກທີ່ບໍ່ໄດ້ຂຽນ (ຖ້າມີຫນຶ່ງ).

ຮູບແບບການນຳໃຊ້

ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ມັນໄດ້ກາຍມາເປັນຮູບແບບທີ່ດີສໍາລັບການເກັບຮັກສາຂໍ້ມູນການບີບອັດຫຼາຍຫຼືຫນ້ອຍ (ຂໍ້ຄວາມທໍາມະດາ, JSON, MessagePack, CBOR, ອາດຈະເປັນ protobuf) ໃນ NOR Flash.

ແນ່ນອນ, ຮູບແບບແມ່ນ "ປັບແຕ່ງ" ສໍາລັບ SLC NOR Flash.

ມັນບໍ່ຄວນໃຊ້ກັບສື່ BER ສູງເຊັ່ນ NAND ຫຼື MLC NOR (ຄວາມຊົງຈຳດັ່ງກ່າວມີໃຫ້ຂາຍບໍ? ຂ້ອຍເຄີຍເຫັນມັນກ່າວເຖິງໃນລະຫັດການແກ້ໄຂ).

ຍິ່ງໄປກວ່ານັ້ນ, ມັນບໍ່ຄວນໃຊ້ກັບອຸປະກອນທີ່ມີ FTL ຂອງຕົນເອງ: USB flash, SD, MicroSD, ແລະອື່ນໆ (ສໍາລັບຄວາມຊົງຈໍາດັ່ງກ່າວຂ້າພະເຈົ້າໄດ້ສ້າງຮູບແບບທີ່ມີຂະຫນາດຫນ້າຂອງ 512 bytes, ລາຍເຊັນໃນຕອນຕົ້ນຂອງແຕ່ລະຫນ້າແລະຕົວເລກບັນທຶກທີ່ເປັນເອກະລັກ - ບາງຄັ້ງມັນເປັນໄປໄດ້ທີ່ຈະຟື້ນຕົວຂໍ້ມູນທັງຫມົດຈາກ flash drive "ຜິດປົກກະຕິ" ໂດຍການອ່ານຕາມລໍາດັບງ່າຍດາຍ).

ອີງຕາມວຽກງານ, ຮູບແບບສາມາດຖືກນໍາໃຊ້ໂດຍບໍ່ມີການປ່ຽນແປງໃນ flash drive ຈາກ 128Kbit (16Kb) ຫາ 1Gbit (128MB). ຖ້າທ່ານຕ້ອງການ, ທ່ານສາມາດນໍາໃຊ້ມັນຢູ່ໃນຊິບຂະຫນາດໃຫຍ່, ແຕ່ທ່ານອາດຈະຕ້ອງປັບຂະຫນາດຫນ້າ (ແຕ່ໃນທີ່ນີ້ຄໍາຖາມກ່ຽວກັບຄວາມເປັນໄປໄດ້ທາງເສດຖະກິດເກີດຂື້ນແລ້ວ; ລາຄາສໍາລັບປະລິມານຂະຫນາດໃຫຍ່ NOR Flash ບໍ່ໄດ້ຊຸກຍູ້).

ຖ້າໃຜຜູ້ຫນຶ່ງພົບເຫັນຮູບແບບທີ່ຫນ້າສົນໃຈແລະຕ້ອງການໃຊ້ມັນໃນໂຄງການເປີດ, ຂຽນ, ຂ້ອຍຈະພະຍາຍາມຊອກຫາເວລາ, ຂັດລະຫັດແລະໂພດມັນຢູ່ໃນ github.

ສະຫລຸບ

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້, ໃນທີ່ສຸດຮູບແບບໄດ້ຫັນອອກເປັນງ່າຍດາຍ ແລະແມ້ແຕ່ຫນ້າເບື່ອ.

ມັນຍາກທີ່ຈະສະທ້ອນເຖິງວິວັດທະນາການຂອງທັດສະນະຂອງຂ້ອຍໃນບົດຄວາມ, ແຕ່ເຊື່ອຂ້ອຍ: ໃນເບື້ອງຕົ້ນຂ້ອຍຢາກສ້າງບາງສິ່ງບາງຢ່າງທີ່ຊັບຊ້ອນ, ບໍ່ສາມາດທໍາລາຍໄດ້, ມີຄວາມສາມາດຢູ່ລອດເຖິງແມ່ນວ່າການລະເບີດຂອງນິວເຄລຍຢູ່ໃກ້ໆ. ຢ່າງໃດກໍຕາມ, ເຫດຜົນ (ຂ້າພະເຈົ້າຫວັງວ່າ) ຍັງຄົງໄດ້ຮັບໄຊຊະນະແລະຄ່ອຍໆປ່ຽນຄວາມສໍາຄັນໄປສູ່ຄວາມງ່າຍດາຍແລະຄວາມຫນາແຫນ້ນ.

ມັນອາດຈະເປັນຂ້ອຍຜິດບໍ? ເຈົ້າ​ແນ່​ນອນ. ຕົວຢ່າງ, ມັນອາດຈະເຮັດໃຫ້ພວກເຮົາຊື້ microcircuits ທີ່ມີຄຸນນະພາບຕ່ໍາຊຸດຫນຶ່ງ. ຫຼືສໍາລັບເຫດຜົນອື່ນໆ, ອຸປະກອນຈະບໍ່ຕອບສະຫນອງຄວາມຄາດຫວັງຂອງຄວາມຫນ້າເຊື່ອຖື.

ຂ້ອຍມີແຜນການສໍາລັບເລື່ອງນີ້ບໍ? ຂ້າພະເຈົ້າຄິດວ່າຫຼັງຈາກອ່ານບົດຄວາມທ່ານບໍ່ຕ້ອງສົງໃສວ່າມີແຜນການ. ແລະບໍ່ແມ່ນແຕ່ຄົນດຽວ.

ໃນບັນທຶກທີ່ຮຸນແຮງກວ່າເລັກນ້ອຍ, ຮູບແບບໄດ້ຖືກພັດທະນາທັງເປັນທາງເລືອກທີ່ເຮັດວຽກແລະເປັນ "ປູມເປົ້າທົດລອງ".

ໃນເວລານີ້, ທຸກສິ່ງທຸກຢ່າງຢູ່ໃນຕາຕະລາງເຮັດວຽກດີ, ໃນມື້ອື່ນການແກ້ໄຂຈະຖືກນໍາໄປໃຊ້ (ປະມານ) ໃນຫຼາຍຮ້ອຍອຸປະກອນ, ໃຫ້ພວກເຮົາເບິ່ງສິ່ງທີ່ເກີດຂື້ນໃນການດໍາເນີນງານ "ສູ້ຮົບ" (ໂຊກດີ, ຂ້ອຍຫວັງວ່າຮູບແບບຊ່ວຍໃຫ້ທ່ານສາມາດກວດພົບຄວາມລົ້ມເຫລວໄດ້ຢ່າງຫນ້າເຊື່ອຖື; ດັ່ງນັ້ນທ່ານສາມາດເກັບກໍາສະຖິຕິຢ່າງເຕັມທີ່). ໃນສອງສາມເດືອນມັນກໍ່ເປັນໄປໄດ້ທີ່ຈະສະຫຼຸບ (ແລະຖ້າທ່ານໂຊກບໍ່ດີ, ເຖິງແມ່ນວ່າກ່ອນຫນ້ານັ້ນ).

ຖ້າຫາກວ່າ, ອີງຕາມຜົນໄດ້ຮັບຂອງການນໍາໃຊ້, ບັນຫາທີ່ຮ້າຍແຮງໄດ້ຖືກຄົ້ນພົບແລະການປັບປຸງແມ່ນຕ້ອງການ, ຫຼັງຈາກນັ້ນຂ້າພະເຈົ້າຈະຂຽນກ່ຽວກັບມັນຢ່າງແນ່ນອນ.

Literature

ຂ້າພະເຈົ້າບໍ່ຕ້ອງການສ້າງບັນຊີລາຍຊື່ທີ່ຫນ້າເບື່ອຍາວຂອງວຽກງານທີ່ໃຊ້ແລ້ວ; ຫຼັງຈາກທີ່ທັງຫມົດ, ທຸກຄົນມີ Google.

ທີ່ນີ້ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈອອກຈາກບັນຊີລາຍຊື່ຂອງການຄົ້ນພົບທີ່ເບິ່ງຄືວ່າຫນ້າສົນໃຈໂດຍສະເພາະກັບຂ້າພະເຈົ້າ, ແຕ່ຄ່ອຍໆພວກເຂົາເຄື່ອນຍ້າຍໂດຍກົງເຂົ້າໄປໃນຂໍ້ຄວາມຂອງບົດຄວາມ, ແລະລາຍການຫນຶ່ງຍັງຄົງຢູ່ໃນບັນຊີລາຍຊື່:

1. ປະໂຫຍດ infgen ຈາກຜູ້ຂຽນ zlib. ສາມາດສະແດງເນື້ອໃນຂອງ deflate/zlib/gzip ໄດ້ຢ່າງຊັດເຈນ. ຖ້າທ່ານຕ້ອງຈັດການກັບໂຄງສ້າງພາຍໃນຂອງຮູບແບບ deflate (ຫຼື gzip), ຂ້າພະເຈົ້າຂໍແນະນໍາໃຫ້ມັນສູງ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com