ಬಾಳಿಕೆ ಬರುವ ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಲಿನಕ್ಸ್ ಫೈಲ್ API ಗಳು

ಕ್ಲೌಡ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ಸಮರ್ಥನೀಯತೆಯನ್ನು ಸಂಶೋಧಿಸುವಾಗ, ನಾನು ಮೂಲಭೂತ ವಿಷಯಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನನ್ನನ್ನು ಪರೀಕ್ಷಿಸಲು ನಿರ್ಧರಿಸಿದೆ. I NVMe ವಿವರಣೆಯನ್ನು ಓದುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ NMVe ಡಿಸ್ಕ್‌ಗಳಿಂದ ಸುಸ್ಥಿರ ಡೇಟಾ ಸಂಗ್ರಹಣೆಗೆ (ಅಂದರೆ, ಸಿಸ್ಟಮ್ ವೈಫಲ್ಯದ ನಂತರ ಡೇಟಾ ಲಭ್ಯವಾಗುತ್ತದೆ ಎಂದು ಖಾತರಿಪಡಿಸುತ್ತದೆ) ಕುರಿತು ಏನು ಖಾತರಿಪಡಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು. ನಾನು ಈ ಕೆಳಗಿನ ಮುಖ್ಯ ತೀರ್ಮಾನಗಳನ್ನು ಮಾಡಿದ್ದೇನೆ: ಡೇಟಾವನ್ನು ಬರೆಯಲು ಆಜ್ಞೆಯನ್ನು ನೀಡಿದ ಕ್ಷಣದಿಂದ ಶೇಖರಣಾ ಮಾಧ್ಯಮಕ್ಕೆ ಬರೆಯುವ ಕ್ಷಣದವರೆಗೆ ಡೇಟಾವನ್ನು ಹಾನಿಗೊಳಗಾಗುತ್ತದೆ ಎಂದು ಪರಿಗಣಿಸಬೇಕು. ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಪ್ರೋಗ್ರಾಂಗಳು ಡೇಟಾವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಲು ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ಸಾಕಷ್ಟು ಸಂತೋಷದಿಂದ ಬಳಸುತ್ತವೆ.

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

ಒಟ್ಟಾರೆಯಾಗಿ, ಈ ವಸ್ತುವು ನನಗೆ ಆಸಕ್ತಿಯ ವಿಷಯದ ಕುರಿತು ನಾನು ಕಲಿತ ವಿಷಯಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಟಿಪ್ಪಣಿಗಳ ಸಂಗ್ರಹವಾಗಿದೆ. ನಾವು ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ವಿಷಯದ ಬಗ್ಗೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಮಾತನಾಡಿದರೆ, ಸುಸ್ಥಿರ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಸಂಘಟಿಸಲು ನೀವು ಆಜ್ಞೆಯನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. fdatasync() ಅಥವಾ ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ಫೈಲ್‌ಗಳನ್ನು ತೆರೆಯಿರಿ O_DSYNC. ಕೋಡ್‌ನಿಂದ ಡಿಸ್ಕ್‌ಗೆ ಡೇಟಾಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳಲು ನೀವು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ಒಮ್ಮೆ ನೋಡಿ ಇದು ಲೇಖನ.

ಬರಹ() ಕಾರ್ಯವನ್ನು ಬಳಸುವ ವೈಶಿಷ್ಟ್ಯಗಳು

ಸಿಸ್ಟಮ್ ಕರೆ write() ಮಾನದಂಡದಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ IEEE POSIX ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗೆ ಡೇಟಾವನ್ನು ಬರೆಯುವ ಪ್ರಯತ್ನವಾಗಿ. ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಂಡ ನಂತರ write() ಡೇಟಾ ರೀಡ್ ಕಾರ್ಯಾಚರಣೆಗಳು ಹಿಂದೆ ಬರೆದ ಬೈಟ್‌ಗಳನ್ನು ನಿಖರವಾಗಿ ಹಿಂತಿರುಗಿಸಬೇಕು, ಇತರ ಪ್ರಕ್ರಿಯೆಗಳು ಅಥವಾ ಥ್ರೆಡ್‌ಗಳಿಂದ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸಿದರೂ ಸಹ ಇದನ್ನು ಮಾಡುತ್ತವೆ (ನೋಡು POSIX ಮಾನದಂಡದ ಸಂಬಂಧಿತ ವಿಭಾಗ). ಇದು, ಸಾಮಾನ್ಯ ಫೈಲ್ ಕಾರ್ಯಾಚರಣೆಗಳೊಂದಿಗೆ ಥ್ರೆಡ್‌ಗಳು ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ ಎಂಬ ವಿಭಾಗದಲ್ಲಿ, ಎರಡು ಥ್ರೆಡ್‌ಗಳು ಪ್ರತಿಯೊಂದೂ ಈ ಕಾರ್ಯಗಳನ್ನು ಕರೆದರೆ, ಪ್ರತಿ ಕರೆಯು ಇತರ ಕರೆಯ ಎಲ್ಲಾ ಗೊತ್ತುಪಡಿಸಿದ ಪರಿಣಾಮಗಳನ್ನು ನೋಡಬೇಕು ಅಥವಾ ಯಾವುದೂ ಇಲ್ಲ ಎಂದು ಹೇಳುವ ಒಂದು ಟಿಪ್ಪಣಿ ಇದೆ. ಇಲ್ಲ. ಪರಿಣಾಮಗಳು. ಎಲ್ಲಾ ಫೈಲ್ I/O ಕಾರ್ಯಾಚರಣೆಗಳು ಅವರು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಸಂಪನ್ಮೂಲದ ಮೇಲೆ ಲಾಕ್ ಅನ್ನು ಹೊಂದಿರಬೇಕು ಎಂಬ ತೀರ್ಮಾನಕ್ಕೆ ಇದು ಕಾರಣವಾಗುತ್ತದೆ.

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

