ಪೂರ್ವೇತಿಹಾಸದ

ನಮ್ಮದೇ ವಿನ್ಯಾಸದ ವಿತರಣಾ ಯಂತ್ರಗಳಿವೆ. ರಾಸ್ಪ್ಬೆರಿ ಪೈ ಒಳಗೆ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಬೋರ್ಡ್ನಲ್ಲಿ ಕೆಲವು ವೈರಿಂಗ್. ನಾಣ್ಯ ಸ್ವೀಕಾರ, ಬಿಲ್ ಸ್ವೀಕಾರ, ಬ್ಯಾಂಕ್ ಟರ್ಮಿನಲ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಲಾಗಿದೆ ... ಎಲ್ಲವನ್ನೂ ಸ್ವಯಂ-ಬರಹದ ಪ್ರೋಗ್ರಾಂ ಮೂಲಕ ನಿಯಂತ್ರಿಸಲಾಗುತ್ತದೆ. ಸಂಪೂರ್ಣ ಕೆಲಸದ ಇತಿಹಾಸವನ್ನು ಫ್ಲ್ಯಾಶ್ ಡ್ರೈವಿನಲ್ಲಿ (ಮೈಕ್ರೋಎಸ್ಡಿ) ಲಾಗ್ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ, ನಂತರ ಅದನ್ನು ಇಂಟರ್ನೆಟ್ ಮೂಲಕ (ಯುಎಸ್ಬಿ ಮೋಡೆಮ್ ಬಳಸಿ) ಸರ್ವರ್ಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಅದನ್ನು ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಮಾರಾಟದ ಮಾಹಿತಿಯನ್ನು 1c ಗೆ ಲೋಡ್ ಮಾಡಲಾಗಿದೆ, ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ ಸರಳ ವೆಬ್ ಇಂಟರ್ಫೇಸ್ ಸಹ ಇದೆ, ಇತ್ಯಾದಿ.

ಅಂದರೆ, ಜರ್ನಲ್ ಅತ್ಯಗತ್ಯ - ಲೆಕ್ಕಪತ್ರ ನಿರ್ವಹಣೆ (ಆದಾಯ, ಮಾರಾಟ, ಇತ್ಯಾದಿ), ಮೇಲ್ವಿಚಾರಣೆ (ಎಲ್ಲಾ ರೀತಿಯ ವೈಫಲ್ಯಗಳು ಮತ್ತು ಇತರ ಬಲ ಮೇಜರ್ ಸಂದರ್ಭಗಳು); ಇದು, ಈ ಯಂತ್ರದ ಬಗ್ಗೆ ನಾವು ಹೊಂದಿರುವ ಎಲ್ಲಾ ಮಾಹಿತಿ ಎಂದು ಒಬ್ಬರು ಹೇಳಬಹುದು.

ಸಮಸ್ಯೆಯನ್ನು

ಫ್ಲ್ಯಾಶ್ ಡ್ರೈವ್‌ಗಳು ತಮ್ಮನ್ನು ಅತ್ಯಂತ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಸಾಧನಗಳಾಗಿ ತೋರಿಸುತ್ತವೆ. ಅವರು ಅಪೇಕ್ಷಣೀಯ ಕ್ರಮಬದ್ಧತೆಯೊಂದಿಗೆ ವಿಫಲರಾಗುತ್ತಾರೆ. ಇದು ಯಂತ್ರದ ಅಲಭ್ಯತೆ ಮತ್ತು (ಕೆಲವು ಕಾರಣಕ್ಕಾಗಿ ಲಾಗ್ ಅನ್ನು ಆನ್‌ಲೈನ್‌ನಲ್ಲಿ ವರ್ಗಾಯಿಸಲಾಗದಿದ್ದರೆ) ಡೇಟಾ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಇದು ಫ್ಲ್ಯಾಶ್ ಡ್ರೈವ್‌ಗಳನ್ನು ಬಳಸುವ ಮೊದಲ ಅನುಭವವಲ್ಲ, ಇದಕ್ಕೂ ಮೊದಲು ನೂರಕ್ಕೂ ಹೆಚ್ಚು ಸಾಧನಗಳೊಂದಿಗೆ ಮತ್ತೊಂದು ಯೋಜನೆ ಇತ್ತು, ಅಲ್ಲಿ ಮ್ಯಾಗಜೀನ್ ಅನ್ನು ಯುಎಸ್‌ಬಿ ಫ್ಲ್ಯಾಷ್ ಡ್ರೈವ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಸಮಸ್ಯೆಗಳೂ ಇದ್ದವು, ಕೆಲವೊಮ್ಮೆ ವಿಫಲವಾದವರ ಸಂಖ್ಯೆ ಒಂದು ತಿಂಗಳು ಡಜನ್‌ಗಳಲ್ಲಿತ್ತು. SLC ಮೆಮೊರಿಯೊಂದಿಗೆ ಬ್ರಾಂಡ್ ಮಾಡಿದವುಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ನಾವು ವಿಭಿನ್ನ ಫ್ಲಾಶ್ ಡ್ರೈವ್ಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ ಮತ್ತು ಕೆಲವು ಮಾದರಿಗಳು ಇತರರಿಗಿಂತ ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿವೆ, ಆದರೆ ಫ್ಲಾಶ್ ಡ್ರೈವ್ಗಳನ್ನು ಬದಲಿಸುವುದರಿಂದ ಸಮಸ್ಯೆಯನ್ನು ಆಮೂಲಾಗ್ರವಾಗಿ ಪರಿಹರಿಸಲಿಲ್ಲ.

ಎಚ್ಚರಿಕೆ ಲಾಂಗ್ರೆಡ್! ನೀವು "ಏಕೆ" ನಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ಆದರೆ "ಹೇಗೆ" ಮಾತ್ರ, ನೀವು ನೇರವಾಗಿ ಹೋಗಬಹುದು ಕೊನೆಯಲ್ಲಿ ಲೇಖನಗಳು.

ನಿರ್ಧಾರವನ್ನು

ಮನಸ್ಸಿಗೆ ಬರುವ ಮೊದಲ ವಿಷಯವೆಂದರೆ: ಮೈಕ್ರೊ ಎಸ್‌ಡಿ ತ್ಯಜಿಸಿ, ಸ್ಥಾಪಿಸಿ, ಉದಾಹರಣೆಗೆ, ಎಸ್‌ಎಸ್‌ಡಿ ಮತ್ತು ಅದರಿಂದ ಬೂಟ್ ಮಾಡಿ. ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಸಾಧ್ಯ, ಬಹುಶಃ, ಆದರೆ ತುಲನಾತ್ಮಕವಾಗಿ ದುಬಾರಿ, ಮತ್ತು ಅಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ (USB-SATA ಅಡಾಪ್ಟರ್ ಅನ್ನು ಸೇರಿಸಲಾಗಿದೆ; ಬಜೆಟ್ SSD ಗಳ ವೈಫಲ್ಯದ ಅಂಕಿಅಂಶಗಳು ಸಹ ಪ್ರೋತ್ಸಾಹಿಸುವುದಿಲ್ಲ).

USB HDD ಸಹ ನಿರ್ದಿಷ್ಟವಾಗಿ ಆಕರ್ಷಕ ಪರಿಹಾರದಂತೆ ಕಾಣುತ್ತಿಲ್ಲ.

ಆದ್ದರಿಂದ, ನಾವು ಈ ಆಯ್ಕೆಗೆ ಬಂದಿದ್ದೇವೆ: MicroSD ಯಿಂದ ಬೂಟ್ ಮಾಡುವುದನ್ನು ಬಿಡಿ, ಆದರೆ ಅವುಗಳನ್ನು ಓದಲು-ಮಾತ್ರ ಮೋಡ್‌ನಲ್ಲಿ ಬಳಸಿ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಲಾಗ್ ಅನ್ನು (ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಹಾರ್ಡ್‌ವೇರ್‌ಗೆ ವಿಶಿಷ್ಟವಾದ ಇತರ ಮಾಹಿತಿ - ಸರಣಿ ಸಂಖ್ಯೆ, ಸಂವೇದಕ ಮಾಪನಾಂಕ ನಿರ್ಣಯಗಳು, ಇತ್ಯಾದಿ) ಬೇರೆಡೆಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ. .

ರಾಸ್್ಬೆರ್ರಿಸ್ಗಾಗಿ ಓದಲು-ಮಾತ್ರ ಎಫ್ಎಸ್ ವಿಷಯವನ್ನು ಈಗಾಗಲೇ ಒಳಗೆ ಮತ್ತು ಹೊರಗೆ ಅಧ್ಯಯನ ಮಾಡಲಾಗಿದೆ, ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ಅನುಷ್ಠಾನದ ವಿವರಗಳ ಮೇಲೆ ವಾಸಿಸುವುದಿಲ್ಲ (ಆದರೆ ಆಸಕ್ತಿ ಇದ್ದರೆ, ಬಹುಶಃ ನಾನು ಈ ವಿಷಯದ ಬಗ್ಗೆ ಮಿನಿ-ಲೇಖನವನ್ನು ಬರೆಯುತ್ತೇನೆ). ವೈಯಕ್ತಿಕ ಅನುಭವದಿಂದ ಮತ್ತು ಈಗಾಗಲೇ ಕಾರ್ಯಗತಗೊಳಿಸಿದವರ ವಿಮರ್ಶೆಗಳಿಂದ ವಿಶ್ವಾಸಾರ್ಹತೆಯಲ್ಲಿ ಲಾಭವಿದೆ ಎಂದು ನಾನು ಗಮನಿಸಲು ಬಯಸುವ ಏಕೈಕ ಅಂಶವಾಗಿದೆ. ಹೌದು, ಸ್ಥಗಿತಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೊಡೆದುಹಾಕಲು ಅಸಾಧ್ಯ, ಆದರೆ ಅವುಗಳ ಆವರ್ತನವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುವುದು ಸಾಕಷ್ಟು ಸಾಧ್ಯ. ಮತ್ತು ಕಾರ್ಡ್‌ಗಳು ಏಕೀಕೃತವಾಗುತ್ತಿವೆ, ಇದು ಸೇವಾ ಸಿಬ್ಬಂದಿಗೆ ಬದಲಿಯನ್ನು ಹೆಚ್ಚು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.

ಯಂತ್ರಾಂಶ

ಮೆಮೊರಿ ಪ್ರಕಾರದ ಆಯ್ಕೆಯ ಬಗ್ಗೆ ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಸಂದೇಹವಿಲ್ಲ - NOR ಫ್ಲ್ಯಾಶ್.
ವಾದಗಳು:

• ಸರಳ ಸಂಪರ್ಕ (ಹೆಚ್ಚಾಗಿ SPI ಬಸ್, ನೀವು ಈಗಾಗಲೇ ಬಳಸಿದ ಅನುಭವವನ್ನು ಹೊಂದಿರುವಿರಿ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಹಾರ್ಡ್‌ವೇರ್ ಸಮಸ್ಯೆಗಳನ್ನು ನಿರೀಕ್ಷಿಸಲಾಗುವುದಿಲ್ಲ);
• ಹಾಸ್ಯಾಸ್ಪದ ಬೆಲೆ;
• ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಆಪರೇಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ (ಅನುಷ್ಠಾನವು ಈಗಾಗಲೇ ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ನಲ್ಲಿದೆ, ನೀವು ಬಯಸಿದರೆ, ನೀವು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಒಂದನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಅದು ಸಹ ಇರುತ್ತದೆ ಅಥವಾ ನಿಮ್ಮದೇ ಆದದನ್ನು ಬರೆಯಬಹುದು, ಅದೃಷ್ಟವಶಾತ್ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ);
• ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಸಂಪನ್ಮೂಲ:
  ವಿಶಿಷ್ಟ ಡೇಟಾಶೀಟ್‌ನಿಂದ: ಡೇಟಾವನ್ನು 20 ವರ್ಷಗಳವರೆಗೆ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಪ್ರತಿ ಬ್ಲಾಕ್‌ಗೆ 100000 ಅಳಿಸುವ ಚಕ್ರಗಳು;
  ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಮೂಲಗಳಿಂದ: ಅತ್ಯಂತ ಕಡಿಮೆ BER, ದೋಷ ತಿದ್ದುಪಡಿ ಕೋಡ್‌ಗಳ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಪ್ರತಿಪಾದಿಸುತ್ತದೆ (ಕೆಲವು ಕೃತಿಗಳು NOR ಗಾಗಿ ECC ಅನ್ನು ಪರಿಗಣಿಸುತ್ತವೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಅವುಗಳು MLC NOR ಅನ್ನು ಅರ್ಥೈಸುತ್ತವೆ; ಇದು ಸಹ ಸಂಭವಿಸುತ್ತದೆ).

ಪರಿಮಾಣ ಮತ್ತು ಸಂಪನ್ಮೂಲದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಅಂದಾಜು ಮಾಡೋಣ.

ಡೇಟಾವನ್ನು ಹಲವಾರು ದಿನಗಳವರೆಗೆ ಉಳಿಸಲು ಖಾತರಿಪಡಿಸಬೇಕೆಂದು ನಾನು ಬಯಸುತ್ತೇನೆ. ಯಾವುದೇ ಸಂವಹನ ಸಮಸ್ಯೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಮಾರಾಟದ ಇತಿಹಾಸವು ಕಳೆದುಹೋಗದಂತೆ ಇದು ಅವಶ್ಯಕವಾಗಿದೆ. ಈ ಅವಧಿಯಲ್ಲಿ ನಾವು 5 ದಿನಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇವೆ (ವಾರಾಂತ್ಯ ಮತ್ತು ರಜಾದಿನಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು) ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬಹುದು.

ನಾವು ಪ್ರಸ್ತುತ ದಿನಕ್ಕೆ ಸುಮಾರು 100kb ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ (3-4 ಸಾವಿರ ನಮೂದುಗಳು), ಆದರೆ ಕ್ರಮೇಣ ಈ ಅಂಕಿ ಅಂಶವು ಬೆಳೆಯುತ್ತಿದೆ - ವಿವರ ಹೆಚ್ಚುತ್ತಿದೆ, ಹೊಸ ಈವೆಂಟ್‌ಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ. ಜೊತೆಗೆ, ಕೆಲವೊಮ್ಮೆ ಸ್ಫೋಟಗಳು ಇವೆ (ಕೆಲವು ಸಂವೇದಕವು ತಪ್ಪು ಧನಾತ್ಮಕಗಳೊಂದಿಗೆ ಸ್ಪ್ಯಾಮಿಂಗ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ). ನಾವು 10 ಸಾವಿರ ದಾಖಲೆಗಳಿಗೆ ಪ್ರತಿ 100 ಬೈಟ್‌ಗಳಿಗೆ ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ - ದಿನಕ್ಕೆ ಮೆಗಾಬೈಟ್‌ಗಳು.

ಒಟ್ಟಾರೆಯಾಗಿ, 5MB ಕ್ಲೀನ್ (ಚೆನ್ನಾಗಿ ಸಂಕುಚಿತ) ಡೇಟಾ ಹೊರಬರುತ್ತದೆ. ಅವರಿಗೆ ಹೆಚ್ಚು (ಸ್ಥೂಲ ಅಂದಾಜು) 1MB ಸೇವಾ ಡೇಟಾ.

ಅಂದರೆ, ನಾವು ಸಂಕೋಚನವನ್ನು ಬಳಸದಿದ್ದರೆ ನಮಗೆ 8MB ಚಿಪ್ ಅಗತ್ಯವಿದೆ, ಅಥವಾ ನಾವು ಅದನ್ನು ಬಳಸಿದರೆ 4MB. ಈ ರೀತಿಯ ಮೆಮೊರಿಗೆ ಸಾಕಷ್ಟು ವಾಸ್ತವಿಕ ಸಂಖ್ಯೆಗಳು.

ಸಂಪನ್ಮೂಲಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ: ಇಡೀ ಮೆಮೊರಿಯನ್ನು ಪ್ರತಿ 5 ದಿನಗಳಿಗೊಮ್ಮೆ ಪುನಃ ಬರೆಯಲಾಗುವುದಿಲ್ಲ ಎಂದು ನಾವು ಯೋಜಿಸಿದರೆ, ನಂತರ 10 ವರ್ಷಗಳ ಸೇವೆಯಲ್ಲಿ ನಾವು ಸಾವಿರಕ್ಕಿಂತ ಕಡಿಮೆ ಮರುಬರೆಯುವ ಚಕ್ರಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ.
ತಯಾರಕರು ನೂರು ಸಾವಿರ ಭರವಸೆ ನೀಡುತ್ತಾರೆ ಎಂದು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ.

NOR vs NAND ಬಗ್ಗೆ ಸ್ವಲ್ಪ

ಇಂದು, ಸಹಜವಾಗಿ, NAND ಮೆಮೊರಿ ಹೆಚ್ಚು ಜನಪ್ರಿಯವಾಗಿದೆ, ಆದರೆ ನಾನು ಅದನ್ನು ಈ ಯೋಜನೆಗೆ ಬಳಸುವುದಿಲ್ಲ: NAND, NOR ಗಿಂತ ಭಿನ್ನವಾಗಿ, ದೋಷ ತಿದ್ದುಪಡಿ ಕೋಡ್‌ಗಳು, ಕೆಟ್ಟ ಬ್ಲಾಕ್‌ಗಳ ಟೇಬಲ್, ಇತ್ಯಾದಿಗಳ ಬಳಕೆಯನ್ನು ಅಗತ್ಯವಾಗಿ ಅಗತ್ಯವಿದೆ, ಜೊತೆಗೆ ಕಾಲುಗಳು NAND ಚಿಪ್ಸ್ ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚು.

NOR ನ ಅನಾನುಕೂಲಗಳು ಸೇರಿವೆ:

• ಸಣ್ಣ ಪರಿಮಾಣ (ಮತ್ತು, ಅದರ ಪ್ರಕಾರ, ಪ್ರತಿ ಮೆಗಾಬೈಟ್ಗೆ ಹೆಚ್ಚಿನ ಬೆಲೆ);
• ಕಡಿಮೆ ಸಂವಹನ ವೇಗ (ಹೆಚ್ಚಾಗಿ ಸರಣಿ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ SPI ಅಥವಾ I2C);
• ನಿಧಾನವಾದ ಅಳಿಸುವಿಕೆ (ಬ್ಲಾಕ್ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿ, ಇದು ಸೆಕೆಂಡಿನ ಭಾಗದಿಂದ ಹಲವಾರು ಸೆಕೆಂಡುಗಳವರೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ).

ನಮಗೆ ನಿರ್ಣಾಯಕ ಏನೂ ಇಲ್ಲ ಎಂದು ತೋರುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾವು ಮುಂದುವರಿಯುತ್ತೇವೆ.

ವಿವರಗಳು ಆಸಕ್ತಿದಾಯಕವಾಗಿದ್ದರೆ, ಮೈಕ್ರೋ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗಿದೆ ನಲ್ಲಿ 25df321a (ಆದಾಗ್ಯೂ, ಇದು ಮುಖ್ಯವಲ್ಲ, ಪಿನ್‌ಔಟ್ ಮತ್ತು ಕಮಾಂಡ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಹೊಂದಿಕೆಯಾಗುವ ಸಾಕಷ್ಟು ಸಾದೃಶ್ಯಗಳು ಮಾರುಕಟ್ಟೆಯಲ್ಲಿವೆ; ನಾವು ಬೇರೆ ತಯಾರಕರು ಮತ್ತು/ಅಥವಾ ಬೇರೆ ಗಾತ್ರದಿಂದ ಮೈಕ್ರೊ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಬಯಸಿದ್ದರೂ ಸಹ, ಎಲ್ಲವೂ ಬದಲಾಗದೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಕೋಡ್).

ನಾನು ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಡ್ರೈವರ್ ಅನ್ನು ಬಳಸುತ್ತೇನೆ; ರಾಸ್ಪ್ಬೆರಿಯಲ್ಲಿ, ಸಾಧನ ಟ್ರೀ ಓವರ್‌ಲೇ ಬೆಂಬಲಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ - ನೀವು /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

ರಾಸ್ಪ್ಬೆರಿ ಪೈಗೆ ಚಿಪ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುವ ವಿವರಣೆಯನ್ನು ನಾನು ಬಿಟ್ಟುಬಿಡುತ್ತೇನೆ. ಒಂದೆಡೆ, ನಾನು ಎಲೆಕ್ಟ್ರಾನಿಕ್ಸ್‌ನಲ್ಲಿ ಪರಿಣಿತನಲ್ಲ, ಮತ್ತೊಂದೆಡೆ, ಇಲ್ಲಿ ಎಲ್ಲವೂ ನನಗೆ ನೀರಸವಾಗಿದೆ: ಮೈಕ್ರೊ ಸರ್ಕ್ಯೂಟ್ ಕೇವಲ 8 ಕಾಲುಗಳನ್ನು ಹೊಂದಿದೆ, ಅದರಲ್ಲಿ ನಮಗೆ ನೆಲ, ಶಕ್ತಿ, SPI (CS, SI, SO, SCK) ಅಗತ್ಯವಿದೆ. ); ಮಟ್ಟಗಳು ರಾಸ್ಪ್ಬೆರಿ ಪೈನಂತೆಯೇ ಇರುತ್ತವೆ, ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ವೈರಿಂಗ್ ಅಗತ್ಯವಿಲ್ಲ - ಸೂಚಿಸಿದ 6 ಪಿನ್ಗಳನ್ನು ಸಂಪರ್ಕಿಸಿ.

ಸಮಸ್ಯೆ ಹೇಳಿಕೆ

ಎಂದಿನಂತೆ, ಸಮಸ್ಯೆಯ ಹೇಳಿಕೆಯು ಹಲವಾರು ಪುನರಾವರ್ತನೆಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ ಮತ್ತು ಇದು ಮುಂದಿನದಕ್ಕೆ ಸಮಯವಾಗಿದೆ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ಆದ್ದರಿಂದ ನಿಲ್ಲಿಸೋಣ, ಈಗಾಗಲೇ ಬರೆದದ್ದನ್ನು ಒಟ್ಟುಗೂಡಿಸಿ ಮತ್ತು ನೆರಳಿನಲ್ಲಿ ಉಳಿದಿರುವ ವಿವರಗಳನ್ನು ಸ್ಪಷ್ಟಪಡಿಸೋಣ.

ಆದ್ದರಿಂದ, ಲಾಗ್ ಅನ್ನು SPI NOR ಫ್ಲ್ಯಾಶ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುವುದು ಎಂದು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ಗೊತ್ತಿಲ್ಲದವರಿಗೆ NOR ಫ್ಲ್ಯಾಶ್ ಎಂದರೇನು?

ಇದು ಬಾಷ್ಪಶೀಲವಲ್ಲದ ಮೆಮೊರಿಯಾಗಿದ್ದು, ಇದರೊಂದಿಗೆ ನೀವು ಮೂರು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾಡಬಹುದು:

1. ಓದುವುದು:
   ಅತ್ಯಂತ ಸಾಮಾನ್ಯವಾದ ಓದುವಿಕೆ: ನಾವು ವಿಳಾಸವನ್ನು ರವಾನಿಸುತ್ತೇವೆ ಮತ್ತು ನಮಗೆ ಅಗತ್ಯವಿರುವಷ್ಟು ಬೈಟ್‌ಗಳನ್ನು ಓದುತ್ತೇವೆ;
2. ದಾಖಲೆ:
   NOR ಫ್ಲ್ಯಾಷ್‌ಗೆ ಬರೆಯುವುದು ನಿಯಮಿತವಾದಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಇದು ಒಂದು ವಿಶಿಷ್ಟತೆಯನ್ನು ಹೊಂದಿದೆ: ನೀವು 1 ರಿಂದ 0 ಅನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸಬಹುದು, ಆದರೆ ಪ್ರತಿಯಾಗಿ ಅಲ್ಲ. ಉದಾಹರಣೆಗೆ, ನಾವು ಮೆಮೊರಿ ಸೆಲ್‌ನಲ್ಲಿ 0x55 ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದಕ್ಕೆ 0x0f ಬರೆದ ನಂತರ, 0x05 ಅನ್ನು ಈಗಾಗಲೇ ಅಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. (ಕೆಳಗಿನ ಕೋಷ್ಟಕವನ್ನು ನೋಡಿ);
3. ಅಳಿಸು:
   ಸಹಜವಾಗಿ, ನಾವು ವಿರುದ್ಧವಾದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ - 0 ರಿಂದ 1 ಕ್ಕೆ ಬದಲಿಸಿ, ಇದು ನಿಖರವಾಗಿ ಅಳಿಸುವ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದೆ. ಮೊದಲ ಎರಡಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿ, ಇದು ಬೈಟ್‌ಗಳೊಂದಿಗೆ ಅಲ್ಲ, ಆದರೆ ಬ್ಲಾಕ್‌ಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (ಆಯ್ದ ಚಿಪ್‌ನಲ್ಲಿ ಕನಿಷ್ಠ ಅಳಿಸುವಿಕೆ ಬ್ಲಾಕ್ 4kb ಆಗಿದೆ). ಅಳಿಸುವಿಕೆಯು ಸಂಪೂರ್ಣ ಬ್ಲಾಕ್ ಅನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ ಮತ್ತು 0 ರಿಂದ 1 ಗೆ ಬದಲಾಯಿಸುವ ಏಕೈಕ ಮಾರ್ಗವಾಗಿದೆ. ಆದ್ದರಿಂದ, ಫ್ಲ್ಯಾಶ್ ಮೆಮೊರಿಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ನೀವು ಆಗಾಗ್ಗೆ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಅಳಿಸಿ ಬ್ಲಾಕ್ ಗಡಿಗೆ ಜೋಡಿಸಬೇಕಾಗುತ್ತದೆ.
   NOR ಫ್ಲ್ಯಾಶ್‌ನಲ್ಲಿ ರೆಕಾರ್ಡಿಂಗ್:

ಬೈನರಿ ಡೇಟಾ

ಆಗಿತ್ತು
01010101

ದಾಖಲಿಸಲಾಗಿದೆ
00001111

ಆಗಿ ಮಾರ್ಪಟ್ಟಿದೆ
00000101

ಲಾಗ್ ಸ್ವತಃ ವೇರಿಯಬಲ್ ಉದ್ದದ ದಾಖಲೆಗಳ ಅನುಕ್ರಮವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ದಾಖಲೆಯ ವಿಶಿಷ್ಟ ಉದ್ದವು ಸುಮಾರು 30 ಬೈಟ್‌ಗಳಾಗಿರುತ್ತದೆ (ಆದರೂ ಹಲವಾರು ಕಿಲೋಬೈಟ್‌ಗಳಷ್ಟು ಉದ್ದವಿರುವ ದಾಖಲೆಗಳು ಕೆಲವೊಮ್ಮೆ ಸಂಭವಿಸುತ್ತವೆ). ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಅವರೊಂದಿಗೆ ಸರಳವಾಗಿ ಬೈಟ್‌ಗಳ ಗುಂಪಿನಂತೆ ಕೆಲಸ ಮಾಡುತ್ತೇವೆ, ಆದರೆ, ನಿಮಗೆ ಆಸಕ್ತಿ ಇದ್ದರೆ, CBOR ಅನ್ನು ದಾಖಲೆಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ

ಲಾಗ್ ಜೊತೆಗೆ, ನಾವು ಕೆಲವು "ಸೆಟಪ್" ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಬೇಕಾಗಿದೆ, ನವೀಕರಿಸಲಾಗಿದೆ ಮತ್ತು ಇಲ್ಲ: ನಿರ್ದಿಷ್ಟ ಸಾಧನ ID, ಸಂವೇದಕ ಮಾಪನಾಂಕ ನಿರ್ಣಯಗಳು, "ಸಾಧನವನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ" ಫ್ಲ್ಯಾಗ್, ಇತ್ಯಾದಿ.
ಈ ಮಾಹಿತಿಯು ಪ್ರಮುಖ ಮೌಲ್ಯದ ದಾಖಲೆಗಳ ಒಂದು ಸೆಟ್ ಆಗಿದೆ, ಇದನ್ನು CBOR ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ನಮ್ಮಲ್ಲಿ ಈ ಹೆಚ್ಚಿನ ಮಾಹಿತಿ ಇಲ್ಲ (ಹೆಚ್ಚಿನ ಕೆಲವು ಕಿಲೋಬೈಟ್‌ಗಳು), ಮತ್ತು ಇದನ್ನು ವಿರಳವಾಗಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ.
ಕೆಳಗಿನವುಗಳಲ್ಲಿ ನಾವು ಅದನ್ನು ಸಂದರ್ಭ ಎಂದು ಕರೆಯುತ್ತೇವೆ.

ಈ ಲೇಖನವು ಎಲ್ಲಿ ಪ್ರಾರಂಭವಾಯಿತು ಎಂಬುದನ್ನು ನಾವು ನೆನಪಿಸಿಕೊಂಡರೆ, ವಿಶ್ವಾಸಾರ್ಹ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ ಮತ್ತು ಸಾಧ್ಯವಾದರೆ, ಹಾರ್ಡ್‌ವೇರ್ ವೈಫಲ್ಯಗಳು/ಡೇಟಾ ಭ್ರಷ್ಟಾಚಾರದ ಸಂದರ್ಭದಲ್ಲಿಯೂ ಸಹ ನಿರಂತರ ಕಾರ್ಯಾಚರಣೆ.

ಸಮಸ್ಯೆಗಳ ಯಾವ ಮೂಲಗಳನ್ನು ಪರಿಗಣಿಸಬಹುದು?

• ಬರೆಯುವ/ಅಳಿಸುವಿಕೆಯ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ಪವರ್ ಆಫ್. ಇದು "ಕ್ರೋಬಾರ್ ವಿರುದ್ಧ ಯಾವುದೇ ಟ್ರಿಕ್ ಇಲ್ಲ" ಎಂಬ ವರ್ಗದಿಂದ ಬಂದಿದೆ.
  ನಿಂದ ಮಾಹಿತಿ ಚರ್ಚೆಗಳು ಸ್ಟಾಕ್‌ಎಕ್ಸ್‌ಚೇಂಜ್‌ನಲ್ಲಿ: ಫ್ಲ್ಯಾಷ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ ವಿದ್ಯುತ್ ಅನ್ನು ಆಫ್ ಮಾಡಿದಾಗ, ಅಳಿಸಿ (1 ಕ್ಕೆ ಹೊಂದಿಸಲಾಗಿದೆ) ಮತ್ತು ಬರೆಯಿರಿ (0 ಕ್ಕೆ ಹೊಂದಿಸಲಾಗಿದೆ) ವ್ಯಾಖ್ಯಾನಿಸದ ನಡವಳಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ: ಡೇಟಾವನ್ನು ಬರೆಯಬಹುದು, ಭಾಗಶಃ ಬರೆಯಬಹುದು (ಹೇಳಲು, ನಾವು 10 ಬೈಟ್‌ಗಳು/80 ಬಿಟ್‌ಗಳನ್ನು ವರ್ಗಾಯಿಸಿದ್ದೇವೆ , ಆದರೆ ಇನ್ನೂ 45 ಬಿಟ್‌ಗಳನ್ನು ಮಾತ್ರ ಬರೆಯಲಾಗುವುದಿಲ್ಲ), ಕೆಲವು ಬಿಟ್‌ಗಳು "ಮಧ್ಯಂತರ" ಸ್ಥಿತಿಯಲ್ಲಿರುವ ಸಾಧ್ಯತೆಯಿದೆ (ಓದುವಿಕೆಯು 0 ಮತ್ತು 1 ಎರಡನ್ನೂ ಉತ್ಪಾದಿಸಬಹುದು);
• ಫ್ಲಾಶ್ ಮೆಮೊರಿಯಲ್ಲಿಯೇ ದೋಷಗಳು.
  BER, ತುಂಬಾ ಕಡಿಮೆಯಾದರೂ, ಶೂನ್ಯಕ್ಕೆ ಸಮನಾಗಿರುವುದಿಲ್ಲ;
• ಬಸ್ ದೋಷಗಳು
  SPI ಮೂಲಕ ರವಾನೆಯಾಗುವ ಡೇಟಾವನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ರಕ್ಷಿಸಲಾಗಿಲ್ಲ; ಸಿಂಗಲ್ ಬಿಟ್ ದೋಷಗಳು ಮತ್ತು ಸಿಂಕ್ರೊನೈಸೇಶನ್ ದೋಷಗಳು ಚೆನ್ನಾಗಿ ಸಂಭವಿಸಬಹುದು - ಬಿಟ್‌ಗಳ ನಷ್ಟ ಅಥವಾ ಅಳವಡಿಕೆ (ಇದು ಬೃಹತ್ ಡೇಟಾ ಭ್ರಷ್ಟಾಚಾರಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ);
• ಇತರ ದೋಷಗಳು/ತೊಂದರೆಗಳು
  ಕೋಡ್‌ನಲ್ಲಿ ದೋಷಗಳು, ರಾಸ್ಪ್‌ಬೆರಿ ಗ್ಲಿಚ್‌ಗಳು, ಅನ್ಯಗ್ರಹದ ಹಸ್ತಕ್ಷೇಪ...

ನಾನು ಅವಶ್ಯಕತೆಗಳನ್ನು ರೂಪಿಸಿದ್ದೇನೆ, ಅದರ ನೆರವೇರಿಕೆ, ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಅವಶ್ಯಕವಾಗಿದೆ:

• ದಾಖಲೆಗಳು ತಕ್ಷಣವೇ ಫ್ಲಾಶ್ ಮೆಮೊರಿಗೆ ಹೋಗಬೇಕು, ವಿಳಂಬವಾದ ಬರಹಗಳನ್ನು ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ; - ದೋಷ ಸಂಭವಿಸಿದಲ್ಲಿ, ಅದನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಪತ್ತೆಹಚ್ಚಬೇಕು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು; - ಸಾಧ್ಯವಾದರೆ, ಸಿಸ್ಟಮ್ ದೋಷಗಳಿಂದ ಚೇತರಿಸಿಕೊಳ್ಳಬೇಕು.
  ("ಅದು ಹೇಗೆ ಇರಬಾರದು" ಎಂಬ ಜೀವನದಿಂದ ಒಂದು ಉದಾಹರಣೆ, ಪ್ರತಿಯೊಬ್ಬರೂ ಎದುರಿಸಿದ್ದಾರೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ: ತುರ್ತು ರೀಬೂಟ್ ನಂತರ, ಫೈಲ್ ಸಿಸ್ಟಮ್ "ಮುರಿದಿದೆ" ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಬೂಟ್ ಆಗುವುದಿಲ್ಲ)

ಕಲ್ಪನೆಗಳು, ವಿಧಾನಗಳು, ಪ್ರತಿಬಿಂಬಗಳು

ನಾನು ಈ ಸಮಸ್ಯೆಯ ಬಗ್ಗೆ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನನ್ನ ತಲೆಯಲ್ಲಿ ಬಹಳಷ್ಟು ವಿಚಾರಗಳು ಮಿನುಗಿದವು, ಉದಾಹರಣೆಗೆ:

• ಡೇಟಾ ಕಂಪ್ರೆಷನ್ ಬಳಸಿ;
• ಬುದ್ಧಿವಂತ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಬಳಸಿ, ಉದಾಹರಣೆಗೆ, ರೆಕಾರ್ಡ್ ಹೆಡರ್ಗಳನ್ನು ದಾಖಲೆಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಗ್ರಹಿಸುವುದು, ಇದರಿಂದ ಯಾವುದೇ ದಾಖಲೆಯಲ್ಲಿ ದೋಷವಿದ್ದರೆ, ಉಳಿದವುಗಳನ್ನು ನೀವು ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲದೆ ಓದಬಹುದು;
• ವಿದ್ಯುತ್ ಆಫ್ ಮಾಡಿದಾಗ ರೆಕಾರ್ಡಿಂಗ್ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಯನ್ನು ನಿಯಂತ್ರಿಸಲು ಬಿಟ್ ಕ್ಷೇತ್ರಗಳನ್ನು ಬಳಸಿ;
• ಎಲ್ಲದಕ್ಕೂ ಚೆಕ್‌ಸಮ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ;
• ಕೆಲವು ರೀತಿಯ ಶಬ್ದ-ನಿರೋಧಕ ಕೋಡಿಂಗ್ ಅನ್ನು ಬಳಸಿ.

ಈ ಕೆಲವು ವಿಚಾರಗಳನ್ನು ಬಳಸಿದರೆ, ಇತರರನ್ನು ಕೈಬಿಡಲು ನಿರ್ಧರಿಸಲಾಯಿತು. ಕ್ರಮವಾಗಿ ಹೋಗೋಣ.

ಡೇಟಾ ಸಂಕೋಚನ

ಜರ್ನಲ್‌ನಲ್ಲಿ ನಾವು ದಾಖಲಿಸುವ ಈವೆಂಟ್‌ಗಳು ಸಾಕಷ್ಟು ಹೋಲುತ್ತವೆ ಮತ್ತು ಪುನರಾವರ್ತನೆಯಾಗುತ್ತವೆ ("5 ರೂಬಲ್ ನಾಣ್ಯವನ್ನು ಎಸೆದರು", "ಬದಲಾವಣೆ ನೀಡಲು ಗುಂಡಿಯನ್ನು ಒತ್ತಿ", ...). ಆದ್ದರಿಂದ, ಸಂಕೋಚನವು ಸಾಕಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿರಬೇಕು.

ಕಂಪ್ರೆಷನ್ ಓವರ್ಹೆಡ್ ಅತ್ಯಲ್ಪವಾಗಿದೆ (ನಮ್ಮ ಪ್ರೊಸೆಸರ್ ಸಾಕಷ್ಟು ಶಕ್ತಿಯುತವಾಗಿದೆ, ಮೊದಲ ಪೈ ಸಹ 700 MHz ಆವರ್ತನದೊಂದಿಗೆ ಒಂದು ಕೋರ್ ಅನ್ನು ಹೊಂದಿತ್ತು, ಪ್ರಸ್ತುತ ಮಾದರಿಗಳು ಗಿಗಾಹರ್ಟ್ಜ್ಗಿಂತ ಹೆಚ್ಚಿನ ಆವರ್ತನದೊಂದಿಗೆ ಹಲವಾರು ಕೋರ್ಗಳನ್ನು ಹೊಂದಿವೆ), ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ವಿನಿಮಯ ದರವು ಕಡಿಮೆಯಾಗಿದೆ (ಹಲವಾರು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಮೆಗಾಬೈಟ್‌ಗಳು), ದಾಖಲೆಗಳ ಗಾತ್ರ ಚಿಕ್ಕದಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಸಂಕೋಚನವು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಿದರೆ, ಅದು ಕೇವಲ ಧನಾತ್ಮಕವಾಗಿರುತ್ತದೆ. (ಸಂಪೂರ್ಣವಾಗಿ ವಿಮರ್ಶಾತ್ಮಕವಲ್ಲದ, ಕೇವಲ ಹೇಳಿಕೆ). ಜೊತೆಗೆ, ನಾವು ನಿಜವಾದ ಎಂಬೆಡೆಡ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ, ಆದರೆ ಸಾಮಾನ್ಯ ಲಿನಕ್ಸ್ - ಆದ್ದರಿಂದ ಅನುಷ್ಠಾನಕ್ಕೆ ಹೆಚ್ಚಿನ ಶ್ರಮ ಅಗತ್ಯವಿಲ್ಲ (ಲೈಬ್ರರಿಯನ್ನು ಲಿಂಕ್ ಮಾಡಲು ಮತ್ತು ಅದರಿಂದ ಹಲವಾರು ಕಾರ್ಯಗಳನ್ನು ಬಳಸಲು ಸಾಕು).

ಲಾಗ್‌ನ ತುಂಡನ್ನು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸಾಧನದಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ (1.7 MB, 70 ಸಾವಿರ ನಮೂದುಗಳು) ಮತ್ತು ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ ಲಭ್ಯವಿರುವ gzip, lz4, lzop, bzip2, xz, zstd ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಕುಚಿತತೆಯನ್ನು ಮೊದಲು ಪರಿಶೀಲಿಸಲಾಗಿದೆ.

• gzip, xz, zstd ಇದೇ ರೀತಿಯ ಫಲಿತಾಂಶಗಳನ್ನು ತೋರಿಸಿದೆ (40Kb).
  ಫ್ಯಾಶನ್ xz ಇಲ್ಲಿ gzip ಅಥವಾ zstd ಮಟ್ಟದಲ್ಲಿ ತೋರಿಸಿದೆ ಎಂದು ನನಗೆ ಆಶ್ಚರ್ಯವಾಯಿತು;
• ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ lzip ಸ್ವಲ್ಪ ಕೆಟ್ಟ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡಿತು;
• lz4 ಮತ್ತು lzop ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ತೋರಿಸಲಿಲ್ಲ (150Kb);
• bzip2 ಆಶ್ಚರ್ಯಕರವಾಗಿ ಉತ್ತಮ ಫಲಿತಾಂಶವನ್ನು ತೋರಿಸಿದೆ (18Kb).

ಆದ್ದರಿಂದ, ಡೇಟಾವನ್ನು ಚೆನ್ನಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗಿದೆ.
ಆದ್ದರಿಂದ (ನಾವು ಮಾರಣಾಂತಿಕ ನ್ಯೂನತೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯದಿದ್ದರೆ) ಸಂಕೋಚನ ಇರುತ್ತದೆ! ಒಂದೇ ಫ್ಲ್ಯಾಶ್ ಡ್ರೈವಿನಲ್ಲಿ ಹೆಚ್ಚಿನ ಡೇಟಾ ಹೊಂದಿಕೊಳ್ಳುವುದರಿಂದ ಸರಳವಾಗಿ.

ಅನಾನುಕೂಲಗಳ ಬಗ್ಗೆ ಯೋಚಿಸೋಣ.

ಮೊದಲ ಸಮಸ್ಯೆ: ಪ್ರತಿ ದಾಖಲೆಯು ತಕ್ಷಣವೇ ಫ್ಲ್ಯಾಷ್‌ಗೆ ಹೋಗಬೇಕು ಎಂದು ನಾವು ಈಗಾಗಲೇ ಒಪ್ಪಿಕೊಂಡಿದ್ದೇವೆ. ವಿಶಿಷ್ಟವಾಗಿ, ಆರ್ಕೈವರ್ ವಾರಾಂತ್ಯದಲ್ಲಿ ಬರೆಯುವ ಸಮಯ ಎಂದು ನಿರ್ಧರಿಸುವವರೆಗೆ ಇನ್‌ಪುಟ್ ಸ್ಟ್ರೀಮ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ನಾವು ತಕ್ಷಣವೇ ಡೇಟಾದ ಸಂಕುಚಿತ ಬ್ಲಾಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಬಾಷ್ಪಶೀಲವಲ್ಲದ ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಬೇಕು.

ನಾನು ಮೂರು ಮಾರ್ಗಗಳನ್ನು ನೋಡುತ್ತೇನೆ:

1. ಮೇಲೆ ಚರ್ಚಿಸಿದ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಬದಲಿಗೆ ನಿಘಂಟಿನ ಸಂಕೋಚನವನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರತಿ ದಾಖಲೆಯನ್ನು ಕುಗ್ಗಿಸಿ.
   ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಆಯ್ಕೆಯಾಗಿದೆ, ಆದರೆ ನನಗೆ ಇಷ್ಟವಿಲ್ಲ. ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಯೋಗ್ಯ ಮಟ್ಟದ ಸಂಕೋಚನವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಿಘಂಟನ್ನು ನಿರ್ದಿಷ್ಟ ಡೇಟಾಗೆ "ಅನುಗುಣವಾಗಿ" ಮಾಡಬೇಕು; ಯಾವುದೇ ಬದಲಾವಣೆಯು ಸಂಕೋಚನ ಮಟ್ಟವು ದುರಂತವಾಗಿ ಕುಸಿಯಲು ಕಾರಣವಾಗುತ್ತದೆ. ಹೌದು, ನಿಘಂಟಿನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ರಚಿಸುವ ಮೂಲಕ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬಹುದು, ಆದರೆ ಇದು ತಲೆನೋವು - ನಾವು ನಿಘಂಟಿನ ಎಲ್ಲಾ ಆವೃತ್ತಿಗಳನ್ನು ಸಂಗ್ರಹಿಸಬೇಕಾಗುತ್ತದೆ; ಪ್ರತಿ ನಮೂದುಗಳಲ್ಲಿ ನಿಘಂಟಿನ ಯಾವ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ಸೂಚಿಸಬೇಕಾಗಿದೆ...
2. "ಕ್ಲಾಸಿಕಲ್" ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರತಿ ರೆಕಾರ್ಡ್ ಅನ್ನು ಕುಗ್ಗಿಸಿ, ಆದರೆ ಇತರರಿಂದ ಸ್ವತಂತ್ರವಾಗಿ.
   ಪರಿಗಣನೆಯಲ್ಲಿರುವ ಕಂಪ್ರೆಷನ್ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಈ ಗಾತ್ರದ (ಹತ್ತಾರು ಬೈಟ್‌ಗಳು) ದಾಖಲೆಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿಲ್ಲ, ಸಂಕುಚಿತ ಅನುಪಾತವು ಸ್ಪಷ್ಟವಾಗಿ 1 ಕ್ಕಿಂತ ಕಡಿಮೆಯಿರುತ್ತದೆ (ಅಂದರೆ, ಕುಗ್ಗಿಸುವ ಬದಲು ಡೇಟಾ ಪರಿಮಾಣವನ್ನು ಹೆಚ್ಚಿಸುವುದು);
3. ಪ್ರತಿ ರೆಕಾರ್ಡಿಂಗ್ ನಂತರ ಫ್ಲಶ್ ಮಾಡಿ.
   ಅನೇಕ ಕಂಪ್ರೆಷನ್ ಲೈಬ್ರರಿಗಳು ಫ್ಲಶ್‌ಗೆ ಬೆಂಬಲವನ್ನು ಹೊಂದಿವೆ. ಇದು ಒಂದು ಆಜ್ಞೆಯಾಗಿದೆ (ಅಥವಾ ಸಂಕೋಚನ ಕಾರ್ಯವಿಧಾನದ ನಿಯತಾಂಕ), ಅದನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ ಆರ್ಕೈವರ್ ಸಂಕುಚಿತ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ರೂಪಿಸುತ್ತದೆ ಇದರಿಂದ ಅದನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ಬಳಸಬಹುದು ಎಲ್ಲಾ ಸಂಕ್ಷೇಪಿಸದ ಡೇಟಾ ಈಗಾಗಲೇ ಸ್ವೀಕರಿಸಲಾಗಿದೆ. ಅಂತಹ ಅನಲಾಗ್ sync ಕಡತ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಅಥವಾ commit sql ನಲ್ಲಿ
   ನಂತರದ ಸಂಕೋಚನ ಕಾರ್ಯಾಚರಣೆಗಳು ಸಂಗ್ರಹವಾದ ನಿಘಂಟನ್ನು ಬಳಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಹಿಂದಿನ ಆವೃತ್ತಿಯಂತೆ ಸಂಕೋಚನ ಅನುಪಾತವು ಹೆಚ್ಚು ಹಾನಿಯಾಗುವುದಿಲ್ಲ ಎಂಬುದು ಮುಖ್ಯವಾದುದು.

ನಾನು ಮೂರನೇ ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿದ್ದೇನೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಅದನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ನೋಡೋಣ.

ಕಂಡು ಉತ್ತಮ ಲೇಖನ zlib ನಲ್ಲಿ ಫ್ಲಶ್ ಬಗ್ಗೆ.

ನಾನು ಲೇಖನದ ಆಧಾರದ ಮೇಲೆ ಮೊಣಕಾಲು ಪರೀಕ್ಷೆಯನ್ನು ಮಾಡಿದ್ದೇನೆ, 70Kb ಪುಟದ ಗಾತ್ರದೊಂದಿಗೆ ನೈಜ ಸಾಧನದಿಂದ 60 ಸಾವಿರ ಲಾಗ್ ನಮೂದುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇನೆ (ನಾವು ನಂತರ ಪುಟದ ಗಾತ್ರಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತೇವೆ) ಸ್ವೀಕರಿಸಲಾಗಿದೆ:

ಕಚ್ಚಾ ಡೇಟಾ
ಕಂಪ್ರೆಷನ್ ಜಿಜಿಪ್ -9 (ಫ್ಲಶ್ ಇಲ್ಲ)
Z_PARTIAL_FLUSH ಜೊತೆಗೆ zlib
Z_SYNC_FLUSH ಜೊತೆಗೆ zlib

ಸಂಪುಟ, ಕೆಬಿ
1692
40
352
604

ಮೊದಲ ನೋಟದಲ್ಲಿ, ಫ್ಲಶ್ ಕೊಡುಗೆಯ ಬೆಲೆ ತುಂಬಾ ಹೆಚ್ಚಾಗಿದೆ, ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ನಮಗೆ ಕಡಿಮೆ ಆಯ್ಕೆ ಇದೆ - ಒಂದೋ ಸಂಕುಚಿತಗೊಳಿಸದಿರುವುದು ಅಥವಾ ಫ್ಲಶ್‌ನೊಂದಿಗೆ ಸಂಕುಚಿತಗೊಳಿಸುವುದು (ಮತ್ತು ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿಯಾಗಿ). ನಾವು 70 ಸಾವಿರ ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾವು ಮರೆಯಬಾರದು, Z_PARTIAL_FLUSH ಪರಿಚಯಿಸಿದ ಪುನರಾವರ್ತನೆಯು ಪ್ರತಿ ದಾಖಲೆಗೆ 4-5 ಬೈಟ್‌ಗಳು ಮಾತ್ರ. ಮತ್ತು ಸಂಕೋಚನ ಅನುಪಾತವು ಸುಮಾರು 5: 1 ಆಗಿ ಹೊರಹೊಮ್ಮಿತು, ಇದು ಅತ್ಯುತ್ತಮ ಫಲಿತಾಂಶಕ್ಕಿಂತ ಹೆಚ್ಚು.

ಇದು ಆಶ್ಚರ್ಯಕರವಾಗಬಹುದು, ಆದರೆ Z_SYNC_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 (ಡಿಫ್ಲೇಟ್) ಇನ್ನೂ ಪುರಾತನ, ಅರ್ಹವಾದ ಮತ್ತು ಸ್ವಲ್ಪ ಹಳೆಯ-ಶೈಲಿಯ ಸಂಕೋಚನ ಅಲ್ಗಾರಿದಮ್ ಆಗಿದೆ. ಸಂಕ್ಷೇಪಿಸದ ಡೇಟಾ ಸ್ಟ್ರೀಮ್‌ನ ಕೊನೆಯ 32Kb ಅನ್ನು ನಿಘಂಟಿನಂತೆ ಬಳಸಲಾಗಿದೆ ಎಂಬ ಅಂಶವು ಇಂದು ವಿಚಿತ್ರವಾಗಿ ಕಾಣುತ್ತದೆ (ಅಂದರೆ, ಕೆಲವು ಡೇಟಾ ಬ್ಲಾಕ್ 40Kb ಹಿಂದೆ ಇನ್‌ಪುಟ್ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿದ್ದಂತೆಯೇ ಇದ್ದರೆ, ಅದನ್ನು ಮತ್ತೆ ಆರ್ಕೈವ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಮತ್ತು ಹಿಂದಿನ ಘಟನೆಯನ್ನು ಉಲ್ಲೇಖಿಸುವುದಿಲ್ಲ). ಫ್ಯಾಶನ್ ಆಧುನಿಕ ಆರ್ಕೈವರ್‌ಗಳಲ್ಲಿ, ನಿಘಂಟಿನ ಗಾತ್ರವನ್ನು ಕಿಲೋಬೈಟ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚಾಗಿ ಮೆಗಾಬೈಟ್‌ಗಳಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ.

ಆದ್ದರಿಂದ ನಾವು ಆರ್ಕೈವರ್‌ಗಳ ನಮ್ಮ ಮಿನಿ-ಅಧ್ಯಯನವನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ.

ಮುಂದೆ ನಾವು bzip2 ಅನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ (ನೆನಪಿಡಿ, ಫ್ಲಶ್ ಇಲ್ಲದೆ ಅದು ಸುಮಾರು 100:1 ರ ಅದ್ಭುತ ಸಂಕೋಚನ ಅನುಪಾತವನ್ನು ತೋರಿಸಿದೆ). ದುರದೃಷ್ಟವಶಾತ್, ಇದು ಫ್ಲಶ್‌ನೊಂದಿಗೆ ತುಂಬಾ ಕಳಪೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು; ಸಂಕುಚಿತ ಡೇಟಾದ ಗಾತ್ರವು ಸಂಕ್ಷೇಪಿಸದ ಡೇಟಾಕ್ಕಿಂತ ದೊಡ್ಡದಾಗಿದೆ.

ವೈಫಲ್ಯದ ಕಾರಣಗಳ ಬಗ್ಗೆ ನನ್ನ ಊಹೆಗಳು