fsync() ಮತ್ತು fdatasync() ಕಾರ್ಯಗಳು

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

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

ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ವಿಭಿನ್ನ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ ವಿಭಿನ್ನವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ನಾನು ಬಳಸಿದೆ blktrace ext4 ಮತ್ತು XFS ಕಡತ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಯಾವ ಡಿಸ್ಕ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ತಿಳಿಯಲು. ಎರಡೂ ಫೈಲ್ ವಿಷಯಗಳು ಮತ್ತು ಫೈಲ್ ಸಿಸ್ಟಮ್ ಜರ್ನಲ್ ಎರಡಕ್ಕೂ ಡಿಸ್ಕ್‌ಗೆ ನಿಯಮಿತ ಬರಹ ಆಜ್ಞೆಗಳನ್ನು ನೀಡುತ್ತವೆ, ಸಂಗ್ರಹವನ್ನು ಫ್ಲಶ್ ಮಾಡಿ ಮತ್ತು ಜರ್ನಲ್‌ಗೆ ಬರೆಯಲು FUA (ಫೋರ್ಸ್ ಯುನಿಟ್ ಪ್ರವೇಶ, ಡೇಟಾವನ್ನು ನೇರವಾಗಿ ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯುವುದು, ಸಂಗ್ರಹವನ್ನು ಬೈಪಾಸ್ ಮಾಡುವುದು) ಮಾಡುವ ಮೂಲಕ ನಿರ್ಗಮಿಸುತ್ತದೆ. ವಹಿವಾಟು ನಡೆದಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಲು ಅವರು ಬಹುಶಃ ಇದನ್ನು ಮಾಡುತ್ತಾರೆ. FUA ಅನ್ನು ಬೆಂಬಲಿಸದ ಡ್ರೈವ್‌ಗಳಲ್ಲಿ, ಇದು ಎರಡು ಕ್ಯಾಶ್ ಫ್ಲಶ್‌ಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ನನ್ನ ಪ್ರಯೋಗಗಳು ಅದನ್ನು ತೋರಿಸಿದವು fdatasync() ಸ್ವಲ್ಪ ವೇಗವಾಗಿ fsync(). ಉಪಯುಕ್ತತೆ blktrace ಎಂದು ಸೂಚಿಸುತ್ತದೆ fdatasync() ಸಾಮಾನ್ಯವಾಗಿ ಕಡಿಮೆ ಡೇಟಾವನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯುತ್ತದೆ (ext4 ರಲ್ಲಿ fsync() 20 ಕಿಬಿ ಬರೆಯುತ್ತಾರೆ, ಮತ್ತು fdatasync() - 16 ಕಿಬಿ). ಅಲ್ಲದೆ, XFS ext4 ಗಿಂತ ಸ್ವಲ್ಪ ವೇಗವಾಗಿದೆ ಎಂದು ನಾನು ಕಂಡುಕೊಂಡೆ. ಮತ್ತು ಇಲ್ಲಿ ಸಹಾಯದಿಂದ blktrace ಎಂದು ಕಂಡುಹಿಡಿಯುವಲ್ಲಿ ಯಶಸ್ವಿಯಾದರು fdatasync() ಡಿಸ್ಕ್‌ಗೆ ಕಡಿಮೆ ಡೇಟಾವನ್ನು ಫ್ಲಶ್ ಮಾಡುತ್ತದೆ (XFS ನಲ್ಲಿ 4 KiB).

fsync() ಅನ್ನು ಬಳಸುವಾಗ ಉಂಟಾಗುವ ಅಸ್ಪಷ್ಟ ಸಂದರ್ಭಗಳು

ನಾನು ಮೂರು ಅಸ್ಪಷ್ಟ ಸನ್ನಿವೇಶಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಬಹುದು fsync()ನಾನು ಆಚರಣೆಯಲ್ಲಿ ಎದುರಿಸಿದ.