Libbz2 ಕೇವಲ ಒಂದು ಫ್ಲಶ್ ಆಯ್ಕೆಯನ್ನು ನೀಡುತ್ತದೆ, ಇದು ನಿಘಂಟನ್ನು ತೆರವುಗೊಳಿಸುವಂತೆ ತೋರುತ್ತದೆ (zlib ನಲ್ಲಿ Z_FULL_FLUSH ಗೆ ಸದೃಶವಾಗಿದೆ); ಇದರ ನಂತರ ಯಾವುದೇ ಪರಿಣಾಮಕಾರಿ ಸಂಕೋಚನದ ಬಗ್ಗೆ ಯಾವುದೇ ಚರ್ಚೆಯಿಲ್ಲ.

ಮತ್ತು ಕೊನೆಯದಾಗಿ ಪರೀಕ್ಷಿಸಬೇಕಾದದ್ದು zstd. ನಿಯತಾಂಕಗಳನ್ನು ಅವಲಂಬಿಸಿ, ಇದು gzip ಮಟ್ಟದಲ್ಲಿ ಸಂಕುಚಿತಗೊಳಿಸುತ್ತದೆ, ಆದರೆ ಹೆಚ್ಚು ವೇಗವಾಗಿ ಅಥವಾ gzip ಗಿಂತ ಉತ್ತಮವಾಗಿರುತ್ತದೆ.

ಅಯ್ಯೋ, ಫ್ಲಶ್‌ನೊಂದಿಗೆ ಅದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲಿಲ್ಲ: ಸಂಕುಚಿತ ಡೇಟಾದ ಗಾತ್ರವು ಸುಮಾರು 700Kb ಆಗಿತ್ತು.

Я ಒಂದು ಪ್ರಶ್ನೆ ಕೇಳಿದರು ಪ್ರಾಜೆಕ್ಟ್‌ನ ಗಿಥಬ್ ಪುಟದಲ್ಲಿ, ಸಂಕುಚಿತ ಡೇಟಾದ ಪ್ರತಿ ಬ್ಲಾಕ್‌ಗೆ ನೀವು 10 ಬೈಟ್‌ಗಳ ಸೇವಾ ಡೇಟಾವನ್ನು ಎಣಿಸಬೇಕು ಎಂಬ ಉತ್ತರವನ್ನು ನಾನು ಸ್ವೀಕರಿಸಿದ್ದೇನೆ, ಅದು ಪಡೆದ ಫಲಿತಾಂಶಗಳಿಗೆ ಹತ್ತಿರದಲ್ಲಿದೆ; ಡಿಫ್ಲೇಟ್ ಅನ್ನು ಹಿಡಿಯಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ.

ಆರ್ಕೈವರ್‌ಗಳೊಂದಿಗಿನ ನನ್ನ ಪ್ರಯೋಗಗಳಲ್ಲಿ ನಾನು ಈ ಹಂತದಲ್ಲಿ ನಿಲ್ಲಿಸಲು ನಿರ್ಧರಿಸಿದೆ (xz, lzip, lzo, lz4 ಪರೀಕ್ಷೆಯ ಹಂತದಲ್ಲಿಯೂ ಸಹ ಫ್ಲಶ್ ಇಲ್ಲದೆ ತಮ್ಮನ್ನು ತಾವು ತೋರಿಸಿಕೊಳ್ಳಲಿಲ್ಲ ಮತ್ತು ನಾನು ಹೆಚ್ಚು ವಿಲಕ್ಷಣ ಸಂಕೋಚನ ಕ್ರಮಾವಳಿಗಳನ್ನು ಪರಿಗಣಿಸಲಿಲ್ಲ ಎಂದು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ).

ಆರ್ಕೈವಿಂಗ್ ಸಮಸ್ಯೆಗಳಿಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ.

ಎರಡನೆಯದು (ಅವರು ಕ್ರಮದಲ್ಲಿ ಹೇಳುವಂತೆ, ಮೌಲ್ಯದಲ್ಲಿ ಅಲ್ಲ) ಸಮಸ್ಯೆಯೆಂದರೆ ಸಂಕುಚಿತ ಡೇಟಾ ಒಂದೇ ಸ್ಟ್ರೀಮ್ ಆಗಿದೆ, ಇದರಲ್ಲಿ ಹಿಂದಿನ ವಿಭಾಗಗಳಿಗೆ ನಿರಂತರವಾಗಿ ಉಲ್ಲೇಖಗಳಿವೆ. ಹೀಗಾಗಿ, ಸಂಕುಚಿತ ಡೇಟಾದ ಒಂದು ವಿಭಾಗವು ಹಾನಿಗೊಳಗಾದರೆ, ನಾವು ಸಂಕ್ಷೇಪಿಸದ ಡೇಟಾದ ಸಂಬಂಧಿತ ಬ್ಲಾಕ್ ಅನ್ನು ಮಾತ್ರ ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ, ಆದರೆ ನಂತರದ ಎಲ್ಲವುಗಳನ್ನು ಸಹ ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ.

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಒಂದು ವಿಧಾನವಿದೆ:

1. ಸಮಸ್ಯೆ ಸಂಭವಿಸುವುದನ್ನು ತಡೆಯಿರಿ - ಸಂಕುಚಿತ ಡೇಟಾಗೆ ಪುನರಾವರ್ತನೆಯನ್ನು ಸೇರಿಸಿ, ಇದು ದೋಷಗಳನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಸರಿಪಡಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ; ನಾವು ಇದರ ಬಗ್ಗೆ ನಂತರ ಮಾತನಾಡುತ್ತೇವೆ;
2. ಸಮಸ್ಯೆ ಸಂಭವಿಸಿದಲ್ಲಿ ಪರಿಣಾಮಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಿ
   ನೀವು ಪ್ರತಿ ಡೇಟಾ ಬ್ಲಾಕ್ ಅನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಸಂಕುಚಿತಗೊಳಿಸಬಹುದು ಎಂದು ನಾವು ಈಗಾಗಲೇ ಹೇಳಿದ್ದೇವೆ ಮತ್ತು ಸಮಸ್ಯೆ ಸ್ವತಃ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ (ಒಂದು ಬ್ಲಾಕ್ನ ಡೇಟಾಗೆ ಹಾನಿ ಈ ಬ್ಲಾಕ್ಗೆ ಮಾತ್ರ ಡೇಟಾ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ). ಆದಾಗ್ಯೂ, ಡೇಟಾ ಸಂಕುಚನವು ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗಿರುವ ಒಂದು ವಿಪರೀತ ಪ್ರಕರಣವಾಗಿದೆ. ಇದಕ್ಕೆ ವಿರುದ್ಧವಾದ ತೀವ್ರತೆ: ನಮ್ಮ ಚಿಪ್‌ನ ಎಲ್ಲಾ 4MB ಅನ್ನು ಒಂದೇ ಆರ್ಕೈವ್ ಆಗಿ ಬಳಸಿ, ಇದು ನಮಗೆ ಅತ್ಯುತ್ತಮವಾದ ಸಂಕೋಚನವನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಡೇಟಾ ಭ್ರಷ್ಟಾಚಾರದ ಸಂದರ್ಭದಲ್ಲಿ ದುರಂತ ಪರಿಣಾಮಗಳನ್ನು ನೀಡುತ್ತದೆ.
   ಹೌದು, ವಿಶ್ವಾಸಾರ್ಹತೆಯ ವಿಷಯದಲ್ಲಿ ರಾಜಿ ಅಗತ್ಯವಿದೆ. ಆದರೆ ನಾವು ಅತ್ಯಂತ ಕಡಿಮೆ BER ಮತ್ತು 20 ವರ್ಷಗಳ ಘೋಷಿತ ಡೇಟಾ ಶೇಖರಣಾ ಅವಧಿಯೊಂದಿಗೆ ಬಾಷ್ಪಶೀಲವಲ್ಲದ ಮೆಮೊರಿಗಾಗಿ ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಸ್ವರೂಪವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೇವೆ ಎಂಬುದನ್ನು ನಾವು ನೆನಪಿನಲ್ಲಿಡಬೇಕು.

ಪ್ರಯೋಗಗಳ ಸಮಯದಲ್ಲಿ, 10 KB ಗಿಂತ ಕಡಿಮೆ ಗಾತ್ರದ ಸಂಕುಚಿತ ಡೇಟಾದ ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಸಂಕೋಚನ ಮಟ್ಟದಲ್ಲಿ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಗಮನಾರ್ಹವಾದ ನಷ್ಟಗಳು ಪ್ರಾರಂಭವಾಗುತ್ತವೆ ಎಂದು ನಾನು ಕಂಡುಹಿಡಿದಿದ್ದೇನೆ.
ಬಳಸಿದ ಮೆಮೊರಿಯನ್ನು ಪೇಜ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಹಿಂದೆ ಉಲ್ಲೇಖಿಸಲಾಗಿದೆ; "ಒಂದು ಪುಟ - ಸಂಕುಚಿತ ಡೇಟಾದ ಒಂದು ಬ್ಲಾಕ್" ಪತ್ರವ್ಯವಹಾರವನ್ನು ಏಕೆ ಬಳಸಬಾರದು ಎಂಬುದಕ್ಕೆ ನನಗೆ ಯಾವುದೇ ಕಾರಣವಿಲ್ಲ.

ಅಂದರೆ, ಕನಿಷ್ಟ ಸಮಂಜಸವಾದ ಪುಟದ ಗಾತ್ರವು 16Kb ಆಗಿದೆ (ಸೇವಾ ಮಾಹಿತಿಗಾಗಿ ಮೀಸಲು ಜೊತೆ). ಆದಾಗ್ಯೂ, ಅಂತಹ ಸಣ್ಣ ಪುಟದ ಗಾತ್ರವು ಗರಿಷ್ಠ ದಾಖಲೆ ಗಾತ್ರದ ಮೇಲೆ ಗಮನಾರ್ಹ ನಿರ್ಬಂಧಗಳನ್ನು ವಿಧಿಸುತ್ತದೆ.

ಸಂಕುಚಿತ ರೂಪದಲ್ಲಿ ಕೆಲವು ಕಿಲೋಬೈಟ್‌ಗಳಿಗಿಂತ ದೊಡ್ಡದಾದ ದಾಖಲೆಗಳನ್ನು ನಾನು ಇನ್ನೂ ನಿರೀಕ್ಷಿಸದಿದ್ದರೂ, ನಾನು 32Kb ಪುಟಗಳನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಿದೆ (ಪ್ರತಿ ಚಿಪ್‌ಗೆ ಒಟ್ಟು 128 ಪುಟಗಳಿಗೆ).

ಸಾರಾಂಶ:

• ನಾವು zlib (ಡಿಫ್ಲೇಟ್) ಬಳಸಿ ಸಂಕುಚಿತ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ;
• ಪ್ರತಿ ನಮೂದುಗೆ ನಾವು Z_SYNC_FLUSH ಅನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ;
• ಪ್ರತಿ ಸಂಕುಚಿತ ದಾಖಲೆಗಾಗಿ, ನಾವು ಟ್ರೇಲಿಂಗ್ ಬೈಟ್‌ಗಳನ್ನು ಟ್ರಿಮ್ ಮಾಡುತ್ತೇವೆ (ಉದಾ 0x00, 0x00, 0xff, 0xff); ಹೆಡರ್‌ನಲ್ಲಿ ನಾವು ಎಷ್ಟು ಬೈಟ್‌ಗಳನ್ನು ಕತ್ತರಿಸಿದ್ದೇವೆ ಎಂದು ಸೂಚಿಸುತ್ತೇವೆ;
• ನಾವು 32Kb ಪುಟಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ; ಪುಟದ ಒಳಗೆ ಸಂಕುಚಿತ ಡೇಟಾದ ಒಂದೇ ಸ್ಟ್ರೀಮ್ ಇದೆ; ಪ್ರತಿ ಪುಟದಲ್ಲಿ ನಾವು ಮತ್ತೆ ಸಂಕೋಚನವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ.

ಮತ್ತು, ಸಂಕೋಚನದೊಂದಿಗೆ ಮುಗಿಸುವ ಮೊದಲು, ನಾವು ಪ್ರತಿ ರೆಕಾರ್ಡ್‌ಗೆ ಸಂಕುಚಿತ ಡೇಟಾದ ಕೆಲವು ಬೈಟ್‌ಗಳನ್ನು ಮಾತ್ರ ಹೊಂದಿದ್ದೇವೆ ಎಂಬ ಅಂಶಕ್ಕೆ ನಿಮ್ಮ ಗಮನವನ್ನು ಸೆಳೆಯಲು ನಾನು ಬಯಸುತ್ತೇನೆ, ಆದ್ದರಿಂದ ಸೇವಾ ಮಾಹಿತಿಯನ್ನು ಹೆಚ್ಚಿಸದಿರುವುದು ಬಹಳ ಮುಖ್ಯ, ಪ್ರತಿ ಬೈಟ್ ಇಲ್ಲಿ ಎಣಿಕೆಯಾಗುತ್ತದೆ.

ಡೇಟಾ ಹೆಡರ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು

ನಾವು ವೇರಿಯಬಲ್ ಉದ್ದದ ದಾಖಲೆಗಳನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ನಾವು ಹೇಗಾದರೂ ದಾಖಲೆಗಳ ನಿಯೋಜನೆ / ಗಡಿಗಳನ್ನು ನಿರ್ಧರಿಸುವ ಅಗತ್ಯವಿದೆ.

ನನಗೆ ಮೂರು ವಿಧಾನಗಳು ತಿಳಿದಿವೆ:

1. ಎಲ್ಲಾ ದಾಖಲೆಗಳನ್ನು ನಿರಂತರ ಸ್ಟ್ರೀಮ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಮೊದಲು ಉದ್ದವನ್ನು ಹೊಂದಿರುವ ರೆಕಾರ್ಡ್ ಹೆಡರ್ ಇರುತ್ತದೆ, ಮತ್ತು ನಂತರ ರೆಕಾರ್ಡ್ ಸ್ವತಃ.
   ಈ ಸಾಕಾರದಲ್ಲಿ, ಶೀರ್ಷಿಕೆಗಳು ಮತ್ತು ಡೇಟಾ ಎರಡೂ ವೇರಿಯಬಲ್ ಉದ್ದವನ್ನು ಹೊಂದಿರಬಹುದು.
   ಮೂಲಭೂತವಾಗಿ, ನಾವು ಸಾರ್ವಕಾಲಿಕವಾಗಿ ಬಳಸಲಾಗುವ ಏಕೈಕ ಲಿಂಕ್ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯುತ್ತೇವೆ;
2. ಹೆಡರ್‌ಗಳು ಮತ್ತು ದಾಖಲೆಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಸ್ಟ್ರೀಮ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.
   ನಿರಂತರ ಉದ್ದದ ಹೆಡರ್‌ಗಳನ್ನು ಬಳಸುವ ಮೂಲಕ, ಒಂದು ಹೆಡರ್‌ಗೆ ಹಾನಿಯು ಇತರರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ.
   ಇದೇ ರೀತಿಯ ವಿಧಾನವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಅನೇಕ ಕಡತ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ;
3. ದಾಖಲೆಗಳನ್ನು ನಿರಂತರ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ದಾಖಲೆಯ ಗಡಿಯನ್ನು ನಿರ್ದಿಷ್ಟ ಮಾರ್ಕರ್‌ನಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ (ಡೇಟಾ ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ನಿಷೇಧಿಸಲಾದ ಅಕ್ಷರಗಳ ಅಕ್ಷರ/ಅನುಕ್ರಮ). ರೆಕಾರ್ಡ್ ಒಳಗೆ ಮಾರ್ಕರ್ ಇದ್ದರೆ, ನಾವು ಅದನ್ನು ಕೆಲವು ಅನುಕ್ರಮದೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ (ಅದನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳಿ).
   ಇದೇ ರೀತಿಯ ವಿಧಾನವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, PPP ಪ್ರೋಟೋಕಾಲ್ನಲ್ಲಿ.

ನಾನು ವಿವರಿಸುತ್ತೇನೆ.

ಆಯ್ಕೆ 1:

ಇಲ್ಲಿ ಎಲ್ಲವೂ ತುಂಬಾ ಸರಳವಾಗಿದೆ: ದಾಖಲೆಯ ಉದ್ದವನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು, ನಾವು ಮುಂದಿನ ಹೆಡರ್ನ ವಿಳಾಸವನ್ನು ಲೆಕ್ಕ ಹಾಕಬಹುದು. ಆದ್ದರಿಂದ ನಾವು 0xff (ಮುಕ್ತ ಪ್ರದೇಶ) ಅಥವಾ ಪುಟದ ಅಂತ್ಯದಿಂದ ತುಂಬಿದ ಪ್ರದೇಶವನ್ನು ಎದುರಿಸುವವರೆಗೆ ನಾವು ಶೀರ್ಷಿಕೆಗಳ ಮೂಲಕ ಚಲಿಸುತ್ತೇವೆ.

ಆಯ್ಕೆ 2:

ವೇರಿಯೇಬಲ್ ರೆಕಾರ್ಡ್ ಉದ್ದದ ಕಾರಣ, ಪ್ರತಿ ಪುಟಕ್ಕೆ ಎಷ್ಟು ದಾಖಲೆಗಳು (ಮತ್ತು ಆದ್ದರಿಂದ ಹೆಡರ್) ಅಗತ್ಯವಿದೆ ಎಂದು ನಾವು ಮುಂಚಿತವಾಗಿ ಹೇಳಲಾಗುವುದಿಲ್ಲ. ನೀವು ಹೆಡರ್‌ಗಳು ಮತ್ತು ಡೇಟಾವನ್ನು ಬೇರೆ ಬೇರೆ ಪುಟಗಳಲ್ಲಿ ಹರಡಬಹುದು, ಆದರೆ ನಾನು ವಿಭಿನ್ನ ವಿಧಾನವನ್ನು ಬಯಸುತ್ತೇನೆ: ನಾವು ಹೆಡರ್‌ಗಳು ಮತ್ತು ಡೇಟಾ ಎರಡನ್ನೂ ಒಂದೇ ಪುಟದಲ್ಲಿ ಇರಿಸುತ್ತೇವೆ, ಆದರೆ ಹೆಡರ್‌ಗಳು (ಸ್ಥಿರ ಗಾತ್ರದ) ಪುಟದ ಆರಂಭದಿಂದ ಬರುತ್ತವೆ, ಮತ್ತು ಡೇಟಾ (ವೇರಿಯಬಲ್ ಉದ್ದದ) ಅಂತ್ಯದಿಂದ ಬರುತ್ತದೆ. ಅವರು "ಭೇಟಿ" ಆದ ತಕ್ಷಣ (ಹೊಸ ಪ್ರವೇಶಕ್ಕೆ ಸಾಕಷ್ಟು ಉಚಿತ ಸ್ಥಳವಿಲ್ಲ), ನಾವು ಈ ಪುಟವನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತೇವೆ ಎಂದು ಪರಿಗಣಿಸುತ್ತೇವೆ.

ಆಯ್ಕೆ 3:

ಹೆಡರ್‌ನಲ್ಲಿ ಡೇಟಾದ ಸ್ಥಳದ ಬಗ್ಗೆ ಉದ್ದ ಅಥವಾ ಇತರ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲ; ದಾಖಲೆಗಳ ಗಡಿಗಳನ್ನು ಸೂಚಿಸುವ ಗುರುತುಗಳು ಸಾಕು. ಆದಾಗ್ಯೂ, ಬರೆಯುವಾಗ / ಓದುವಾಗ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು.
ನಾನು 0xff ಅನ್ನು ಮಾರ್ಕರ್ ಆಗಿ ಬಳಸುತ್ತೇನೆ (ಅದು ಅಳಿಸಿದ ನಂತರ ಪುಟವನ್ನು ತುಂಬುತ್ತದೆ), ಆದ್ದರಿಂದ ಉಚಿತ ಪ್ರದೇಶವನ್ನು ಖಂಡಿತವಾಗಿಯೂ ಡೇಟಾ ಎಂದು ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ.

ಹೋಲಿಕೆ ಕೋಷ್ಟಕ:

ಆಯ್ಕೆ 1
ಆಯ್ಕೆ 2
ಆಯ್ಕೆ 3

ದೋಷ ಸಹಿಷ್ಣುತೆ
-
+
+

ಸಾಂದ್ರತೆ
+
-
+

ಅನುಷ್ಠಾನದ ಸಂಕೀರ್ಣತೆ
*
**
**

ಆಯ್ಕೆ 1 ಮಾರಣಾಂತಿಕ ದೋಷವನ್ನು ಹೊಂದಿದೆ: ಯಾವುದೇ ಹೆಡರ್ ಹಾನಿಗೊಳಗಾದರೆ, ಸಂಪೂರ್ಣ ನಂತರದ ಸರಪಳಿ ನಾಶವಾಗುತ್ತದೆ. ಬೃಹತ್ ಹಾನಿಯ ಸಂದರ್ಭದಲ್ಲಿಯೂ ಸಹ ಕೆಲವು ಡೇಟಾವನ್ನು ಮರುಪಡೆಯಲು ಉಳಿದ ಆಯ್ಕೆಗಳು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತವೆ.
ಆದರೆ ಇಲ್ಲಿ ನಾವು ಡೇಟಾವನ್ನು ಸಂಕುಚಿತ ರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ಎಂದು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಸೂಕ್ತವಾಗಿದೆ ಮತ್ತು ಆದ್ದರಿಂದ ನಾವು "ಮುರಿದ" ದಾಖಲೆಯ ನಂತರ ಪುಟದಲ್ಲಿನ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ, ಆದ್ದರಿಂದ ಟೇಬಲ್ನಲ್ಲಿ ಮೈನಸ್ ಇದ್ದರೂ, ನಾವು ಮಾಡುವುದಿಲ್ಲ ಅದನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಿ.

ಸಾಂದ್ರತೆ:

• ಮೊದಲ ಆಯ್ಕೆಯಲ್ಲಿ, ನಾವು ಹೆಡರ್‌ನಲ್ಲಿ ಉದ್ದವನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸಬೇಕಾಗಿದೆ; ನಾವು ವೇರಿಯಬಲ್-ಉದ್ದದ ಪೂರ್ಣಾಂಕಗಳನ್ನು ಬಳಸಿದರೆ, ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ನಾವು ಒಂದು ಬೈಟ್ ಮೂಲಕ ಪಡೆಯಬಹುದು;
• ಎರಡನೇ ಆಯ್ಕೆಯಲ್ಲಿ ನಾವು ಆರಂಭಿಕ ವಿಳಾಸ ಮತ್ತು ಉದ್ದವನ್ನು ಸಂಗ್ರಹಿಸಬೇಕಾಗಿದೆ; ದಾಖಲೆಯು ಸ್ಥಿರ ಗಾತ್ರವಾಗಿರಬೇಕು, ನಾನು ಪ್ರತಿ ದಾಖಲೆಗೆ 4 ಬೈಟ್‌ಗಳನ್ನು ಅಂದಾಜು ಮಾಡುತ್ತೇನೆ (ಆಫ್‌ಸೆಟ್‌ಗಾಗಿ ಎರಡು ಬೈಟ್‌ಗಳು ಮತ್ತು ಉದ್ದಕ್ಕಾಗಿ ಎರಡು ಬೈಟ್‌ಗಳು);
• ರೆಕಾರ್ಡಿಂಗ್‌ನ ಪ್ರಾರಂಭವನ್ನು ಸೂಚಿಸಲು ಮೂರನೇ ಆಯ್ಕೆಗೆ ಕೇವಲ ಒಂದು ಅಕ್ಷರದ ಅಗತ್ಯವಿದೆ, ಜೊತೆಗೆ ರೆಕಾರ್ಡಿಂಗ್ ಸ್ವತಃ ಶೀಲ್ಡಿಂಗ್‌ನಿಂದ 1-2% ರಷ್ಟು ಹೆಚ್ಚಾಗುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಮೊದಲ ಆಯ್ಕೆಯೊಂದಿಗೆ ಸರಿಸುಮಾರು ಸಮಾನತೆ.

ಆರಂಭದಲ್ಲಿ, ನಾನು ಎರಡನೆಯ ಆಯ್ಕೆಯನ್ನು ಮುಖ್ಯವೆಂದು ಪರಿಗಣಿಸಿದೆ (ಮತ್ತು ಅನುಷ್ಠಾನವನ್ನು ಸಹ ಬರೆದಿದ್ದೇನೆ). ನಾನು ಅಂತಿಮವಾಗಿ ಸಂಕೋಚನವನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಿದಾಗ ಮಾತ್ರ ನಾನು ಅದನ್ನು ತ್ಯಜಿಸಿದೆ.

ಬಹುಶಃ ಒಂದು ದಿನ ನಾನು ಇನ್ನೂ ಇದೇ ರೀತಿಯ ಆಯ್ಕೆಯನ್ನು ಬಳಸುತ್ತೇನೆ. ಉದಾಹರಣೆಗೆ, ಭೂಮಿ ಮತ್ತು ಮಂಗಳ ಗ್ರಹಗಳ ನಡುವೆ ಪ್ರಯಾಣಿಸುವ ಹಡಗಿನ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ನಾನು ವ್ಯವಹರಿಸಬೇಕಾದರೆ, ವಿಶ್ವಾಸಾರ್ಹತೆ, ಕಾಸ್ಮಿಕ್ ವಿಕಿರಣ, ...

ಮೂರನೆಯ ಆಯ್ಕೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ: ಶೀಲ್ಡಿಂಗ್‌ನೊಂದಿಗೆ ಗೊಂದಲಕ್ಕೀಡಾಗುವುದು, ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಉದ್ದವನ್ನು ಬದಲಾಯಿಸುವುದು ಇತ್ಯಾದಿಗಳನ್ನು ನಾನು ಇಷ್ಟಪಡದ ಕಾರಣ ಅನುಷ್ಠಾನದ ತೊಂದರೆಗಾಗಿ ನಾನು ಅದಕ್ಕೆ ಎರಡು ನಕ್ಷತ್ರಗಳನ್ನು ನೀಡಿದ್ದೇನೆ. ಹೌದು, ಬಹುಶಃ ನಾನು ಪಕ್ಷಪಾತಿಯಾಗಿದ್ದೇನೆ, ಆದರೆ ನಾನು ಕೋಡ್ ಅನ್ನು ಬರೆಯಬೇಕಾಗಿದೆ - ನಿಮಗೆ ಇಷ್ಟವಿಲ್ಲದ ಕೆಲಸವನ್ನು ಮಾಡಲು ನಿಮ್ಮನ್ನು ಏಕೆ ಒತ್ತಾಯಿಸಬೇಕು.

ಸಾರಾಂಶ: ದಕ್ಷತೆ ಮತ್ತು ಅನುಷ್ಠಾನದ ಸುಲಭತೆಯಿಂದಾಗಿ ನಾವು "ಉದ್ದದೊಂದಿಗೆ ಹೆಡರ್ - ವೇರಿಯಬಲ್ ಉದ್ದದ ಡೇಟಾ" ಸರಪಳಿಗಳ ರೂಪದಲ್ಲಿ ಶೇಖರಣಾ ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿಕೊಳ್ಳುತ್ತೇವೆ.

ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಗಳ ಯಶಸ್ಸನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಬಿಟ್ ಫೀಲ್ಡ್‌ಗಳನ್ನು ಬಳಸುವುದು

ನಾನು ಕಲ್ಪನೆಯನ್ನು ಎಲ್ಲಿ ಪಡೆದುಕೊಂಡೆ ಎಂದು ನನಗೆ ಈಗ ನೆನಪಿಲ್ಲ, ಆದರೆ ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
ಪ್ರತಿ ಪ್ರವೇಶಕ್ಕೆ, ನಾವು ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಹಲವಾರು ಬಿಟ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ.
ನಾವು ಮೊದಲೇ ಹೇಳಿದಂತೆ, ಅಳಿಸಿದ ನಂತರ ಎಲ್ಲಾ ಬಿಟ್‌ಗಳು 1 ಸೆಗಳಿಂದ ತುಂಬಿರುತ್ತವೆ ಮತ್ತು ನಾವು 1 ರಿಂದ 0 ಗೆ ಬದಲಾಯಿಸಬಹುದು, ಆದರೆ ಪ್ರತಿಯಾಗಿ ಅಲ್ಲ. ಆದ್ದರಿಂದ "ಧ್ವಜವನ್ನು ಹೊಂದಿಸಲಾಗಿಲ್ಲ" ಗಾಗಿ ನಾವು 1 ಅನ್ನು ಬಳಸುತ್ತೇವೆ, "ಧ್ವಜವನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ" ಗಾಗಿ ನಾವು 0 ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ವೇರಿಯಬಲ್-ಉದ್ದದ ದಾಖಲೆಯನ್ನು ಫ್ಲ್ಯಾಷ್‌ಗೆ ಹಾಕುವುದು ಹೇಗಿರಬಹುದು ಎಂಬುದು ಇಲ್ಲಿದೆ:

1. ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿಸಿ "ಉದ್ದದ ರೆಕಾರ್ಡಿಂಗ್ ಪ್ರಾರಂಭವಾಗಿದೆ";
2. ಉದ್ದವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿ;
3. "ಡೇಟಾ ರೆಕಾರ್ಡಿಂಗ್ ಪ್ರಾರಂಭವಾಗಿದೆ" ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿಸಿ;
4. ನಾವು ಡೇಟಾವನ್ನು ದಾಖಲಿಸುತ್ತೇವೆ;
5. "ರೆಕಾರ್ಡಿಂಗ್ ಎಂಡ್" ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿಸಿ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಒಟ್ಟು 4 ಬಿಟ್ ಫ್ಲ್ಯಾಗ್‌ಗಳಿಗಾಗಿ “ದೋಷ ಸಂಭವಿಸಿದೆ” ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಎರಡು ಸ್ಥಿರ ಸ್ಥಿತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ “1111” - ರೆಕಾರ್ಡಿಂಗ್ ಪ್ರಾರಂಭವಾಗಿಲ್ಲ ಮತ್ತು “1000” - ರೆಕಾರ್ಡಿಂಗ್ ಯಶಸ್ವಿಯಾಗಿದೆ; ರೆಕಾರ್ಡಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯ ಅನಿರೀಕ್ಷಿತ ಅಡಚಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಮಧ್ಯಂತರ ಸ್ಥಿತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ, ಅದನ್ನು ನಾವು ಪತ್ತೆ ಮಾಡಬಹುದು ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು.

ವಿಧಾನವು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಆದರೆ ಇದು ಹಠಾತ್ ವಿದ್ಯುತ್ ನಿಲುಗಡೆ ಮತ್ತು ಅಂತಹುದೇ ವೈಫಲ್ಯಗಳಿಂದ ಮಾತ್ರ ರಕ್ಷಿಸುತ್ತದೆ, ಇದು ಸಹಜವಾಗಿ ಮುಖ್ಯವಾಗಿದೆ, ಆದರೆ ಇದು ಸಂಭವನೀಯ ವೈಫಲ್ಯಗಳಿಗೆ ಏಕೈಕ (ಅಥವಾ ಮುಖ್ಯ) ಕಾರಣದಿಂದ ದೂರವಿದೆ.

ಸಾರಾಂಶ: ಉತ್ತಮ ಪರಿಹಾರದ ಹುಡುಕಾಟದಲ್ಲಿ ಮುಂದುವರಿಯೋಣ.

ಚೆಕ್ಸಮ್ಗಳು

ಚೆಕ್‌ಸಮ್‌ಗಳು (ಸಮಂಜಸವಾದ ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ) ನಾವು ಬರೆಯಬೇಕಾದದ್ದನ್ನು ನಿಖರವಾಗಿ ಓದುತ್ತಿದ್ದೇವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ಮತ್ತು, ಮೇಲೆ ಚರ್ಚಿಸಿದ ಬಿಟ್ ಕ್ಷೇತ್ರಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, ಅವು ಯಾವಾಗಲೂ ಕೆಲಸ ಮಾಡುತ್ತವೆ.

ನಾವು ಮೇಲೆ ಚರ್ಚಿಸಿದ ಸಮಸ್ಯೆಗಳ ಸಂಭಾವ್ಯ ಮೂಲಗಳ ಪಟ್ಟಿಯನ್ನು ನಾವು ಪರಿಗಣಿಸಿದರೆ, ಚೆಕ್ಸಮ್ ಅದರ ಮೂಲವನ್ನು ಲೆಕ್ಕಿಸದೆ ದೋಷವನ್ನು ಗುರುತಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ (ಬಹುಶಃ, ದುರುದ್ದೇಶಪೂರಿತ ವಿದೇಶಿಯರು ಹೊರತುಪಡಿಸಿ - ಅವರು ಚೆಕ್ಸಮ್ ಅನ್ನು ಸಹ ನಕಲಿ ಮಾಡಬಹುದು).

ಆದ್ದರಿಂದ ಡೇಟಾ ಅಖಂಡವಾಗಿದೆ ಎಂದು ಪರಿಶೀಲಿಸುವುದು ನಮ್ಮ ಗುರಿಯಾಗಿದ್ದರೆ, ಚೆಕ್‌ಸಮ್‌ಗಳು ಉತ್ತಮ ಉಪಾಯವಾಗಿದೆ.

ಚೆಕ್ಸಮ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಅಲ್ಗಾರಿದಮ್ನ ಆಯ್ಕೆಯು ಯಾವುದೇ ಪ್ರಶ್ನೆಗಳನ್ನು ಹುಟ್ಟುಹಾಕಲಿಲ್ಲ - CRC. ಒಂದೆಡೆ, ಗಣಿತದ ಗುಣಲಕ್ಷಣಗಳು ಕೆಲವು ರೀತಿಯ ದೋಷಗಳನ್ನು 100% ಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ; ಮತ್ತೊಂದೆಡೆ, ಯಾದೃಚ್ಛಿಕ ಡೇಟಾದಲ್ಲಿ ಈ ಅಲ್ಗಾರಿದಮ್ ಸಾಮಾನ್ಯವಾಗಿ ಸೈದ್ಧಾಂತಿಕ ಮಿತಿಗಿಂತ ಹೆಚ್ಚಿಲ್ಲದ ಘರ್ಷಣೆಯ ಸಂಭವನೀಯತೆಯನ್ನು ತೋರಿಸುತ್ತದೆ. . ಇದು ಅತ್ಯಂತ ವೇಗದ ಅಲ್ಗಾರಿದಮ್ ಆಗಿರಬಾರದು ಅಥವಾ ಘರ್ಷಣೆಗಳ ಸಂಖ್ಯೆಯ ವಿಷಯದಲ್ಲಿ ಯಾವಾಗಲೂ ಕನಿಷ್ಠವಾಗಿರುವುದಿಲ್ಲ, ಆದರೆ ಇದು ಬಹಳ ಮುಖ್ಯವಾದ ಗುಣಮಟ್ಟವನ್ನು ಹೊಂದಿದೆ: ನಾನು ಎದುರಿಸಿದ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ, ಅದು ಸ್ಪಷ್ಟವಾಗಿ ವಿಫಲವಾದ ಯಾವುದೇ ಮಾದರಿಗಳಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸ್ಥಿರತೆ ಮುಖ್ಯ ಗುಣಮಟ್ಟವಾಗಿದೆ.

ವಾಲ್ಯೂಮೆಟ್ರಿಕ್ ಅಧ್ಯಯನದ ಉದಾಹರಣೆ: 1 ನ ಭಾಗ, 2 ನ ಭಾಗ (narod.ru ಗೆ ಲಿಂಕ್‌ಗಳು, ಕ್ಷಮಿಸಿ).