ಅಂತಹ ಮೊದಲ ಪ್ರಕರಣ 2008 ರಲ್ಲಿ ಸಂಭವಿಸಿತು. ನಂತರ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಫೈಲ್‌ಗಳನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಬರೆದರೆ ಫೈರ್‌ಫಾಕ್ಸ್ 3 ಇಂಟರ್ಫೇಸ್ ಫ್ರೀಜ್ ಆಗುತ್ತದೆ. ಸಮಸ್ಯೆಯೆಂದರೆ ಇಂಟರ್ಫೇಸ್ನ ಅನುಷ್ಠಾನವು ಅದರ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು SQLite ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಳಸಿತು. ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸಂಭವಿಸಿದ ಪ್ರತಿ ಬದಲಾವಣೆಯ ನಂತರ, ಕಾರ್ಯವನ್ನು ಕರೆಯಲಾಯಿತು fsync(), ಇದು ಸ್ಥಿರವಾದ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ಉತ್ತಮ ಖಾತರಿಗಳನ್ನು ನೀಡಿತು. ext3 ಕಡತ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನಂತರ ಬಳಸಿದ, ಕಾರ್ಯ fsync() ಸಿಸ್ಟಂನಲ್ಲಿನ ಎಲ್ಲಾ "ಕೊಳಕು" ಪುಟಗಳನ್ನು ಡಿಸ್ಕ್ಗೆ ಎಸೆದರು, ಮತ್ತು ಅನುಗುಣವಾದ ಫೈಲ್ಗೆ ಸಂಬಂಧಿಸಿದವುಗಳಲ್ಲ. ಇದರರ್ಥ ಫೈರ್‌ಫಾಕ್ಸ್‌ನಲ್ಲಿನ ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡುವುದರಿಂದ ಮ್ಯಾಗ್ನೆಟಿಕ್ ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯಲು ಮೆಗಾಬೈಟ್ ಡೇಟಾವನ್ನು ಪ್ರಚೋದಿಸಬಹುದು, ಇದು ಹಲವು ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರ, ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ ಇದು ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗೆ ಕೆಲಸವನ್ನು ಅಸಮಕಾಲಿಕ ಹಿನ್ನೆಲೆ ಕಾರ್ಯಗಳಿಗೆ ವರ್ಗಾಯಿಸಲು ವಸ್ತುವಾಗಿತ್ತು. ಇದರರ್ಥ ಫೈರ್‌ಫಾಕ್ಸ್ ಹಿಂದೆ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಟ್ಟುನಿಟ್ಟಾದ ಶೇಖರಣಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ಜಾರಿಗೆ ತಂದಿದೆ ಮತ್ತು ext3 ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನ ವೈಶಿಷ್ಟ್ಯಗಳು ಈ ಸಮಸ್ಯೆಯನ್ನು ಉಲ್ಬಣಗೊಳಿಸುತ್ತವೆ.