ಆದಾಗ್ಯೂ, ಚೆಕ್ಸಮ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಕಾರ್ಯವು ಪೂರ್ಣಗೊಂಡಿಲ್ಲ; CRC ಎಂಬುದು ಚೆಕ್ಸಮ್ಗಳ ಸಂಪೂರ್ಣ ಕುಟುಂಬವಾಗಿದೆ. ನೀವು ಉದ್ದವನ್ನು ನಿರ್ಧರಿಸಬೇಕು, ತದನಂತರ ಬಹುಪದವನ್ನು ಆರಿಸಿ.

ಚೆಕ್ಸಮ್ ಉದ್ದವನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಮೊದಲ ನೋಟದಲ್ಲಿ ತೋರುವಷ್ಟು ಸರಳವಾದ ಪ್ರಶ್ನೆಯಲ್ಲ.

ನಾನು ವಿವರಿಸುತ್ತೇನೆ:
ಪ್ರತಿ ಬೈಟ್‌ನಲ್ಲಿ ದೋಷದ ಸಂಭವನೀಯತೆಯನ್ನು ನಾವು ಹೊಂದೋಣ ಮತ್ತು ಆದರ್ಶ ಚೆಕ್ಸಮ್, ಪ್ರತಿ ಮಿಲಿಯನ್ ದಾಖಲೆಗಳಿಗೆ ಸರಾಸರಿ ದೋಷಗಳ ಸಂಖ್ಯೆಯನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ:

ಡೇಟಾ, ಬೈಟ್
ಚೆಕ್ಸಮ್, ಬೈಟ್
ಪತ್ತೆಯಾಗದ ದೋಷಗಳು
ತಪ್ಪು ದೋಷ ಪತ್ತೆ
ಒಟ್ಟು ತಪ್ಪು ಧನಾತ್ಮಕ

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

ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ - ರಕ್ಷಿಸಲಾದ ಡೇಟಾದ ಉದ್ದವನ್ನು ಅವಲಂಬಿಸಿ, ಚೆಕ್ಸಮ್ನ ಉದ್ದವನ್ನು ಕನಿಷ್ಠ ತಪ್ಪಾದ ಧನಾತ್ಮಕಗಳೊಂದಿಗೆ ಆಯ್ಕೆಮಾಡಿ - ಮತ್ತು ಟ್ರಿಕ್ ಚೀಲದಲ್ಲಿದೆ.

ಆದಾಗ್ಯೂ, ಸಣ್ಣ ಚೆಕ್‌ಸಮ್‌ಗಳೊಂದಿಗೆ ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ: ಸಿಂಗಲ್ ಬಿಟ್ ದೋಷಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವಲ್ಲಿ ಅವು ಉತ್ತಮವಾಗಿದ್ದರೂ, ಸಾಕಷ್ಟು ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ ಅವರು ಸಂಪೂರ್ಣವಾಗಿ ಯಾದೃಚ್ಛಿಕ ಡೇಟಾವನ್ನು ಸರಿಯಾಗಿ ಸ್ವೀಕರಿಸಬಹುದು. ಹಬ್ರೆ ವಿವರಿಸುವ ಲೇಖನ ಈಗಾಗಲೇ ಇತ್ತು ನಿಜ ಜೀವನದಲ್ಲಿ ಸಮಸ್ಯೆ.

ಆದ್ದರಿಂದ, ಯಾದೃಚ್ಛಿಕ ಚೆಕ್ಸಮ್ ಹೊಂದಾಣಿಕೆಯನ್ನು ಅಸಾಧ್ಯವಾಗಿಸಲು, ನೀವು 32 ಬಿಟ್‌ಗಳು ಅಥವಾ ಅದಕ್ಕಿಂತ ಹೆಚ್ಚು ಉದ್ದವಿರುವ ಚೆಕ್‌ಸಮ್‌ಗಳನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ. (64 ಬಿಟ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚಿನ ಉದ್ದಗಳಿಗೆ, ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಹ್ಯಾಶ್ ಕಾರ್ಯಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ).

ನಾವು ಎಲ್ಲಾ ವಿಧಾನಗಳಿಂದ ಜಾಗವನ್ನು ಉಳಿಸಬೇಕಾಗಿದೆ ಎಂದು ನಾನು ಮೊದಲೇ ಬರೆದಿದ್ದರೂ, ನಾವು ಇನ್ನೂ 32-ಬಿಟ್ ಚೆಕ್‌ಸಮ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ (16 ಬಿಟ್‌ಗಳು ಸಾಕಾಗುವುದಿಲ್ಲ, ಘರ್ಷಣೆಯ ಸಂಭವನೀಯತೆ 0.01% ಕ್ಕಿಂತ ಹೆಚ್ಚು; ಮತ್ತು 24 ಬಿಟ್‌ಗಳು ಹೇಳು, ಇಲ್ಲಿಯೂ ಇಲ್ಲವೂ ಇಲ್ಲ) .

ಇಲ್ಲಿ ಒಂದು ಆಕ್ಷೇಪಣೆ ಉಂಟಾಗಬಹುದು: ಈಗ ಏಕಕಾಲದಲ್ಲಿ 4 ಬೈಟ್‌ಗಳನ್ನು ನೀಡಲು ಸಂಕೋಚನವನ್ನು ಆರಿಸುವಾಗ ನಾವು ಪ್ರತಿ ಬೈಟ್ ಅನ್ನು ಉಳಿಸಿದ್ದೇವೆಯೇ? ಚೆಕ್ಸಮ್ ಅನ್ನು ಸಂಕುಚಿತಗೊಳಿಸದಿರುವುದು ಅಥವಾ ಸೇರಿಸದಿರುವುದು ಉತ್ತಮವಲ್ಲವೇ? ಖಂಡಿತ ಇಲ್ಲ, ಸಂಕೋಚನವಿಲ್ಲ ಅರ್ಥವಲ್ಲ, ನಾವು ಸಮಗ್ರತೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು.

ಬಹುಪದವನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ, ನಾವು ಚಕ್ರವನ್ನು ಮರುಶೋಧಿಸುವುದಿಲ್ಲ, ಆದರೆ ಈಗ ಜನಪ್ರಿಯವಾಗಿರುವ CRC-32C ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ.
ಈ ಕೋಡ್ 6 ಬೈಟ್‌ಗಳವರೆಗಿನ ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ 22 ಬಿಟ್ ದೋಷಗಳನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ (ಬಹುಶಃ ನಮಗೆ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಪ್ರಕರಣ), 4 ಬೈಟ್‌ಗಳವರೆಗಿನ ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ 655 ಬಿಟ್ ದೋಷಗಳು (ನಮಗೆ ಸಹ ಸಾಮಾನ್ಯ ಪ್ರಕರಣ), 2 ಅಥವಾ ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿನ ಯಾವುದೇ ಬೆಸ ಸಂಖ್ಯೆಯ ಬಿಟ್ ದೋಷಗಳನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ ಯಾವುದೇ ಸಮಂಜಸವಾದ ಉದ್ದ.

ಯಾರಾದರೂ ವಿವರಗಳಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ

ವಿಕಿಪೀಡಿಯ ಲೇಖನ CRC ಬಗ್ಗೆ.

ಕೋಡ್ ನಿಯತಾಂಕಗಳು crc-32c ಮೇಲೆ ಕೂಪ್‌ಮನ್ ವೆಬ್‌ಸೈಟ್ - ಬಹುಶಃ ಗ್ರಹದ ಪ್ರಮುಖ CRC ತಜ್ಞ.

В ಅವರ ಲೇಖನ ಆಗಿದೆ ಮತ್ತೊಂದು ಆಸಕ್ತಿದಾಯಕ ಕೋಡ್, ಇದು ನಮಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ಯಾಕೆಟ್ ಉದ್ದಗಳಿಗೆ ಸ್ವಲ್ಪ ಉತ್ತಮವಾದ ನಿಯತಾಂಕಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಆದರೆ ನಾನು ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಪರಿಗಣಿಸಲಿಲ್ಲ ಮತ್ತು ಪ್ರಮಾಣಿತ ಮತ್ತು ಉತ್ತಮವಾಗಿ-ಸಂಶೋಧಿಸಿದ ಒಂದಕ್ಕೆ ಬದಲಾಗಿ ಕಸ್ಟಮ್ ಕೋಡ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ನಾನು ಸಾಕಷ್ಟು ಸಮರ್ಥನಾಗಿದ್ದೆ.

ಅಲ್ಲದೆ, ನಮ್ಮ ಡೇಟಾವನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಿರುವುದರಿಂದ, ಪ್ರಶ್ನೆಯು ಉದ್ಭವಿಸುತ್ತದೆ: ಸಂಕುಚಿತ ಅಥವಾ ಸಂಕ್ಷೇಪಿಸದ ಡೇಟಾದ ಚೆಕ್ಸಮ್ ಅನ್ನು ನಾವು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬೇಕೇ?

ಸಂಕ್ಷೇಪಿಸದ ಡೇಟಾದ ಚೆಕ್ಸಮ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ಪರವಾಗಿ ವಾದಗಳು:

• ನಾವು ಅಂತಿಮವಾಗಿ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ಸುರಕ್ಷತೆಯನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾಗಿದೆ - ಆದ್ದರಿಂದ ನಾವು ಅದನ್ನು ನೇರವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತೇವೆ (ಅದೇ ಸಮಯದಲ್ಲಿ, ಸಂಕೋಚನ / ಡಿಕಂಪ್ರೆಷನ್ ಅನುಷ್ಠಾನದಲ್ಲಿ ಸಂಭವನೀಯ ದೋಷಗಳು, ಮುರಿದ ಮೆಮೊರಿಯಿಂದ ಉಂಟಾಗುವ ಹಾನಿ, ಇತ್ಯಾದಿಗಳನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ);
• zlib ನಲ್ಲಿನ ಡಿಫ್ಲೇಟ್ ಅಲ್ಗಾರಿದಮ್ ಸಾಕಷ್ಟು ಪ್ರಬುದ್ಧ ಅನುಷ್ಠಾನವನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಮಾಡಬಾರದು "ಬಾಗಿದ" ಇನ್‌ಪುಟ್ ಡೇಟಾದೊಂದಿಗೆ ಬೀಳುತ್ತದೆ; ಮೇಲಾಗಿ, ಇನ್‌ಪುಟ್ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ದೋಷಗಳನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಪತ್ತೆಹಚ್ಚಲು ಇದು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ದೋಷವನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಒಟ್ಟಾರೆ ಸಂಭವನೀಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ (ಒಂದು ಸಣ್ಣ ದಾಖಲೆಯಲ್ಲಿ ಒಂದೇ ಬಿಟ್ ಅನ್ನು ತಲೆಕೆಳಗು ಮಾಡುವ ಮೂಲಕ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿತು, zlib ದೋಷವನ್ನು ಪತ್ತೆಹಚ್ಚಿದೆ ಸುಮಾರು ಮೂರನೇ ಒಂದು ಭಾಗದಷ್ಟು ಪ್ರಕರಣಗಳಲ್ಲಿ).

ಸಂಕ್ಷೇಪಿಸದ ಡೇಟಾದ ಚೆಕ್ಸಮ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವ ವಿರುದ್ಧ ವಾದಗಳು:

• CRC ನಿರ್ದಿಷ್ಟವಾಗಿ ಫ್ಲ್ಯಾಶ್ ಮೆಮೊರಿಯ ವಿಶಿಷ್ಟವಾದ ಕೆಲವು ಬಿಟ್ ದೋಷಗಳಿಗಾಗಿ "ಅನುಗುಣವಾಗಿದೆ" (ಸಂಕುಚಿತ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿನ ಸ್ವಲ್ಪ ದೋಷವು ಔಟ್‌ಪುಟ್ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಭಾರಿ ಬದಲಾವಣೆಯನ್ನು ಉಂಟುಮಾಡಬಹುದು, ಅದರ ಮೇಲೆ, ಸಂಪೂರ್ಣವಾಗಿ ಸೈದ್ಧಾಂತಿಕವಾಗಿ, ನಾವು ಘರ್ಷಣೆಯನ್ನು "ಕ್ಯಾಚ್" ಮಾಡಬಹುದು);
• ಡಿಕಂಪ್ರೆಸರ್‌ಗೆ ಸಂಭಾವ್ಯವಾಗಿ ಮುರಿದ ಡೇಟಾವನ್ನು ರವಾನಿಸುವ ಕಲ್ಪನೆಯನ್ನು ನಾನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡುವುದಿಲ್ಲ, ಯಾರಿಗೆ ಗೊತ್ತುಅವನು ಹೇಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾನೆ.

ಈ ಯೋಜನೆಯಲ್ಲಿ, ಸಂಕ್ಷೇಪಿಸದ ಡೇಟಾದ ಚೆಕ್‌ಸಮ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುವ ಸಾಮಾನ್ಯವಾಗಿ ಸ್ವೀಕರಿಸಿದ ಅಭ್ಯಾಸದಿಂದ ವಿಪಥಗೊಳ್ಳಲು ನಾನು ನಿರ್ಧರಿಸಿದೆ.

ಸಾರಾಂಶ: ನಾವು CRC-32C ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಅವರು ಫ್ಲ್ಯಾಷ್ಗೆ ಬರೆಯಲಾದ ರೂಪದಲ್ಲಿ ಡೇಟಾದಿಂದ ಚೆಕ್ಸಮ್ ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ (ಸಂಕೋಚನದ ನಂತರ).

ಪುನರಾವರ್ತನೆ

ಅನಗತ್ಯ ಕೋಡಿಂಗ್ ಬಳಕೆಯು ಸಹಜವಾಗಿ, ಡೇಟಾ ನಷ್ಟವನ್ನು ನಿವಾರಿಸುವುದಿಲ್ಲ, ಆದಾಗ್ಯೂ, ಇದು ಗಮನಾರ್ಹವಾಗಿ (ಸಾಮಾನ್ಯವಾಗಿ ಅನೇಕ ಆದೇಶಗಳ ಮೂಲಕ) ಚೇತರಿಸಿಕೊಳ್ಳಲಾಗದ ಡೇಟಾ ನಷ್ಟದ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಲು ನಾವು ವಿವಿಧ ರೀತಿಯ ಪುನರಾವರ್ತನೆಗಳನ್ನು ಬಳಸಬಹುದು.
ಹ್ಯಾಮಿಂಗ್ ಕೋಡ್‌ಗಳು ಸಿಂಗಲ್ ಬಿಟ್ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಬಹುದು, ರೀಡ್-ಸೊಲೊಮನ್ ಅಕ್ಷರ ಸಂಕೇತಗಳು, ಚೆಕ್‌ಸಮ್‌ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಲಾದ ಡೇಟಾದ ಬಹು ಪ್ರತಿಗಳು ಅಥವಾ RAID-6 ನಂತಹ ಎನ್‌ಕೋಡಿಂಗ್‌ಗಳು ಬೃಹತ್ ಭ್ರಷ್ಟಾಚಾರದ ಸಂದರ್ಭದಲ್ಲಿಯೂ ಡೇಟಾವನ್ನು ಮರುಪಡೆಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಆರಂಭದಲ್ಲಿ, ದೋಷ-ನಿರೋಧಕ ಕೋಡಿಂಗ್‌ನ ವ್ಯಾಪಕ ಬಳಕೆಗೆ ನಾನು ಬದ್ಧನಾಗಿದ್ದೆ, ಆದರೆ ನಂತರ ನಾವು ಮೊದಲು ಯಾವ ದೋಷಗಳಿಂದ ನಮ್ಮನ್ನು ರಕ್ಷಿಸಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ ಎಂಬ ಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿರಬೇಕು ಮತ್ತು ನಂತರ ಕೋಡಿಂಗ್ ಅನ್ನು ಆರಿಸಿಕೊಳ್ಳಬೇಕು ಎಂದು ನಾನು ಅರಿತುಕೊಂಡೆ.

ದೋಷಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಹಿಡಿಯಬೇಕು ಎಂದು ನಾವು ಮೊದಲೇ ಹೇಳಿದ್ದೇವೆ. ಯಾವ ಹಂತದಲ್ಲಿ ನಾವು ದೋಷಗಳನ್ನು ಎದುರಿಸಬಹುದು?

1. ಅಪೂರ್ಣ ರೆಕಾರ್ಡಿಂಗ್ (ಕೆಲವು ಕಾರಣಕ್ಕಾಗಿ ರೆಕಾರ್ಡಿಂಗ್ ಸಮಯದಲ್ಲಿ ವಿದ್ಯುತ್ ಅನ್ನು ಆಫ್ ಮಾಡಲಾಗಿದೆ, ರಾಸ್ಪ್ಬೆರಿ ಫ್ರೀಜ್, ...)
   ಅಯ್ಯೋ, ಅಂತಹ ದೋಷದ ಸಂದರ್ಭದಲ್ಲಿ, ಅಮಾನ್ಯ ದಾಖಲೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು ಮತ್ತು ಕಳೆದುಹೋದ ಡೇಟಾವನ್ನು ಪರಿಗಣಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ;
2. ದೋಷಗಳನ್ನು ಬರೆಯಿರಿ (ಕೆಲವು ಕಾರಣಕ್ಕಾಗಿ, ಫ್ಲ್ಯಾಷ್ ಮೆಮೊರಿಗೆ ಬರೆದದ್ದು ಬರೆದದ್ದಲ್ಲ)
   ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡಿದ ತಕ್ಷಣ ನಾವು ಪರೀಕ್ಷೆಯನ್ನು ಓದಿದರೆ ಅಂತಹ ದೋಷಗಳನ್ನು ನಾವು ತಕ್ಷಣ ಪತ್ತೆ ಮಾಡಬಹುದು;
3. ಸಂಗ್ರಹಣೆಯ ಸಮಯದಲ್ಲಿ ಮೆಮೊರಿಯಲ್ಲಿ ಡೇಟಾದ ವಿರೂಪ;
4. ಓದುವ ದೋಷಗಳು
   ಅದನ್ನು ಸರಿಪಡಿಸಲು, ಚೆಕ್ಸಮ್ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಓದುವಿಕೆಯನ್ನು ಹಲವಾರು ಬಾರಿ ಪುನರಾವರ್ತಿಸಲು ಸಾಕು.