ಎರಡನೇ ಸಮಸ್ಯೆ 2009 ರಲ್ಲಿ ಸಂಭವಿಸಿತು. ನಂತರ, ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್‌ನ ನಂತರ, ಹೊಸ ext4 ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನ ಬಳಕೆದಾರರು ಹೊಸದಾಗಿ ರಚಿಸಲಾದ ಅನೇಕ ಫೈಲ್‌ಗಳು ಶೂನ್ಯ ಉದ್ದವನ್ನು ಹೊಂದಿದ್ದವು ಎಂಬ ಅಂಶವನ್ನು ಎದುರಿಸಬೇಕಾಯಿತು, ಆದರೆ ಇದು ಹಳೆಯ ext3 ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಸಂಭವಿಸಲಿಲ್ಲ. ಹಿಂದಿನ ಪ್ಯಾರಾಗ್ರಾಫ್‌ನಲ್ಲಿ, ext3 ಹೆಚ್ಚು ಡೇಟಾವನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಹೇಗೆ ಫ್ಲಶ್ ಮಾಡಿದೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ಮಾತನಾಡಿದ್ದೇನೆ, ಅದು ವಿಷಯಗಳನ್ನು ಬಹಳಷ್ಟು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ. fsync(). ಪರಿಸ್ಥಿತಿಯನ್ನು ಸುಧಾರಿಸಲು, ext4 ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಫೈಲ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಕೊಳಕು ಪುಟಗಳನ್ನು ಮಾತ್ರ ಡಿಸ್ಕ್‌ಗೆ ಫ್ಲಶ್ ಮಾಡಲಾಗುತ್ತದೆ. ಮತ್ತು ಇತರ ಫೈಲ್‌ಗಳ ಡೇಟಾವು ext3 ಗಿಂತ ಹೆಚ್ಚು ಸಮಯದವರೆಗೆ ಮೆಮೊರಿಯಲ್ಲಿ ಉಳಿಯುತ್ತದೆ. ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಇದನ್ನು ಮಾಡಲಾಗಿದೆ (ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಡೇಟಾವು ಈ ಸ್ಥಿತಿಯಲ್ಲಿ 30 ಸೆಕೆಂಡುಗಳವರೆಗೆ ಇರುತ್ತದೆ, ನೀವು ಇದನ್ನು ಬಳಸಿಕೊಂಡು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು ಡರ್ಟಿ_ಎಕ್ಸ್‌ಪೈರ್_ಸೆಂಟಿಸೆಕ್‌ಗಳು; ಇಲ್ಲಿ ಇದರ ಬಗ್ಗೆ ನೀವು ಹೆಚ್ಚುವರಿ ವಸ್ತುಗಳನ್ನು ಕಾಣಬಹುದು). ಇದರರ್ಥ ವೈಫಲ್ಯದ ನಂತರ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಮರುಪಡೆಯಲಾಗದಂತೆ ಕಳೆದುಕೊಳ್ಳಬಹುದು. ಈ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವನ್ನು ಬಳಸುವುದು fsync() ಸ್ಥಿರವಾದ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಮತ್ತು ವೈಫಲ್ಯಗಳ ಪರಿಣಾಮಗಳಿಂದ ಅವುಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ರಕ್ಷಿಸಲು ಅಗತ್ಯವಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ. ಕಾರ್ಯ fsync() ext4 ಅನ್ನು ಬಳಸುವಾಗ ext3 ಅನ್ನು ಬಳಸುವಾಗ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ವಿಧಾನದ ಅನನುಕೂಲವೆಂದರೆ ಅದರ ಬಳಕೆಯು ಮೊದಲಿನಂತೆ, ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ಸ್ಥಾಪಿಸುವಂತಹ ಕೆಲವು ಕಾರ್ಯಾಚರಣೆಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ. ಇದರ ಬಗ್ಗೆ ವಿವರಗಳನ್ನು ನೋಡಿ ಇಲ್ಲಿ и ಇಲ್ಲಿ.

ಮೂರನೇ ಸಮಸ್ಯೆ ಬಗ್ಗೆ fsync(), 2018 ರಲ್ಲಿ ಹುಟ್ಟಿಕೊಂಡಿತು. ನಂತರ, PostgreSQL ಯೋಜನೆಯ ಚೌಕಟ್ಟಿನೊಳಗೆ, ಕಾರ್ಯವು ಕಂಡುಬಂದರೆ fsync() ದೋಷವನ್ನು ಎದುರಿಸಿದರೆ, ಅದು "ಕೊಳಕು" ಪುಟಗಳನ್ನು "ಕ್ಲೀನ್" ಎಂದು ಗುರುತಿಸುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಕೆಳಗಿನ ಕರೆಗಳು fsync() ಅಂತಹ ಪುಟಗಳೊಂದಿಗೆ ಅವರು ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ಈ ಕಾರಣದಿಂದಾಗಿ, ಮಾರ್ಪಡಿಸಿದ ಪುಟಗಳನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಡಿಸ್ಕ್ಗೆ ಬರೆಯಲಾಗುವುದಿಲ್ಲ. ಇದು ನಿಜವಾದ ವಿಪತ್ತು, ಏಕೆಂದರೆ ಕೆಲವು ಡೇಟಾವನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯಲಾಗಿದೆ ಎಂದು ಅಪ್ಲಿಕೇಶನ್ ಭಾವಿಸುತ್ತದೆ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಅದು ಆಗುವುದಿಲ್ಲ. ಅಂತಹ ವೈಫಲ್ಯಗಳು fsync() ಅಪರೂಪ, ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸಲು ಬಹುತೇಕ ಏನನ್ನೂ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ದಿನಗಳಲ್ಲಿ, ಇದು ಸಂಭವಿಸಿದಾಗ, PostgreSQL ಮತ್ತು ಇತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತವೆ. ಇದು, "ಎಫ್‌ಸಿಂಕ್ ವೈಫಲ್ಯಗಳಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಚೇತರಿಸಿಕೊಳ್ಳಬಹುದೇ?" ಎಂಬ ವಸ್ತುವಿನಲ್ಲಿ, ಈ ಸಮಸ್ಯೆಯನ್ನು ವಿವರವಾಗಿ ಅನ್ವೇಷಿಸಲಾಗಿದೆ. ಪ್ರಸ್ತುತ ಈ ಸಮಸ್ಯೆಗೆ ಉತ್ತಮ ಪರಿಹಾರವೆಂದರೆ ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ಡೈರೆಕ್ಟ್ I/O ಅನ್ನು ಬಳಸುವುದು O_SYNC ಅಥವಾ ಧ್ವಜದೊಂದಿಗೆ O_DSYNC. ಈ ವಿಧಾನದೊಂದಿಗೆ, ನಿರ್ದಿಷ್ಟ ಬರಹ ಕಾರ್ಯಾಚರಣೆಗಳ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸಬಹುದಾದ ದೋಷಗಳನ್ನು ಸಿಸ್ಟಮ್ ವರದಿ ಮಾಡುತ್ತದೆ, ಆದರೆ ಈ ವಿಧಾನಕ್ಕೆ ಬಫರ್‌ಗಳನ್ನು ಸ್ವತಃ ನಿರ್ವಹಿಸಲು ಅಪ್ಲಿಕೇಶನ್ ಅಗತ್ಯವಿದೆ. ಇದರ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ಓದಿ ಇಲ್ಲಿ и ಇಲ್ಲಿ.

O_SYNC ಮತ್ತು O_DSYNC ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಫೈಲ್‌ಗಳನ್ನು ತೆರೆಯಲಾಗುತ್ತಿದೆ

ಸ್ಥಿರವಾದ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಒದಗಿಸುವ Linux ಕಾರ್ಯವಿಧಾನಗಳ ಚರ್ಚೆಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ. ಅವುಗಳೆಂದರೆ, ನಾವು ಧ್ವಜವನ್ನು ಬಳಸುವ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ O_SYNC ಅಥವಾ ಧ್ವಜ O_DSYNC ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಫೈಲ್‌ಗಳನ್ನು ತೆರೆಯುವಾಗ ತೆರೆದ (). ಈ ವಿಧಾನದೊಂದಿಗೆ, ಪ್ರತಿ ಆಜ್ಞೆಯ ನಂತರ ಪ್ರತಿ ಡೇಟಾ ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ write() ವ್ಯವಸ್ಥೆಗೆ ಅನುಗುಣವಾಗಿ ಆಜ್ಞೆಗಳನ್ನು ನೀಡಲಾಗುತ್ತದೆ fsync() и fdatasync(). ದಿ POSIX ವಿಶೇಷಣಗಳು ಇದನ್ನು "ಸಿಂಕ್ರೊನೈಸ್ಡ್ I/O ಫೈಲ್ ಇಂಟೆಗ್ರಿಟಿ ಕಂಪ್ಲೀಷನ್" ಮತ್ತು "ಡೇಟಾ ಇಂಟೆಗ್ರಿಟಿ ಕಂಪ್ಲೀಷನ್" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಈ ವಿಧಾನದ ಮುಖ್ಯ ಪ್ರಯೋಜನವೆಂದರೆ ಡೇಟಾ ಸಮಗ್ರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನೀವು ಎರಡಕ್ಕಿಂತ ಒಂದು ಸಿಸ್ಟಮ್ ಕರೆಯನ್ನು ಮಾತ್ರ ಮಾಡಬೇಕಾಗಿದೆ (ಉದಾಹರಣೆಗೆ - write() и fdatasync()) ಈ ವಿಧಾನದ ಮುಖ್ಯ ಅನನುಕೂಲವೆಂದರೆ ಅನುಗುಣವಾದ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲಾ ಬರಹಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ, ಇದು ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು ರಚಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ.

O_DIRECT ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ಡೈರೆಕ್ಟ್ I/O ಅನ್ನು ಬಳಸುವುದು

ಸಿಸ್ಟಮ್ ಕರೆ open() ಧ್ವಜವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ O_DIRECT, ಇದು ಡಿಸ್ಕ್ನೊಂದಿಗೆ ನೇರವಾಗಿ ಸಂವಹನ ಮಾಡುವ ಮೂಲಕ I/O ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಸಂಗ್ರಹವನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಇದು, ಅನೇಕ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಪ್ರೋಗ್ರಾಂನಿಂದ ನೀಡಲಾದ ಬರೆಯುವ ಆಜ್ಞೆಗಳನ್ನು ನೇರವಾಗಿ ಡಿಸ್ಕ್ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಗುರಿಯನ್ನು ಹೊಂದಿರುವ ಆಜ್ಞೆಗಳಿಗೆ ಅನುವಾದಿಸಲಾಗುತ್ತದೆ ಎಂದರ್ಥ. ಆದರೆ, ಸಾಮಾನ್ಯವಾಗಿ, ಈ ಕಾರ್ಯವಿಧಾನವು ಕಾರ್ಯಗಳಿಗೆ ಬದಲಿಯಾಗಿಲ್ಲ fsync() ಅಥವಾ fdatasync(). ವಾಸ್ತವವೆಂದರೆ ಡಿಸ್ಕ್ ಸ್ವತಃ ಮಾಡಬಹುದು ಮುಂದೂಡಿಕೆ ಅಥವಾ ಸಂಗ್ರಹ ಅನುಗುಣವಾದ ಡೇಟಾ ಬರವಣಿಗೆ ಆಜ್ಞೆಗಳು. ಮತ್ತು, ವಿಷಯಗಳನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸಲು, ಕೆಲವು ವಿಶೇಷ ಸಂದರ್ಭಗಳಲ್ಲಿ ಧ್ವಜವನ್ನು ಬಳಸುವಾಗ I/O ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ O_DIRECT, ಪ್ರಸಾರ ಸಾಂಪ್ರದಾಯಿಕ ಬಫರ್ ಕಾರ್ಯಾಚರಣೆಗಳಲ್ಲಿ. ಫೈಲ್‌ಗಳನ್ನು ತೆರೆಯಲು ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಬಳಸುವುದು ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗವಾಗಿದೆ O_DSYNC, ಇದರರ್ಥ ಪ್ರತಿ ಬರವಣಿಗೆಯ ಕಾರ್ಯಾಚರಣೆಯು ಕರೆಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ fdatasync().