ಅಂದರೆ, ದೋಷ-ನಿರೋಧಕ ಕೋಡಿಂಗ್ ಇಲ್ಲದೆ ಮೂರನೇ ವಿಧದ ದೋಷಗಳನ್ನು (ಶೇಖರಣಾ ಸಮಯದಲ್ಲಿ ಡೇಟಾದ ಸ್ವಾಭಾವಿಕ ಭ್ರಷ್ಟಾಚಾರ) ಮಾತ್ರ ಸರಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ. ಅಂತಹ ದೋಷಗಳು ಇನ್ನೂ ಅಸಂಭವವೆಂದು ತೋರುತ್ತದೆ.

ಸಾರಾಂಶ: ಅನಗತ್ಯ ಕೋಡಿಂಗ್ ಅನ್ನು ತ್ಯಜಿಸಲು ನಿರ್ಧರಿಸಲಾಯಿತು, ಆದರೆ ಕಾರ್ಯಾಚರಣೆಯು ಈ ನಿರ್ಧಾರದ ದೋಷವನ್ನು ತೋರಿಸಿದರೆ, ಸಮಸ್ಯೆಯ ಪರಿಗಣನೆಗೆ ಹಿಂತಿರುಗಿ (ವೈಫಲ್ಯಗಳ ಕುರಿತು ಈಗಾಗಲೇ ಸಂಗ್ರಹವಾಗಿರುವ ಅಂಕಿಅಂಶಗಳೊಂದಿಗೆ, ಇದು ಸೂಕ್ತವಾದ ಕೋಡಿಂಗ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ).

Прочее

ಸಹಜವಾಗಿ, ಲೇಖನದ ಸ್ವರೂಪವು ಸ್ವರೂಪದಲ್ಲಿ ಪ್ರತಿ ಬಿಟ್ ಅನ್ನು ಸಮರ್ಥಿಸಲು ನಮಗೆ ಅನುಮತಿಸುವುದಿಲ್ಲ (ಮತ್ತು ನನ್ನ ಶಕ್ತಿ ಈಗಾಗಲೇ ಮುಗಿದಿದೆ), ಆದ್ದರಿಂದ ನಾನು ಈ ಹಿಂದೆ ಸ್ಪರ್ಶಿಸದ ಕೆಲವು ಅಂಶಗಳನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುತ್ತೇನೆ.

• ಎಲ್ಲಾ ಪುಟಗಳನ್ನು "ಸಮಾನ" ಮಾಡಲು ನಿರ್ಧರಿಸಲಾಯಿತು
  ಅಂದರೆ, ಮೆಟಾಡೇಟಾ, ಪ್ರತ್ಯೇಕ ಥ್ರೆಡ್‌ಗಳು ಇತ್ಯಾದಿಗಳೊಂದಿಗೆ ಯಾವುದೇ ವಿಶೇಷ ಪುಟಗಳು ಇರುವುದಿಲ್ಲ, ಬದಲಿಗೆ ಎಲ್ಲಾ ಪುಟಗಳನ್ನು ಪುನಃ ಬರೆಯುವ ಒಂದೇ ಥ್ರೆಡ್.
  ಇದು ಪುಟಗಳಲ್ಲಿ ಸಹ ಧರಿಸುವುದನ್ನು ಖಾತ್ರಿಗೊಳಿಸುತ್ತದೆ, ವೈಫಲ್ಯದ ಯಾವುದೇ ಒಂದು ಅಂಶವಿಲ್ಲ, ಮತ್ತು ನಾನು ಅದನ್ನು ಇಷ್ಟಪಡುತ್ತೇನೆ;
• ಸ್ವರೂಪದ ಆವೃತ್ತಿಯನ್ನು ಒದಗಿಸುವುದು ಕಡ್ಡಾಯವಾಗಿದೆ.
  ಶಿರೋಲೇಖದಲ್ಲಿ ಆವೃತ್ತಿ ಸಂಖ್ಯೆ ಇಲ್ಲದ ಫಾರ್ಮ್ಯಾಟ್ ಕೆಟ್ಟದ್ದಾಗಿದೆ!
  ಪುಟದ ಹೆಡರ್‌ಗೆ ನಿರ್ದಿಷ್ಟ ಮ್ಯಾಜಿಕ್ ಸಂಖ್ಯೆ (ಸಹಿ) ಹೊಂದಿರುವ ಕ್ಷೇತ್ರವನ್ನು ಸೇರಿಸಲು ಸಾಕು, ಅದು ಬಳಸಿದ ಸ್ವರೂಪದ ಆವೃತ್ತಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ (ಆಚರಣೆಯಲ್ಲಿ ಅವುಗಳಲ್ಲಿ ಒಂದು ಡಜನ್ ಕೂಡ ಇರುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುವುದಿಲ್ಲ);
• ದಾಖಲೆಗಳಿಗಾಗಿ ವೇರಿಯಬಲ್-ಉದ್ದದ ಹೆಡರ್ ಅನ್ನು ಬಳಸಿ (ಅದರಲ್ಲಿ ಬಹಳಷ್ಟು ಇವೆ), ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅದನ್ನು 1 ಬೈಟ್ ಉದ್ದವಾಗಿಸಲು ಪ್ರಯತ್ನಿಸುವುದು;
• ಹೆಡರ್‌ನ ಉದ್ದ ಮತ್ತು ಸಂಕುಚಿತ ದಾಖಲೆಯ ಟ್ರಿಮ್ ಮಾಡಿದ ಭಾಗದ ಉದ್ದವನ್ನು ಎನ್‌ಕೋಡ್ ಮಾಡಲು, ವೇರಿಯಬಲ್-ಉದ್ದದ ಬೈನರಿ ಕೋಡ್‌ಗಳನ್ನು ಬಳಸಿ.

ಸಾಕಷ್ಟು ಸಹಾಯ ಮಾಡಿದೆ ಆನ್ಲೈನ್ ​​ಜನರೇಟರ್ ಹಫ್ಮನ್ ಸಂಕೇತಗಳು. ಕೆಲವೇ ನಿಮಿಷಗಳಲ್ಲಿ ನಾವು ಅಗತ್ಯವಿರುವ ವೇರಿಯಬಲ್ ಉದ್ದದ ಕೋಡ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಯಿತು.

ಡೇಟಾ ಶೇಖರಣಾ ಸ್ವರೂಪದ ವಿವರಣೆ

ಬೈಟ್ ಆದೇಶ

ಒಂದು ಬೈಟ್‌ಗಿಂತ ದೊಡ್ಡದಾದ ಕ್ಷೇತ್ರಗಳನ್ನು ದೊಡ್ಡ-ಎಂಡಿಯನ್ ಸ್ವರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ (ನೆಟ್‌ವರ್ಕ್ ಬೈಟ್ ಕ್ರಮ), ಅಂದರೆ, 0x1234 ಅನ್ನು 0x12, 0x34 ಎಂದು ಬರೆಯಲಾಗಿದೆ.

ಪುಟ ವಿನ್ಯಾಸ

ಎಲ್ಲಾ ಫ್ಲಾಶ್ ಮೆಮೊರಿಯನ್ನು ಸಮಾನ ಗಾತ್ರದ ಪುಟಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ.

ಡೀಫಾಲ್ಟ್ ಪುಟದ ಗಾತ್ರವು 32Kb ಆಗಿದೆ, ಆದರೆ ಮೆಮೊರಿ ಚಿಪ್‌ನ ಒಟ್ಟು ಗಾತ್ರದ 1/4 ಕ್ಕಿಂತ ಹೆಚ್ಚಿಲ್ಲ (4MB ಚಿಪ್‌ಗಾಗಿ, 128 ಪುಟಗಳನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ).

ಪ್ರತಿಯೊಂದು ಪುಟವು ಇತರರಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ (ಅಂದರೆ, ಒಂದು ಪುಟದಲ್ಲಿನ ಡೇಟಾವು ಮತ್ತೊಂದು ಪುಟದಲ್ಲಿ ಡೇಟಾವನ್ನು ಉಲ್ಲೇಖಿಸುವುದಿಲ್ಲ).

ಎಲ್ಲಾ ಪುಟಗಳನ್ನು ನೈಸರ್ಗಿಕ ಕ್ರಮದಲ್ಲಿ (ವಿಳಾಸಗಳ ಆರೋಹಣ ಕ್ರಮದಲ್ಲಿ) ಸಂಖ್ಯೆ 0 ರಿಂದ ಪ್ರಾರಂಭಿಸಿ (ಪುಟ ಶೂನ್ಯವು ವಿಳಾಸ 0 ರಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಮೊದಲ ಪುಟವು 32Kb ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಎರಡನೇ ಪುಟವು 64Kb ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಇತ್ಯಾದಿ.)

ಮೆಮೊರಿ ಚಿಪ್ ಅನ್ನು ಸೈಕ್ಲಿಕ್ ಬಫರ್ (ರಿಂಗ್ ಬಫರ್) ಆಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಅಂದರೆ, ಮೊದಲು ಬರವಣಿಗೆ ಪುಟ ಸಂಖ್ಯೆ 0, ನಂತರ ಸಂಖ್ಯೆ 1, ..., ನಾವು ಕೊನೆಯ ಪುಟವನ್ನು ತುಂಬಿದಾಗ, ಹೊಸ ಚಕ್ರವು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಪುಟ ಶೂನ್ಯದಿಂದ ರೆಕಾರ್ಡಿಂಗ್ ಮುಂದುವರಿಯುತ್ತದೆ. .

ಪುಟದ ಒಳಗೆ

ಪುಟದ ಆರಂಭದಲ್ಲಿ, 4-ಬೈಟ್ ಪುಟದ ಹೆಡರ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ನಂತರ ಹೆಡರ್ ಚೆಕ್‌ಸಮ್ (CRC-32C), ನಂತರ ದಾಖಲೆಗಳನ್ನು "ಹೆಡರ್, ಡೇಟಾ, ಚೆಕ್‌ಸಮ್" ಸ್ವರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.

ಪುಟದ ಶೀರ್ಷಿಕೆ (ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಕೊಳಕು ಹಸಿರು) ಇವುಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

• ಎರಡು-ಬೈಟ್ ಮ್ಯಾಜಿಕ್ ಸಂಖ್ಯೆ ಕ್ಷೇತ್ರ (ಸ್ವರೂಪದ ಆವೃತ್ತಿಯ ಸಂಕೇತವೂ ಸಹ)
  ಸ್ವರೂಪದ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಗೆ ಇದನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ 0xed00 ⊕ номер страницы;
• ಎರಡು-ಬೈಟ್ ಕೌಂಟರ್ "ಪುಟ ಆವೃತ್ತಿ" (ಮೆಮೊರಿ ರಿರೈಟ್ ಸೈಕಲ್ ಸಂಖ್ಯೆ).

ಪುಟದಲ್ಲಿನ ನಮೂದುಗಳನ್ನು ಸಂಕುಚಿತ ರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ (ಡಿಫ್ಲೇಟ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ). ಒಂದು ಪುಟದಲ್ಲಿನ ಎಲ್ಲಾ ದಾಖಲೆಗಳನ್ನು ಒಂದು ಥ್ರೆಡ್‌ನಲ್ಲಿ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುತ್ತದೆ (ಸಾಮಾನ್ಯ ನಿಘಂಟನ್ನು ಬಳಸಲಾಗುತ್ತದೆ), ಮತ್ತು ಪ್ರತಿ ಹೊಸ ಪುಟದ ಸಂಕೋಚನವು ಹೊಸದಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಅಂದರೆ, ಯಾವುದೇ ದಾಖಲೆಯನ್ನು ಡಿಕಂಪ್ರೆಸ್ ಮಾಡಲು, ಈ ಪುಟದಿಂದ ಎಲ್ಲಾ ಹಿಂದಿನ ದಾಖಲೆಗಳು (ಮತ್ತು ಇದು ಮಾತ್ರ) ಅಗತ್ಯವಿದೆ.

ಪ್ರತಿಯೊಂದು ದಾಖಲೆಯನ್ನು Z_SYNC_FLUSH ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸಂಕುಚಿತ ಸ್ಟ್ರೀಮ್‌ನ ಕೊನೆಯಲ್ಲಿ 4 ಬೈಟ್‌ಗಳು 0x00, 0x00, 0xff, 0xff ಇರುತ್ತದೆ, ಬಹುಶಃ ಒಂದು ಅಥವಾ ಎರಡು ಹೆಚ್ಚಿನ ಶೂನ್ಯ ಬೈಟ್‌ಗಳಿಂದ ಮುಂಚಿತವಾಗಿರಬಹುದು.
ಫ್ಲ್ಯಾಶ್ ಮೆಮೊರಿಗೆ ಬರೆಯುವಾಗ ನಾವು ಈ ಅನುಕ್ರಮವನ್ನು (4, 5 ಅಥವಾ 6 ಬೈಟ್‌ಗಳು ಉದ್ದ) ತ್ಯಜಿಸುತ್ತೇವೆ.

ರೆಕಾರ್ಡ್ ಹೆಡರ್ 1, 2 ಅಥವಾ 3 ಬೈಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ:

• ಒಂದು ಬಿಟ್ (ಟಿ) ದಾಖಲೆಯ ಪ್ರಕಾರವನ್ನು ಸೂಚಿಸುತ್ತದೆ: 0 - ಸಂದರ್ಭ, 1 - ಲಾಗ್;
• 1 ರಿಂದ 7 ಬಿಟ್‌ಗಳವರೆಗಿನ ವೇರಿಯಬಲ್ ಉದ್ದದ ಕ್ಷೇತ್ರ (S), ಹೆಡರ್‌ನ ಉದ್ದವನ್ನು ಮತ್ತು ಡಿಕಂಪ್ರೆಷನ್‌ಗಾಗಿ ರೆಕಾರ್ಡ್‌ಗೆ ಸೇರಿಸಬೇಕಾದ "ಟೈಲ್" ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ;
• ದಾಖಲೆಯ ಉದ್ದ (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 ಚೆಕ್‌ಸಮ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಇದರಲ್ಲಿ ಹಿಂದಿನ ಚೆಕ್‌ಸಮ್‌ನ ತಲೆಕೆಳಗಾದ ಮೌಲ್ಯವನ್ನು ಆರಂಭಿಕ ಮೌಲ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ (init).

CRC "ಅವಧಿ" ಯ ಆಸ್ತಿಯನ್ನು ಹೊಂದಿದೆ, ಕೆಳಗಿನ ಸೂತ್ರವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಪ್ಲಸ್ ಅಥವಾ ಮೈನಸ್ ಬಿಟ್ ವಿಲೋಮ): .
ಅಂದರೆ, ವಾಸ್ತವವಾಗಿ, ಈ ಪುಟದಲ್ಲಿನ ಹೆಡರ್‌ಗಳು ಮತ್ತು ಡೇಟಾದ ಹಿಂದಿನ ಎಲ್ಲಾ ಬೈಟ್‌ಗಳ CRC ಅನ್ನು ನಾವು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತೇವೆ.

ಚೆಕ್ಸಮ್ ಅನ್ನು ನೇರವಾಗಿ ಅನುಸರಿಸುವುದು ಮುಂದಿನ ದಾಖಲೆಯ ಹೆಡರ್ ಆಗಿದೆ.

ಹೆಡರ್ ಅನ್ನು ಅದರ ಮೊದಲ ಬೈಟ್ ಯಾವಾಗಲೂ 0x00 ಮತ್ತು 0xff ಗಿಂತ ಭಿನ್ನವಾಗಿರುವ ರೀತಿಯಲ್ಲಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ (ಹೆಡರ್‌ನ ಮೊದಲ ಬೈಟ್ ಬದಲಿಗೆ ನಾವು 0xff ಅನ್ನು ಎದುರಿಸಿದರೆ, ಇದರರ್ಥ ಇದು ಬಳಕೆಯಾಗದ ಪ್ರದೇಶವಾಗಿದೆ; 0x00 ದೋಷವನ್ನು ಸಂಕೇತಿಸುತ್ತದೆ).

ಉದಾಹರಣೆ ಅಲ್ಗಾರಿದಮ್ಸ್

ಫ್ಲ್ಯಾಶ್ ಮೆಮೊರಿಯಿಂದ ಓದುವುದು

ಯಾವುದೇ ಓದುವಿಕೆ ಚೆಕ್ಸಮ್ ಚೆಕ್ನೊಂದಿಗೆ ಬರುತ್ತದೆ.
ಚೆಕ್ಸಮ್ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಸರಿಯಾದ ಡೇಟಾವನ್ನು ಓದುವ ಭರವಸೆಯಲ್ಲಿ ಓದುವಿಕೆಯನ್ನು ಹಲವಾರು ಬಾರಿ ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ.

(ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ, ಲಿನಕ್ಸ್ NOR ಫ್ಲ್ಯಾಶ್‌ನಿಂದ ಓದುವಿಕೆಯನ್ನು ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ, ಪರೀಕ್ಷಿಸಲಾಗಿದೆ)

ಫ್ಲಾಶ್ ಮೆಮೊರಿಗೆ ಬರೆಯಿರಿ

ನಾವು ಡೇಟಾವನ್ನು ದಾಖಲಿಸುತ್ತೇವೆ.
ಅವುಗಳನ್ನು ಓದೋಣ.

ಓದುವ ಡೇಟಾವು ಲಿಖಿತ ಡೇಟಾದೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ನಾವು ಪ್ರದೇಶವನ್ನು ಸೊನ್ನೆಗಳೊಂದಿಗೆ ತುಂಬುತ್ತೇವೆ ಮತ್ತು ದೋಷವನ್ನು ಸಂಕೇತಿಸುತ್ತೇವೆ.

ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ಹೊಸ ಮೈಕ್ರೊ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು

ಪ್ರಾರಂಭಕ್ಕಾಗಿ, ಆವೃತ್ತಿ 1 ರೊಂದಿಗಿನ ಹೆಡರ್ ಅನ್ನು ಮೊದಲ (ಅಥವಾ ಬದಲಿಗೆ ಶೂನ್ಯ) ಪುಟಕ್ಕೆ ಬರೆಯಲಾಗುತ್ತದೆ.
ಅದರ ನಂತರ, ಆರಂಭಿಕ ಸಂದರ್ಭವನ್ನು ಈ ಪುಟಕ್ಕೆ ಬರೆಯಲಾಗುತ್ತದೆ (ಯಂತ್ರದ UUID ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ).

ಅಷ್ಟೆ, ಫ್ಲಾಶ್ ಮೆಮೊರಿ ಬಳಕೆಗೆ ಸಿದ್ಧವಾಗಿದೆ.

ಯಂತ್ರವನ್ನು ಲೋಡ್ ಮಾಡಲಾಗುತ್ತಿದೆ

ಲೋಡ್ ಮಾಡುವಾಗ, ಪ್ರತಿ ಪುಟದ ಮೊದಲ 8 ಬೈಟ್‌ಗಳನ್ನು (ಹೆಡರ್ + CRC) ಓದಲಾಗುತ್ತದೆ, ಅಜ್ಞಾತ ಮ್ಯಾಜಿಕ್ ಸಂಖ್ಯೆ ಅಥವಾ ತಪ್ಪಾದ CRC ಹೊಂದಿರುವ ಪುಟಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತದೆ.
"ಸರಿಯಾದ" ಪುಟಗಳಿಂದ, ಗರಿಷ್ಠ ಆವೃತ್ತಿಯೊಂದಿಗೆ ಪುಟಗಳನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಪುಟವನ್ನು ಅವುಗಳಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ.
ಮೊದಲ ದಾಖಲೆಯನ್ನು ಓದಲಾಗುತ್ತದೆ, CRC ಯ ಸರಿಯಾಗಿರುವುದು ಮತ್ತು "ಸಂದರ್ಭ" ಧ್ವಜದ ಉಪಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ. ಎಲ್ಲವೂ ಸರಿಯಾಗಿದ್ದರೆ, ಈ ಪುಟವನ್ನು ಪ್ರಸ್ತುತ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ನಾವು "ಲೈವ್" ಪುಟವನ್ನು ಕಂಡುಕೊಳ್ಳುವವರೆಗೆ ನಾವು ಹಿಂದಿನದಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತೇವೆ.
ಮತ್ತು ಕಂಡುಬರುವ ಪುಟದಲ್ಲಿ ನಾವು ಎಲ್ಲಾ ದಾಖಲೆಗಳನ್ನು ಓದುತ್ತೇವೆ, ನಾವು "ಸಂದರ್ಭ" ಧ್ವಜದೊಂದಿಗೆ ಬಳಸುತ್ತೇವೆ.
zlib ನಿಘಂಟನ್ನು ಉಳಿಸಿ (ಈ ಪುಟಕ್ಕೆ ಸೇರಿಸಲು ಇದು ಅಗತ್ಯವಿದೆ).

ಅದು ಇಲ್ಲಿದೆ, ಡೌನ್‌ಲೋಡ್ ಪೂರ್ಣಗೊಂಡಿದೆ, ಸಂದರ್ಭವನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲಾಗಿದೆ, ನೀವು ಕೆಲಸ ಮಾಡಬಹುದು.

ಜರ್ನಲ್ ನಮೂದನ್ನು ಸೇರಿಸಲಾಗುತ್ತಿದೆ

ನಾವು Z_SYNC_FLUSH ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಮೂಲಕ ಸರಿಯಾದ ನಿಘಂಟಿನೊಂದಿಗೆ ರೆಕಾರ್ಡ್ ಅನ್ನು ಸಂಕುಚಿತಗೊಳಿಸುತ್ತೇವೆ. ಸಂಕುಚಿತ ದಾಖಲೆಯು ಪ್ರಸ್ತುತ ಪುಟದಲ್ಲಿ ಸರಿಹೊಂದುತ್ತದೆಯೇ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ.
ಇದು ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ (ಅಥವಾ ಪುಟದಲ್ಲಿ CRC ದೋಷಗಳಿದ್ದರೆ), ಹೊಸ ಪುಟವನ್ನು ಪ್ರಾರಂಭಿಸಿ (ಕೆಳಗೆ ನೋಡಿ).
ನಾವು ದಾಖಲೆ ಮತ್ತು CRC ಅನ್ನು ಬರೆಯುತ್ತೇವೆ. ದೋಷ ಸಂಭವಿಸಿದಲ್ಲಿ, ಹೊಸ ಪುಟವನ್ನು ಪ್ರಾರಂಭಿಸಿ.

ಹೊಸ ಪುಟ

ನಾವು ಕನಿಷ್ಟ ಸಂಖ್ಯೆಯ ಉಚಿತ ಪುಟವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ (ಉಚಿತ ಪುಟವನ್ನು ಹೆಡರ್‌ನಲ್ಲಿ ತಪ್ಪಾದ ಚೆಕ್‌ಸಮ್ ಅಥವಾ ಪ್ರಸ್ತುತಕ್ಕಿಂತ ಕಡಿಮೆ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿರುವ ಪುಟ ಎಂದು ನಾವು ಪರಿಗಣಿಸುತ್ತೇವೆ). ಅಂತಹ ಯಾವುದೇ ಪುಟಗಳಿಲ್ಲದಿದ್ದರೆ, ಪ್ರಸ್ತುತ ಒಂದಕ್ಕೆ ಸಮಾನವಾದ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿರುವ ಪುಟಗಳಿಂದ ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ ಪುಟವನ್ನು ಆಯ್ಕೆಮಾಡಿ.
ಆಯ್ದ ಪುಟವನ್ನು ನಾವು ಅಳಿಸುತ್ತೇವೆ. ನಾವು 0xff ನೊಂದಿಗೆ ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಏನಾದರೂ ತಪ್ಪಾಗಿದ್ದರೆ, ಮುಂದಿನ ಉಚಿತ ಪುಟವನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಇತ್ಯಾದಿ.
ಅಳಿಸಿದ ಪುಟದಲ್ಲಿ ನಾವು ಹೆಡರ್ ಅನ್ನು ಬರೆಯುತ್ತೇವೆ, ಮೊದಲ ನಮೂದು ಸಂದರ್ಭದ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯಾಗಿದೆ, ಮುಂದಿನದು ಬರೆಯದ ಲಾಗ್ ನಮೂದು (ಒಂದು ಇದ್ದರೆ).

ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ವಯಿಸುವಿಕೆ

ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, NOR ಫ್ಲ್ಯಾಶ್‌ನಲ್ಲಿ ಯಾವುದೇ ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಸಂಕುಚಿತ ಮಾಹಿತಿ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು (ಸಾದಾ ಪಠ್ಯ, JSON, MessagePack, CBOR, ಪ್ರಾಯಶಃ protobuf) ಸಂಗ್ರಹಿಸಲು ಇದು ಉತ್ತಮ ಸ್ವರೂಪವಾಗಿದೆ.

ಸಹಜವಾಗಿ, SLC NOR ಫ್ಲ್ಯಾಶ್‌ಗಾಗಿ ಸ್ವರೂಪವು "ಅನುಗುಣವಾಗಿದೆ".

NAND ಅಥವಾ MLC NOR ನಂತಹ ಹೆಚ್ಚಿನ BER ಮಾಧ್ಯಮದೊಂದಿಗೆ ಇದನ್ನು ಬಳಸಬಾರದು (ಅಂತಹ ಮೆಮೊರಿಯು ಮಾರಾಟಕ್ಕೆ ಲಭ್ಯವಿದೆಯೇ? ತಿದ್ದುಪಡಿ ಕೋಡ್‌ಗಳಲ್ಲಿನ ಕೃತಿಗಳಲ್ಲಿ ಮಾತ್ರ ಇದನ್ನು ಉಲ್ಲೇಖಿಸಿರುವುದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ).

ಇದಲ್ಲದೆ, ಇದನ್ನು ತಮ್ಮದೇ ಆದ ಎಫ್‌ಟಿಎಲ್ ಹೊಂದಿರುವ ಸಾಧನಗಳೊಂದಿಗೆ ಬಳಸಬಾರದು: ಯುಎಸ್‌ಬಿ ಫ್ಲ್ಯಾಷ್, ಎಸ್‌ಡಿ, ಮೈಕ್ರೊ ಎಸ್‌ಡಿ, ಇತ್ಯಾದಿ (ಅಂತಹ ಮೆಮೊರಿಗಾಗಿ ನಾನು 512 ಬೈಟ್‌ಗಳ ಪುಟದ ಗಾತ್ರದೊಂದಿಗೆ ಸ್ವರೂಪವನ್ನು ರಚಿಸಿದ್ದೇನೆ, ಪ್ರತಿ ಪುಟದ ಆರಂಭದಲ್ಲಿ ಸಹಿ ಮತ್ತು ಅನನ್ಯ ದಾಖಲೆ ಸಂಖ್ಯೆಗಳು - ಕೆಲವೊಮ್ಮೆ ಸರಳ ಅನುಕ್ರಮ ಓದುವ ಮೂಲಕ "ಗ್ಲಿಚ್ಡ್" ಫ್ಲ್ಯಾಷ್ ಡ್ರೈವ್‌ನಿಂದ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಮರುಪಡೆಯಲು ಸಾಧ್ಯವಾಯಿತು).

ಕಾರ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿ, 128Kbit (16Kb) ನಿಂದ 1Gbit (128MB) ಗೆ ಫ್ಲಾಶ್ ಡ್ರೈವ್‌ಗಳಲ್ಲಿ ಬದಲಾವಣೆಗಳಿಲ್ಲದೆ ಸ್ವರೂಪವನ್ನು ಬಳಸಬಹುದು. ಬಯಸಿದಲ್ಲಿ, ನೀವು ಅದನ್ನು ದೊಡ್ಡ ಚಿಪ್ಸ್ನಲ್ಲಿ ಬಳಸಬಹುದು, ಆದರೆ ನೀವು ಬಹುಶಃ ಪುಟದ ಗಾತ್ರವನ್ನು ಸರಿಹೊಂದಿಸಬೇಕಾಗಿದೆ (ಆದರೆ ಇಲ್ಲಿ ಆರ್ಥಿಕ ಕಾರ್ಯಸಾಧ್ಯತೆಯ ಪ್ರಶ್ನೆಯು ಈಗಾಗಲೇ ಉದ್ಭವಿಸುತ್ತದೆ; ದೊಡ್ಡ ಪ್ರಮಾಣದ NOR ಫ್ಲ್ಯಾಶ್‌ನ ಬೆಲೆಯು ಪ್ರೋತ್ಸಾಹದಾಯಕವಾಗಿಲ್ಲ).

ಯಾರಾದರೂ ಫಾರ್ಮ್ಯಾಟ್ ಅನ್ನು ಆಸಕ್ತಿದಾಯಕವೆಂದು ಕಂಡುಕೊಂಡರೆ ಮತ್ತು ಅದನ್ನು ತೆರೆದ ಯೋಜನೆಯಲ್ಲಿ ಬಳಸಲು ಬಯಸಿದರೆ, ಬರೆಯಿರಿ, ನಾನು ಸಮಯವನ್ನು ಹುಡುಕಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ, ಕೋಡ್ ಅನ್ನು ಹೊಳಪು ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಗಿಥಬ್‌ನಲ್ಲಿ ಪೋಸ್ಟ್ ಮಾಡುತ್ತೇನೆ.

ತೀರ್ಮಾನಕ್ಕೆ

ನೀವು ನೋಡುವಂತೆ, ಕೊನೆಯಲ್ಲಿ ಸ್ವರೂಪವು ಸರಳವಾಗಿದೆ ಮತ್ತು ನೀರಸ ಕೂಡ.

ಲೇಖನದಲ್ಲಿ ನನ್ನ ದೃಷ್ಟಿಕೋನದ ವಿಕಸನವನ್ನು ಪ್ರತಿಬಿಂಬಿಸುವುದು ಕಷ್ಟ, ಆದರೆ ನನ್ನನ್ನು ನಂಬಿರಿ: ಆರಂಭದಲ್ಲಿ ನಾನು ಅತ್ಯಾಧುನಿಕ, ಅವಿನಾಶವಾದ, ಹತ್ತಿರದಲ್ಲಿ ಪರಮಾಣು ಸ್ಫೋಟವನ್ನು ಸಹ ಬದುಕುಳಿಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ರಚಿಸಲು ಬಯಸಿದ್ದೆ. ಆದಾಗ್ಯೂ, ಕಾರಣ (ನಾನು ಭಾವಿಸುತ್ತೇನೆ) ಇನ್ನೂ ಗೆದ್ದಿದೆ ಮತ್ತು ಕ್ರಮೇಣ ಆದ್ಯತೆಗಳು ಸರಳತೆ ಮತ್ತು ಸಾಂದ್ರತೆಯ ಕಡೆಗೆ ಬದಲಾಯಿತು.

ನಾನು ತಪ್ಪು ಮಾಡಿರಬಹುದು? ಖಂಡಿತವಾಗಿಯೂ. ಉದಾಹರಣೆಗೆ, ನಾವು ಕಡಿಮೆ-ಗುಣಮಟ್ಟದ ಮೈಕ್ರೋ ಸರ್ಕ್ಯೂಟ್‌ಗಳ ಬ್ಯಾಚ್ ಅನ್ನು ಖರೀದಿಸಿದ್ದೇವೆ ಎಂದು ಅದು ತಿರುಗಬಹುದು. ಅಥವಾ ಇತರ ಕಾರಣಗಳಿಗಾಗಿ ಉಪಕರಣಗಳು ವಿಶ್ವಾಸಾರ್ಹತೆಯ ನಿರೀಕ್ಷೆಗಳನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ.

ಇದಕ್ಕಾಗಿ ನನ್ನ ಬಳಿ ಯೋಜನೆ ಇದೆಯೇ? ಲೇಖನವನ್ನು ಓದಿದ ನಂತರ ಯೋಜನೆ ಇದೆ ಎಂದು ನಿಮಗೆ ಯಾವುದೇ ಸಂದೇಹವಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ಮತ್ತು ಒಬ್ಬಂಟಿಯಾಗಿಯೂ ಅಲ್ಲ.

ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಗಂಭೀರವಾದ ಟಿಪ್ಪಣಿಯಲ್ಲಿ, ಸ್ವರೂಪವನ್ನು ಕೆಲಸದ ಆಯ್ಕೆಯಾಗಿ ಮತ್ತು "ಟ್ರಯಲ್ ಬಲೂನ್" ಆಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ.

ಈ ಸಮಯದಲ್ಲಿ ಮೇಜಿನ ಮೇಲಿರುವ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಅಕ್ಷರಶಃ ಇನ್ನೊಂದು ದಿನ ಪರಿಹಾರವನ್ನು ನಿಯೋಜಿಸಲಾಗುವುದು (ಅಂದಾಜು) ನೂರು ಸಾಧನಗಳಲ್ಲಿ, "ಯುದ್ಧ" ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ (ಅದೃಷ್ಟವಶಾತ್, ವೈಫಲ್ಯಗಳನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಪತ್ತೆಹಚ್ಚಲು ಸ್ವರೂಪವು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ; ಆದ್ದರಿಂದ ನೀವು ಪೂರ್ಣ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು). ಕೆಲವು ತಿಂಗಳುಗಳಲ್ಲಿ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ (ಮತ್ತು ನೀವು ದುರದೃಷ್ಟವಂತರಾಗಿದ್ದರೆ, ಮುಂಚೆಯೇ).

ಬಳಕೆಯ ಫಲಿತಾಂಶಗಳ ಆಧಾರದ ಮೇಲೆ, ಗಂಭೀರ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆ ಹಚ್ಚಿದರೆ ಮತ್ತು ಸುಧಾರಣೆಗಳು ಅಗತ್ಯವಿದ್ದರೆ, ನಾನು ಖಂಡಿತವಾಗಿಯೂ ಅದರ ಬಗ್ಗೆ ಬರೆಯುತ್ತೇನೆ.

ಸಾಹಿತ್ಯ

ಬಳಸಿದ ಕೃತಿಗಳ ದೀರ್ಘ ಬೇಸರದ ಪಟ್ಟಿಯನ್ನು ಮಾಡಲು ನಾನು ಬಯಸುವುದಿಲ್ಲ; ಎಲ್ಲಾ ನಂತರ, ಪ್ರತಿಯೊಬ್ಬರೂ Google ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ.

ಇಲ್ಲಿ ನನಗೆ ವಿಶೇಷವಾಗಿ ಆಸಕ್ತಿದಾಯಕವೆಂದು ತೋರುವ ಸಂಶೋಧನೆಗಳ ಪಟ್ಟಿಯನ್ನು ಬಿಡಲು ನಾನು ನಿರ್ಧರಿಸಿದೆ, ಆದರೆ ಕ್ರಮೇಣ ಅವರು ನೇರವಾಗಿ ಲೇಖನದ ಪಠ್ಯಕ್ಕೆ ವಲಸೆ ಹೋದರು ಮತ್ತು ಒಂದು ಐಟಂ ಪಟ್ಟಿಯಲ್ಲಿ ಉಳಿದಿದೆ:

1. ಉಪಯುಕ್ತತೆ infgen ಲೇಖಕ zlib ನಿಂದ. deflate/zlib/gzip ಆರ್ಕೈವ್‌ಗಳ ವಿಷಯಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರದರ್ಶಿಸಬಹುದು. ಡಿಫ್ಲೇಟ್ (ಅಥವಾ ಜಿಜಿಪ್) ಸ್ವರೂಪದ ಆಂತರಿಕ ರಚನೆಯನ್ನು ನೀವು ಎದುರಿಸಬೇಕಾದರೆ, ನಾನು ಅದನ್ನು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.

ಮೂಲ: www.habr.com