XFS ಫೈಲ್ ಸಿಸ್ಟಮ್ ಇತ್ತೀಚೆಗೆ "ಫಾಸ್ಟ್ ಪಾತ್" ಅನ್ನು ಸೇರಿಸಿದೆ ಎಂದು ಅದು ಬದಲಾಯಿತು O_DIRECT|O_DSYNC- ಡೇಟಾ ರೆಕಾರ್ಡಿಂಗ್. ಬಳಸಿ ಬ್ಲಾಕ್ ಅನ್ನು ಪುನಃ ಬರೆಯಲಾಗಿದ್ದರೆ O_DIRECT|O_DSYNC, ನಂತರ XFS, ಸಂಗ್ರಹವನ್ನು ಫ್ಲಶ್ ಮಾಡುವ ಬದಲು, ಸಾಧನವು ಅದನ್ನು ಬೆಂಬಲಿಸಿದರೆ FUA ಬರೆಯುವ ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಉಪಯುಕ್ತತೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನಾನು ಇದನ್ನು ಪರಿಶೀಲಿಸಿದ್ದೇನೆ blktrace Linux 5.4/Ubuntu 20.04 ವ್ಯವಸ್ಥೆಯಲ್ಲಿ. ಈ ವಿಧಾನವು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿರಬೇಕು, ಏಕೆಂದರೆ ಬಳಸಿದಾಗ, ಕನಿಷ್ಠ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಎರಡು (ಸಂಗ್ರಹವನ್ನು ಬರೆಯುವುದು ಮತ್ತು ಫ್ಲಶ್ ಮಾಡುವುದು) ಬದಲಿಗೆ ಒಂದು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ನಾನು ಲಿಂಕ್ ಅನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ ಪ್ಯಾಚ್ 2018 ಕರ್ನಲ್, ಇದು ಈ ಕಾರ್ಯವಿಧಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಇತರ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಈ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅನ್ನು ಅನ್ವಯಿಸುವ ಕುರಿತು ಕೆಲವು ಚರ್ಚೆಗಳಿವೆ, ಆದರೆ ನನಗೆ ತಿಳಿದಿರುವಂತೆ, XFS ಇದು ಇಲ್ಲಿಯವರೆಗೆ ಬೆಂಬಲಿಸುವ ಏಕೈಕ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಆಗಿದೆ.

sync_file_range() ಕಾರ್ಯ

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

ಡೇಟಾ ನಿರಂತರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುವ ಸಿಸ್ಟಮ್ ಕರೆಗಳು

ಡೇಟಾ ನಿರಂತರತೆಯನ್ನು ಖಚಿತಪಡಿಸುವ I/O ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಮೂರು ವಿಧಾನಗಳನ್ನು ಬಳಸಬಹುದೆಂದು ನಾನು ತೀರ್ಮಾನಕ್ಕೆ ಬಂದಿದ್ದೇನೆ. ಅವರೆಲ್ಲರಿಗೂ ಫಂಕ್ಷನ್ ಕರೆ ಅಗತ್ಯವಿರುತ್ತದೆ fsync() ಫೈಲ್ ಅನ್ನು ರಚಿಸಲಾದ ಡೈರೆಕ್ಟರಿಗಾಗಿ. ಇವುಗಳು ವಿಧಾನಗಳು:

1. ಫಂಕ್ಷನ್ ಕರೆ fdatasync() ಅಥವಾ fsync() ಕಾರ್ಯದ ನಂತರ write() (ಬಳಸುವುದು ಉತ್ತಮ fdatasync()).
2. ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ತೆರೆಯಲಾದ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು O_DSYNC ಅಥವಾ O_SYNC (ಉತ್ತಮ - ಧ್ವಜದೊಂದಿಗೆ O_DSYNC).
3. ಕಮಾಂಡ್ ಬಳಕೆ pwritev2() ಧ್ವಜದೊಂದಿಗೆ RWF_DSYNC ಅಥವಾ RWF_SYNC (ಮೇಲಾಗಿ ಧ್ವಜದೊಂದಿಗೆ RWF_DSYNC).

ಕಾರ್ಯಕ್ಷಮತೆಯ ಟಿಪ್ಪಣಿಗಳು

ನಾನು ಪರೀಕ್ಷಿಸಿದ ವಿವಿಧ ಕಾರ್ಯವಿಧಾನಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನಾನು ಎಚ್ಚರಿಕೆಯಿಂದ ಅಳತೆ ಮಾಡಿಲ್ಲ. ಅವರ ಕೆಲಸದ ವೇಗದಲ್ಲಿ ನಾನು ಗಮನಿಸಿದ ವ್ಯತ್ಯಾಸಗಳು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ. ಇದರರ್ಥ ನಾನು ತಪ್ಪಾಗಿರಬಹುದು ಮತ್ತು ವಿಭಿನ್ನ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಒಂದೇ ವಿಷಯವು ವಿಭಿನ್ನ ಫಲಿತಾಂಶಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಮೊದಲಿಗೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಏನು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ಮಾತನಾಡುತ್ತೇನೆ ಮತ್ತು ನಂತರ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕಡಿಮೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.

1. ಫೈಲ್ ಡೇಟಾವನ್ನು ಓವರ್‌ರೈಟ್ ಮಾಡುವುದು ಫೈಲ್‌ಗೆ ಡೇಟಾವನ್ನು ಸೇರಿಸುವುದಕ್ಕಿಂತ ವೇಗವಾಗಿರುತ್ತದೆ (ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಪ್ರಯೋಜನವು 2-100% ಆಗಿರಬಹುದು). ಫೈಲ್‌ಗೆ ಡೇಟಾವನ್ನು ಸೇರಿಸಲು ಸಿಸ್ಟಮ್ ಕರೆ ಮಾಡಿದ ನಂತರವೂ ಫೈಲ್‌ನ ಮೆಟಾಡೇಟಾದಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಬದಲಾವಣೆಗಳ ಅಗತ್ಯವಿದೆ fallocate(), ಆದರೆ ಈ ಪರಿಣಾಮದ ಪ್ರಮಾಣವು ಬದಲಾಗಬಹುದು. ಉತ್ತಮ ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ, ಕರೆ ಮಾಡಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ fallocate() ಅಗತ್ಯವಿರುವ ಜಾಗವನ್ನು ಮುಂಚಿತವಾಗಿ ನಿಯೋಜಿಸಲು. ನಂತರ ಈ ಜಾಗವನ್ನು ಸೊನ್ನೆಗಳಿಂದ ಸ್ಪಷ್ಟವಾಗಿ ತುಂಬಬೇಕು ಮತ್ತು ಕರೆಯಬೇಕು fsync(). ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿನ ಅನುಗುಣವಾದ ಬ್ಲಾಕ್‌ಗಳನ್ನು "ಹಂಚಿಕೊಳ್ಳದ" ಬದಲಿಗೆ "ಹಂಚಿಕೆ" ಎಂದು ಗುರುತಿಸಲಾಗಿದೆ ಎಂದು ಇದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಇದು ಸಣ್ಣ (ಸುಮಾರು 2%) ಕಾರ್ಯಕ್ಷಮತೆಯ ಸುಧಾರಣೆಯನ್ನು ನೀಡುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕೆಲವು ಡಿಸ್ಕ್ಗಳು ​​ಇತರರಿಗಿಂತ ಒಂದು ಬ್ಲಾಕ್ಗೆ ನಿಧಾನವಾದ ಮೊದಲ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರಬಹುದು. ಅಂದರೆ ಶೂನ್ಯಗಳೊಂದಿಗೆ ಜಾಗವನ್ನು ತುಂಬುವುದರಿಂದ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಗಮನಾರ್ಹ (ಸುಮಾರು 100%) ಸುಧಾರಣೆಗೆ ಕಾರಣವಾಗಬಹುದು. ನಿರ್ದಿಷ್ಟವಾಗಿ, ಇದು ಡಿಸ್ಕ್ಗಳೊಂದಿಗೆ ಸಂಭವಿಸಬಹುದು AWS EBS (ಇದು ಅನಧಿಕೃತ ಡೇಟಾ, ನಾನು ಅದನ್ನು ಖಚಿತಪಡಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ). ಶೇಖರಣೆಗೂ ಅದೇ ಹೋಗುತ್ತದೆ ಜಿಸಿಪಿ ಪರ್ಸಿಸ್ಟೆಂಟ್ ಡಿಸ್ಕ್ (ಮತ್ತು ಇದು ಈಗಾಗಲೇ ಅಧಿಕೃತ ಮಾಹಿತಿಯಾಗಿದೆ, ಪರೀಕ್ಷೆಗಳಿಂದ ದೃಢೀಕರಿಸಲ್ಪಟ್ಟಿದೆ). ಇತರ ತಜ್ಞರು ಅದೇ ರೀತಿ ಮಾಡಿದ್ದಾರೆ ವೀಕ್ಷಣೆ, ವಿವಿಧ ಡಿಸ್ಕ್ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದೆ.
2. ಕಡಿಮೆ ಸಿಸ್ಟಮ್ ಕರೆಗಳು, ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆ (ಲಾಭವು ಸುಮಾರು 5% ಆಗಿರಬಹುದು). ಒಂದು ಸವಾಲಿನಂತೆ ಕಾಣುತ್ತದೆ open() ಧ್ವಜದೊಂದಿಗೆ O_DSYNC ಅಥವಾ ಕರೆ ಮಾಡಿ pwritev2() ಧ್ವಜದೊಂದಿಗೆ RWF_SYNC ಕರೆಗಿಂತ ವೇಗವಾಗಿ fdatasync(). ಒಂದೇ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಕಡಿಮೆ ಸಿಸ್ಟಮ್ ಕರೆಗಳನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ (ಎರಡರ ಬದಲಿಗೆ ಒಂದು ಕರೆ) ಈ ವಿಧಾನವು ಒಂದು ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ ಎಂದು ನಾನು ಅನುಮಾನಿಸುತ್ತೇನೆ. ಆದರೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ವ್ಯತ್ಯಾಸವು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ, ಆದ್ದರಿಂದ ನೀವು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸಬಹುದು ಮತ್ತು ಅದರ ತರ್ಕವನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸದ ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಬಳಸಬಹುದು.

ಸುಸ್ಥಿರ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ವಿಷಯದಲ್ಲಿ ನೀವು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದರೆ, ಇಲ್ಲಿ ಕೆಲವು ಉಪಯುಕ್ತ ವಸ್ತುಗಳು:

• I/O ಪ್ರವೇಶ ವಿಧಾನಗಳು - ಇನ್‌ಪುಟ್/ಔಟ್‌ಪುಟ್ ಕಾರ್ಯವಿಧಾನಗಳ ಮೂಲಭೂತ ಅವಲೋಕನ.
• ಡೇಟಾ ಡಿಸ್ಕ್ ತಲುಪುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು — ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಡಿಸ್ಕ್‌ಗೆ ಹೋಗುವ ದಾರಿಯಲ್ಲಿ ಡೇಟಾಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಒಂದು ಕಥೆ.
• ನೀವು ಹೊಂದಿರುವ ಡೈರೆಕ್ಟರಿಯನ್ನು ಯಾವಾಗ fsync ಮಾಡಬೇಕು - ಯಾವಾಗ ಬಳಸಬೇಕು ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರ fsync() ಡೈರೆಕ್ಟರಿಗಳಿಗಾಗಿ. ಇದನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ಹೊಸ ಫೈಲ್ ಅನ್ನು ರಚಿಸುವಾಗ ನೀವು ಇದನ್ನು ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ ಮತ್ತು ಈ ಶಿಫಾರಸುಗೆ ಕಾರಣವೆಂದರೆ ಲಿನಕ್ಸ್ನಲ್ಲಿ ಒಂದೇ ಫೈಲ್ಗೆ ಹಲವು ಉಲ್ಲೇಖಗಳು ಇರಬಹುದು.
• Linux ನಲ್ಲಿ SQL ಸರ್ವರ್: FUA ಇಂಟರ್ನಲ್ಸ್ — Linux ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ SQL ಸರ್ವರ್‌ನಲ್ಲಿ ನಿರಂತರ ಡೇಟಾ ಸಂಗ್ರಹಣೆಯನ್ನು ಹೇಗೆ ಅಳವಡಿಸಲಾಗಿದೆ ಎಂಬುದರ ವಿವರಣೆ ಇಲ್ಲಿದೆ. ಇಲ್ಲಿ ವಿಂಡೋಸ್ ಮತ್ತು ಲಿನಕ್ಸ್ ಸಿಸ್ಟಮ್ ಕರೆಗಳ ನಡುವೆ ಕೆಲವು ಆಸಕ್ತಿದಾಯಕ ಹೋಲಿಕೆಗಳಿವೆ. XFS ನ FUA ಆಪ್ಟಿಮೈಸೇಶನ್ ಕುರಿತು ನಾನು ಕಲಿತ ಈ ವಸ್ತುವಿಗೆ ಧನ್ಯವಾದಗಳು ಎಂದು ನನಗೆ ಬಹುತೇಕ ಖಚಿತವಾಗಿದೆ.

ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಸುರಕ್ಷಿತವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ಭಾವಿಸಿದ ಡೇಟಾವನ್ನು ನೀವು ಕಳೆದುಕೊಂಡಿದ್ದೀರಾ?

ಮೂಲ: www.habr.com