Reiser4 ಫೈಲ್ ಸಿಸ್ಟಂನ ಡೆವಲಪರ್ ಎಡ್ವರ್ಡ್ ಶಿಶ್ಕಿನ್ ಅವರೊಂದಿಗಿನ ಎರಡನೇ ಸಂದರ್ಶನವನ್ನು ಪ್ರಕಟಿಸಲಾಗಿದೆ.
ಪ್ರಾರಂಭಿಸಲು, ದಯವಿಟ್ಟು ನೀವು ಎಲ್ಲಿ ಮತ್ತು ಯಾರಿಗಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂದು ಓದುಗರಿಗೆ ನೆನಪಿಸಿ.
ನಾನು ಜರ್ಮನ್ ಸಂಶೋಧನಾ ಕೇಂದ್ರದ ಹುವಾವೇ ಟೆಕ್ನಾಲಜೀಸ್‌ನಲ್ಲಿ ಪ್ರಧಾನ ಶೇಖರಣಾ ವಾಸ್ತುಶಿಲ್ಪಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದೇನೆ. ವರ್ಚುವಲೈಸೇಶನ್ ವಿಭಾಗದಲ್ಲಿ ನಾನು ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ವಿವಿಧ ಅಂಶಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತೇನೆ. ನನ್ನ ಚಟುವಟಿಕೆಗಳು ನಿರ್ದಿಷ್ಟ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ಗೆ ಸಂಬಂಧಿಸಿಲ್ಲ.
ನೀವು ಪ್ರಸ್ತುತ ಮುಖ್ಯ ಕರ್ನಲ್ ಶಾಖೆಗೆ ಬದ್ಧರಾಗಿದ್ದೀರಾ?
ಬಹಳ ವಿರಳವಾಗಿ, ಮತ್ತು ನನ್ನ ಉದ್ಯೋಗದಾತರಿಗೆ ಅದು ಅಗತ್ಯವಿದ್ದರೆ ಮಾತ್ರ. ಕೊನೆಯ ಬಾರಿಗೆ ಸುಮಾರು ಮೂರು ವರ್ಷಗಳ ಹಿಂದೆ, 9p ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಲಾದ ಸಂಗ್ರಹಣೆಗಾಗಿ ಥ್ರೋಪುಟ್ ಅನ್ನು ಹೆಚ್ಚಿಸಲು ನಾನು ಪ್ಯಾಚ್‌ಗಳನ್ನು ಕಳುಹಿಸಿದೆ (ಈ ವ್ಯಾಪಾರದ ಇನ್ನೊಂದು ಹೆಸರು VirtFS). ಇಲ್ಲಿ ಒಂದು ಪ್ರಮುಖ ಟಿಪ್ಪಣಿಯನ್ನು ಮಾಡಬೇಕು: ನಾನು ಲಿನಕ್ಸ್‌ನೊಂದಿಗೆ ದೀರ್ಘಕಾಲ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೂ, ನಾನು ಎಂದಿಗೂ ಅದರ ಅಭಿಮಾನಿಯಾಗಿರಲಿಲ್ಲ, ಅಂದರೆ, ನಾನು ಎಲ್ಲದರಂತೆಯೇ “ಸಮವಾಗಿ ಉಸಿರಾಡುತ್ತೇನೆ”. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ನಾನು ನ್ಯೂನತೆಯನ್ನು ಗಮನಿಸಿದರೆ, ನಾನು ಅದನ್ನು ಒಮ್ಮೆ ಸೂಚಿಸಬಹುದು. ಮತ್ತು ಆದ್ದರಿಂದ ನೀವು ಯಾರನ್ನಾದರೂ ಅನುಸರಿಸಬಹುದು ಮತ್ತು ಅವರನ್ನು ಮನವೊಲಿಸಬಹುದು - ಇದು ಸಂಭವಿಸುವುದಿಲ್ಲ.
ಕಳೆದ ಬಾರಿ, ಹತ್ತು ವರ್ಷಗಳ ಹಿಂದೆ, ನೀವು ಕರ್ನಲ್ ಅಭಿವೃದ್ಧಿ ಶೈಲಿಯನ್ನು ಸಾಕಷ್ಟು ಟೀಕಿಸಿದ್ದೀರಿ ಎಂದು ನನಗೆ ನೆನಪಿದೆ. ನಿಮ್ಮ (ಅಥವಾ ಬಹುಶಃ ಕಾರ್ಪೊರೇಟ್) ದೃಷ್ಟಿಕೋನದಿಂದ, ಏನಾದರೂ ಬದಲಾಗಿದೆಯೇ, ಸಮುದಾಯವು ಹೆಚ್ಚು ಸ್ಪಂದಿಸುತ್ತಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ? ಇಲ್ಲದಿದ್ದರೆ, ಯಾರನ್ನು ದೂರುವುದು ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಿ?
ಉತ್ತಮವಾದ ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ನಾನು ನೋಡಿಲ್ಲ. ಸಮುದಾಯದ ಮುಖ್ಯ ಸಮಸ್ಯೆಯೆಂದರೆ ವಿಜ್ಞಾನವನ್ನು ರಾಜಕೀಯ ತಂತ್ರಜ್ಞಾನಗಳು, ವೈಯಕ್ತಿಕ ಸಂಬಂಧಗಳು, ಬಹುಮತದ ಅಭಿಪ್ರಾಯ, ಜನಪ್ರಿಯತೆ, "ಆಂತರಿಕ ಧ್ವನಿಗಳು," ಕೊಳೆತ ರಾಜಿಗಳಿಂದ ಸಲಹೆ, ವಿಜ್ಞಾನವನ್ನು ಹೊರತುಪಡಿಸಿ ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಬದಲಿಸುವುದು. ಕಂಪ್ಯೂಟರ್ ಸೈನ್ಸ್, ಒಬ್ಬರು ಏನು ಹೇಳಿದರೂ, ಮೊದಲ ಮತ್ತು ಅಗ್ರಗಣ್ಯವಾಗಿ ನಿಖರವಾದ ವಿಜ್ಞಾನವಾಗಿದೆ. ಮತ್ತು ಯಾರಾದರೂ 2x2 ಗಾಗಿ ತಮ್ಮದೇ ಆದ ಮೌಲ್ಯವನ್ನು ಘೋಷಿಸಲು ಪ್ರಾರಂಭಿಸಿದರೆ, 4 ಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿ, “ಲಿನಕ್ಸ್ ವೇ” ಫ್ಲ್ಯಾಗ್ ಅಡಿಯಲ್ಲಿ ಅಥವಾ ಇತರ ಫ್ಲ್ಯಾಗ್ ಅಡಿಯಲ್ಲಿ, ಇದು ಹಾನಿಯನ್ನು ಹೊರತುಪಡಿಸಿ ಬೇರೆ ಯಾವುದನ್ನೂ ತರಲು ಅಸಂಭವವಾಗಿದೆ.
ಎಲ್ಲಾ ತೊಂದರೆಗಳು ಪ್ರಾಥಮಿಕವಾಗಿ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವವರ ಅಸಮರ್ಥತೆ ಮತ್ತು ಶಿಕ್ಷಣದ ಕೊರತೆಯಿಂದಾಗಿ. ವ್ಯವಸ್ಥಾಪಕರು ಅಸಮರ್ಥರಾಗಿದ್ದರೆ, ಅವರು ವಸ್ತುನಿಷ್ಠ, ಸಮರ್ಪಕ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಅವನೂ ಸಂಸ್ಕಾರಹೀನನಾಗಿದ್ದರೆ, ಅವನಿಗೆ ಸರಿಯಾದ ಸಲಹೆಯನ್ನು ನೀಡುವ ಸಮರ್ಥ ತಜ್ಞರನ್ನು ಹುಡುಕಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ, "ತೋರಿಕೆಯಲ್ಲಿ ಸರಿಯಾದ ವಿಷಯಗಳು" ಎಂದು ಹೇಳುವ ಸ್ಕ್ಯಾಮರ್ ಮೇಲೆ ಆಯ್ಕೆಯು ಬೀಳುತ್ತದೆ. ಅಸಮರ್ಥ ಏಕಾಂಗಿ ನಾಯಕರ ಸುತ್ತ ಯಾವಾಗಲೂ ಭ್ರಷ್ಟ ವಾತಾವರಣ ಬೆಳೆಯುತ್ತದೆ. ಇದಲ್ಲದೆ, ಈ ವಿಷಯದಲ್ಲಿ ಇತಿಹಾಸವು ಯಾವುದೇ ವಿನಾಯಿತಿಗಳನ್ನು ತಿಳಿದಿಲ್ಲ, ಮತ್ತು ಸಮುದಾಯವು ಇದರ ಸ್ಪಷ್ಟವಾದ ದೃಢೀಕರಣವಾಗಿದೆ.
Btrfs ಅಭಿವೃದ್ಧಿಯಲ್ಲಿನ ಪ್ರಗತಿಯನ್ನು ನೀವು ಹೇಗೆ ನಿರ್ಣಯಿಸುತ್ತೀರಿ? ಈ FS ಬಾಲ್ಯದ ಕಾಯಿಲೆಗಳಿಂದ ಮುಕ್ತಿ ಪಡೆದಿದೆಯೇ? ನೀವು ಅದನ್ನು ನಿಮಗಾಗಿ ಹೇಗೆ ಇರಿಸುತ್ತೀರಿ - FS "ಮನೆಗಾಗಿ" ಅಥವಾ ಕಾರ್ಪೊರೇಟ್ ಬಳಕೆಗಾಗಿಯೂ?
ನಾನು ಅದನ್ನು ತೊಡೆದುಹಾಕಲಿಲ್ಲ. ನಾನು 11 ವರ್ಷಗಳ ಹಿಂದೆ ಹೇಳಿದ ಎಲ್ಲವೂ ಇಂದಿಗೂ ಪ್ರಸ್ತುತವಾಗಿದೆ. ಬಿಟಿಆರ್‌ಎಫ್‌ಗಳೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳಲ್ಲೊಂದು ಇದು ಗಂಭೀರ ಅಗತ್ಯಗಳಿಗೆ ಸೂಕ್ತವಲ್ಲದ ಸ್ಥಳವಾಗಿದೆ. ಯಾವುದೇ ಇತರ ಎಫ್‌ಎಸ್‌ಗಳು ವಿಭಜನೆಯಲ್ಲಿ ಸಾಕಷ್ಟು ಮುಕ್ತ ಸ್ಥಳವನ್ನು ತೋರಿಸುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಹೊಸ ಡಿಸ್ಕ್ಗಾಗಿ ಅಂಗಡಿಗೆ ಓಡಲು ಬಳಕೆದಾರರನ್ನು ಕೇಳಲಾಗುತ್ತದೆ ಎಂಬ ಅಂಶದ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡುವುದಿಲ್ಲ. ಮುಕ್ತ ಸ್ಥಳಾವಕಾಶದ ಕೊರತೆಯಿಂದಾಗಿ ತಾರ್ಕಿಕ ಪರಿಮಾಣದಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಅಸಮರ್ಥತೆ ಕೂಡ ಕೆಟ್ಟ ವಿಷಯವಲ್ಲ. ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ, ಅನಪೇಕ್ಷಿತ ಬಳಕೆದಾರರು ಯಾವಾಗಲೂ, ಯಾವುದೇ ಡಿಸ್ಕ್ ಕೋಟಾಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡಬಹುದು, ಸಾಕಷ್ಟು ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಮುಕ್ತ ಜಾಗವನ್ನು ಎಲ್ಲರಿಗೂ ವಂಚಿಸಬಹುದು.
ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ (ಲಿನಕ್ಸ್ ಕರ್ನಲ್ 5.12 ಗಾಗಿ ಪರೀಕ್ಷಿಸಲಾಗಿದೆ). ಹೊಸದಾಗಿ ಸ್ಥಾಪಿಸಲಾದ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ, ಇದು ಲೂಪ್‌ನಲ್ಲಿ ಹೋಮ್ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಕೆಲವು ಹೆಸರುಗಳೊಂದಿಗೆ ಫೈಲ್ಗಳನ್ನು ರಚಿಸುತ್ತದೆ, ಕೆಲವು ಆಫ್‌ಸೆಟ್‌ಗಳಲ್ಲಿ ಅವರಿಗೆ ಡೇಟಾವನ್ನು ಬರೆಯುತ್ತದೆ ಮತ್ತು ನಂತರ ಈ ಫೈಲ್ಗಳನ್ನು ಅಳಿಸುತ್ತದೆ. ಈ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರನ್ ಮಾಡಿದ ಒಂದು ನಿಮಿಷದ ನಂತರ, ಅಸಾಮಾನ್ಯ ಏನೂ ಸಂಭವಿಸುವುದಿಲ್ಲ. ಐದು ನಿಮಿಷಗಳ ನಂತರ, ವಿಭಾಗದ ಮೇಲೆ ಆಕ್ರಮಿತ ಜಾಗದ ಭಾಗವು ಸ್ವಲ್ಪ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಎರಡು ಮೂರು ಗಂಟೆಗಳ ನಂತರ ಅದು 50% ತಲುಪುತ್ತದೆ (15% ಆರಂಭಿಕ ಮೌಲ್ಯದೊಂದಿಗೆ). ಮತ್ತು ಐದು ಅಥವಾ ಆರು ಗಂಟೆಗಳ ಕೆಲಸದ ನಂತರ, ಸ್ಕ್ರಿಪ್ಟ್ "ವಿಭಜನೆಯಲ್ಲಿ ಯಾವುದೇ ಮುಕ್ತ ಸ್ಥಳವಿಲ್ಲ" ಎಂಬ ದೋಷದೊಂದಿಗೆ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ. ಇದರ ನಂತರ, ನಿಮ್ಮ ವಿಭಾಗಕ್ಕೆ 4K ಫೈಲ್ ಅನ್ನು ಬರೆಯಲು ನಿಮಗೆ ಇನ್ನು ಮುಂದೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ಆಸಕ್ತಿದಾಯಕ ಪರಿಸ್ಥಿತಿಯು ಸಂಭವಿಸುತ್ತದೆ: ನೀವು ವಿಭಜನೆಗೆ ಏನನ್ನೂ ಬರೆಯದೆ ಕೊನೆಗೊಂಡಿದ್ದೀರಿ, ಮತ್ತು ಎಲ್ಲಾ ಮುಕ್ತ ಸ್ಥಳ (ಸುಮಾರು 85%) ಎಲ್ಲೋ ಕಣ್ಮರೆಯಾಯಿತು. ಅಂತಹ ದಾಳಿಗೆ ಒಳಪಟ್ಟಿರುವ ವಿಭಾಗದ ವಿಶ್ಲೇಷಣೆಯು ಕೇವಲ ಒಂದು ಐಟಂ (ಒಂದು ಕೀಲಿಯೊಂದಿಗೆ ಸಜ್ಜುಗೊಂಡ ವಸ್ತು), ಗಾತ್ರದಲ್ಲಿ ಹಲವಾರು ಬೈಟ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಅನೇಕ ಮರದ ನೋಡ್‌ಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ. ಅಂದರೆ, ಈ ಹಿಂದೆ 15% ಡಿಸ್ಕ್ ಜಾಗವನ್ನು ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ವಿಷಯವು ಸಂಪೂರ್ಣ ವಿಭಾಗದ ಮೇಲೆ ಸಮವಾಗಿ "ಸ್ಮೀಯರ್" ಆಗಿ ಹೊರಹೊಮ್ಮಿತು, ಇದರಿಂದಾಗಿ ಹೊಸ ಫೈಲ್ ಅನ್ನು ಬರೆಯಲು ಎಲ್ಲಿಯೂ ಇಲ್ಲ, ಏಕೆಂದರೆ ಅದರ ಕೀಲಿಯು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಎಲ್ಲಕ್ಕಿಂತ ದೊಡ್ಡದಾಗಿದೆ ಮತ್ತು ಉಚಿತವಾಗಿದೆ ವಿಭಾಗದ ಬ್ಲಾಕ್‌ಗಳು ಖಾಲಿಯಾಗಿವೆ.
ಇದಲ್ಲದೆ, ಇದೆಲ್ಲವೂ ಈಗಾಗಲೇ ಮೂಲಭೂತ Btrfs ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ (ಯಾವುದೇ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು, ಉಪ ಸಂಪುಟಗಳು, ಇತ್ಯಾದಿಗಳಿಲ್ಲದೆ) ನಡೆಯುತ್ತದೆ ಮತ್ತು ಆ FS ನಲ್ಲಿ ಫೈಲ್ ಬಾಡಿಗಳನ್ನು (ಮರದಲ್ಲಿ “ತುಣುಕುಗಳಾಗಿ” ಅಥವಾ ವಿಸ್ತಾರವಾಗಿ) ಹೇಗೆ ಸಂಗ್ರಹಿಸಲು ನೀವು ನಿರ್ಧರಿಸುತ್ತೀರಿ ಎಂಬುದು ಮುಖ್ಯವಲ್ಲ. ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡದ ಬ್ಲಾಕ್‌ಗಳು) - ಅಂತಿಮ ಫಲಿತಾಂಶವು ಒಂದೇ ಆಗಿರುತ್ತದೆ.
ನೀವು ಇತರ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಇಂತಹ ದಾಳಿಗೆ ಒಳಪಡಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ (ಅವರು ನಿಮಗೆ ಏನು ಹೇಳಿದರೂ ಪರವಾಗಿಲ್ಲ). ನಾನು ಬಹಳ ಹಿಂದೆಯೇ ಸಮಸ್ಯೆಯ ಕಾರಣವನ್ನು ವಿವರಿಸಿದೆ: ಇದು Btrfs ನಲ್ಲಿನ B-ಟ್ರೀ ಪರಿಕಲ್ಪನೆಯ ಸಂಪೂರ್ಣ ವಿರೂಪವಾಗಿದೆ, ಇದು ಸ್ವಯಂಪ್ರೇರಿತವಾಗಿ ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅವನತಿಗೆ ಸಾಧ್ಯವಾಗುವಂತೆ ಮಾಡುತ್ತದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಕೆಲವು ಲೋಡ್‌ಗಳ ಅಡಿಯಲ್ಲಿ, ಹೊರಗಿನ ಸಹಾಯವಿಲ್ಲದೆ ತನ್ನದೇ ಆದ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಫೈಲ್ ಸಿಸ್ಟಮ್ ನಿರಂತರವಾಗಿ "ಬೇರ್ಪಡುತ್ತದೆ". ಎಲ್ಲಾ ರೀತಿಯ "ಒತ್ತುವ" ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳು ವೈಯಕ್ತಿಕ ಡೆಸ್ಕ್‌ಟಾಪ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ದಿನವನ್ನು ಉಳಿಸುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ.
ಸಾಮೂಹಿಕ ಸರ್ವರ್‌ಗಳಲ್ಲಿ, ಆಕ್ರಮಣಕಾರರು ಯಾವಾಗಲೂ "ಮುಂದೆ" ಪಡೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಅಡ್ಮಿನಿಸ್ಟ್ರೇಟರ್ ಅವನನ್ನು ನಿಖರವಾಗಿ ಬೆದರಿಸಿದ್ದು ಯಾರು ಎಂದು ನಿರ್ಧರಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. Btrfs ನಲ್ಲಿ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಅತ್ಯಂತ ವೇಗವಾದ ಮಾರ್ಗವೆಂದರೆ ಸಾಮಾನ್ಯ B-ಟ್ರೀ ರಚನೆಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸುವುದು, ಅಂದರೆ. ಡಿಸ್ಕ್ ಸ್ವರೂಪವನ್ನು ಮರುವಿನ್ಯಾಸಗೊಳಿಸುವುದು ಮತ್ತು Btrfs ಕೋಡ್‌ನ ಗಮನಾರ್ಹ ಭಾಗಗಳನ್ನು ಪುನಃ ಬರೆಯುವುದು. ಡೆವಲಪರ್‌ಗಳು ಸಂಬಂಧಿತ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಮತ್ತು ಡೇಟಾ ರಚನೆಗಳಲ್ಲಿನ ಮೂಲ ಲೇಖನಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಅನುಸರಿಸಿದರೆ ಮತ್ತು “ಲಿನಕ್ಸ್‌ನಲ್ಲಿನ ವಾಡಿಕೆಯಂತೆ (ಮತ್ತು ಪ್ರೋತ್ಸಾಹಿಸಿದ) “ಮುರಿದ ಫೋನ್” ಆಟವನ್ನು ಆಡದಿದ್ದರೆ, ಡೀಬಗ್ ಮಾಡುವುದು ಸೇರಿದಂತೆ ಇದು 8-10 ವರ್ಷಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ದಾರಿ".
ಡೆವಲಪರ್‌ಗಳಿಗೆ ಇದನ್ನೆಲ್ಲ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬೇಕಾದ ಸಮಯವನ್ನು ಕೂಡ ಇಲ್ಲಿ ಸೇರಿಸಬೇಕಾಗಿದೆ. ಇದು ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗುವುದು ಇಲ್ಲಿಯೇ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಅವರಿಗೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು 10 ವರ್ಷಗಳು ಸಾಕಾಗಲಿಲ್ಲ. ಸರಿ, ಅಲ್ಲಿಯವರೆಗೆ ನೀವು ಪವಾಡಕ್ಕಾಗಿ ಆಶಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. "ನಿಮಗೆ ಮತ್ತು ನನಗೆ ತಿಳಿದಿರದ" ಆರೋಹಿಸುವ ಆಯ್ಕೆಯ ರೂಪದಲ್ಲಿ ಅಥವಾ ತಯಾರಿಸಲು "ಕೇವಲ ವ್ಯವಹಾರದ ವಿಷಯ" ಎಂಬ ಪ್ಯಾಚ್ ರೂಪದಲ್ಲಿ ಇದು ಸಂಭವಿಸುವುದಿಲ್ಲ. ಅಂತಹ ಪ್ರತಿ ಆತುರದ "ಫಿಕ್ಸ್" ಗಾಗಿ ನಾನು ಅವನತಿಯ ಹೊಸ ಸನ್ನಿವೇಶವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತೇನೆ. ಬಿ-ಟ್ರೀಗಳು ನನ್ನ ನೆಚ್ಚಿನ ವಿಷಯಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಮತ್ತು ಈ ರಚನೆಗಳು ತಮ್ಮೊಂದಿಗೆ ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ಸಹಿಸುವುದಿಲ್ಲ ಎಂದು ನಾನು ಹೇಳಲೇಬೇಕು!
ನನಗಾಗಿ ಬಿಟಿಆರ್‌ಎಫ್‌ಗಳನ್ನು ಹೇಗೆ ಇರಿಸುವುದು? ಸಂಪೂರ್ಣವಾಗಿ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಎಂದು ಕರೆಯಲಾಗದ ವಿಷಯವಾಗಿ, ಬಳಸುವುದನ್ನು ಬಿಡಿ. ಏಕೆಂದರೆ, ವ್ಯಾಖ್ಯಾನದ ಪ್ರಕಾರ, ಎಫ್ಎಸ್ ಎಂಬುದು "ಡಿಸ್ಕ್ ಸ್ಪೇಸ್" ಸಂಪನ್ಮೂಲದ ಪರಿಣಾಮಕಾರಿ ನಿರ್ವಹಣೆಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಓಎಸ್ ಉಪವ್ಯವಸ್ಥೆಯಾಗಿದೆ, ಇದನ್ನು ನಾವು ಬಿಟಿಆರ್‌ಎಫ್‌ಗಳ ಸಂದರ್ಭದಲ್ಲಿ ನೋಡುವುದಿಲ್ಲ. ಸರಿ, ಕೆಲಸಕ್ಕೆ ತಡವಾಗದಂತೆ ಗಡಿಯಾರವನ್ನು ಖರೀದಿಸಲು ನೀವು ಅಂಗಡಿಗೆ ಬಂದಿದ್ದೀರಿ ಎಂದು ಊಹಿಸಿ, ಮತ್ತು ಗಡಿಯಾರದ ಬದಲಿಗೆ ಅವರು ನಿಮಗೆ ಗರಿಷ್ಠ 30 ನಿಮಿಷಗಳ ಕಾಲ ಟೈಮರ್ನೊಂದಿಗೆ ವಿದ್ಯುತ್ ಗ್ರಿಲ್ ಅನ್ನು ಮಾರಾಟ ಮಾಡಿದರು. ಆದ್ದರಿಂದ, ಬಿಟಿಆರ್‌ಎಫ್‌ಗಳ ಪರಿಸ್ಥಿತಿ ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿದೆ.
ಮೇಲಿಂಗ್ ಪಟ್ಟಿಗಳ ಮೂಲಕ ನೋಡುವಾಗ, ಡ್ರೈವ್‌ಗಳ ಅಗ್ಗದತೆಯಿಂದಾಗಿ ಡಿಸ್ಕ್ ಜಾಗವನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿರ್ವಹಿಸುವುದು ಇನ್ನು ಮುಂದೆ ಪ್ರಸ್ತುತವಾಗುವುದಿಲ್ಲ ಎಂಬ ಹೇಳಿಕೆಯನ್ನು ನಾನು ಆಗಾಗ್ಗೆ ನೋಡುತ್ತೇನೆ. ಇದು ಸಂಪೂರ್ಣ ಅಸಂಬದ್ಧವಾಗಿದೆ. ಪರಿಣಾಮಕಾರಿ ಡಿಸ್ಕ್ ಸ್ಪೇಸ್ ಮ್ಯಾನೇಜರ್ ಇಲ್ಲದೆ, OS ದುರ್ಬಲ ಮತ್ತು ನಿಷ್ಪ್ರಯೋಜಕವಾಗುತ್ತದೆ. ನಿಮ್ಮ ಗಣಕದಲ್ಲಿನ ಡಿಸ್ಕ್‌ಗಳ ಸಾಮರ್ಥ್ಯದ ಹೊರತಾಗಿಯೂ.
RHEL ನಲ್ಲಿ Btrfs ಬೆಂಬಲವನ್ನು ಸ್ಥಗಿತಗೊಳಿಸುವುದರ ಕುರಿತು ನಾನು ಕಾಮೆಂಟ್ ಕೇಳಲು ಬಯಸುತ್ತೇನೆ.
ಇಲ್ಲಿ ಕಾಮೆಂಟ್ ಮಾಡಲು ವಿಶೇಷ ಏನೂ ಇಲ್ಲ, ಎಲ್ಲವೂ ತುಂಬಾ ಸ್ಪಷ್ಟವಾಗಿದೆ. ಅವರು ಅದನ್ನು "ತಂತ್ರಜ್ಞಾನ ಪೂರ್ವವೀಕ್ಷಣೆ" ಎಂದು ಸಹ ಹೊಂದಿದ್ದರು. ಆದ್ದರಿಂದ, ನಾನು ಈ "ಪೂರ್ವವೀಕ್ಷಣೆ" ಮೂಲಕ ಹೋಗಲಿಲ್ಲ. ಈ ಲೇಬಲ್ ಶಾಶ್ವತವಾಗಿ ಸ್ಥಗಿತಗೊಳ್ಳಲು ಬಿಡಬೇಡಿ! ಆದರೆ ಅವರು ಪೂರ್ಣ ಬೆಂಬಲದೊಂದಿಗೆ ದೋಷಯುಕ್ತ ವಿನ್ಯಾಸ ಉತ್ಪನ್ನವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. RHEL ಒಂದು ಉದ್ಯಮವಾಗಿದೆ, ಅಂದರೆ, ನಿಗದಿತ ಸರಕು-ಹಣ ಸಂಬಂಧಗಳು. Btrfs ಮೇಲಿಂಗ್ ಪಟ್ಟಿಯಲ್ಲಿರುವಂತೆ Red Hat ಬಳಕೆದಾರರನ್ನು ಬೆದರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪರಿಸ್ಥಿತಿಯನ್ನು ಊಹಿಸಿ: ತನ್ನ ಕಷ್ಟಪಟ್ಟು ಗಳಿಸಿದ ಹಣವನ್ನು ಡಿಸ್ಕ್ಗಾಗಿ ಪಾವತಿಸಿದ ಕ್ಲೈಂಟ್ ಮತ್ತು ಬೆಂಬಲಕ್ಕಾಗಿ ನೀವು ಏನನ್ನೂ ಬರೆಯದ ನಂತರ ಅವನ ಡಿಸ್ಕ್ ಸ್ಥಳವು ಎಲ್ಲಿಗೆ ಹೋಯಿತು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಯಸುತ್ತಾನೆ. ಇದಕ್ಕೆ ನೀವು ಅವನಿಗೆ ಏನು ಉತ್ತರಿಸುವಿರಿ?
ಮತ್ತಷ್ಟು. Red Hat ನ ಗ್ರಾಹಕರು ಪ್ರಸಿದ್ಧ ದೊಡ್ಡ ಬ್ಯಾಂಕುಗಳು ಮತ್ತು ವಿನಿಮಯ ಕೇಂದ್ರಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತಾರೆ. Btrfs ನಲ್ಲಿ ಉಲ್ಲೇಖಿಸಲಾದ ದುರ್ಬಲತೆಯ ಆಧಾರದ ಮೇಲೆ ಅವರು DoS ದಾಳಿಗೆ ಒಳಪಟ್ಟರೆ ಏನಾಗುತ್ತದೆ ಎಂದು ಊಹಿಸಿ. ಇದಕ್ಕೆ ಯಾರು ಹೊಣೆ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಿ? ಲೇಖಕರು ಯಾವುದಕ್ಕೂ ಜವಾಬ್ದಾರರಲ್ಲ ಎಂದು ಬರೆಯಲಾದ ಜಿಪಿಎಲ್ ಪರವಾನಗಿಯ ಸಾಲಿನತ್ತ ಬೆರಳು ತೋರಿಸಲು ಹೊರಟಿರುವವರಿಗೆ, ನಾನು ತಕ್ಷಣ ಹೇಳುತ್ತೇನೆ: “ಅದನ್ನು ಮರೆಮಾಡಿ!” Red Hat ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಸಾಕಾಗುವುದಿಲ್ಲ ಎಂದು ತೋರುವ ರೀತಿಯಲ್ಲಿ! ಆದರೆ Red Hat ಈ ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಎದುರಿಸುತ್ತಿಲ್ಲ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ, ಅವರ ನಿರ್ದಿಷ್ಟವಾಗಿ ಪ್ರಬಲವಾದ QA ಇಂಜಿನಿಯರ್‌ಗಳ ತಂಡವು ನನ್ನ ಸಮಯದಲ್ಲಿ ನಿಕಟವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಅವಕಾಶವನ್ನು ಹೊಂದಿತ್ತು.
ಕೆಲವು ಕಂಪನಿಗಳು ತಮ್ಮ ಎಂಟರ್‌ಪ್ರೈಸ್ ಉತ್ಪನ್ನಗಳಲ್ಲಿ ಬಿಟಿಆರ್‌ಎಫ್‌ಗಳನ್ನು ಏಕೆ ಬೆಂಬಲಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತವೆ?
ಉತ್ಪನ್ನದ ಹೆಸರಿನಲ್ಲಿ "ಎಂಟರ್‌ಪ್ರೈಸ್" ಎಂಬ ಪೂರ್ವಪ್ರತ್ಯಯವು ಹೆಚ್ಚು ಅರ್ಥವಲ್ಲ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ. ಎಂಟರ್‌ಪ್ರೈಸ್ ಎನ್ನುವುದು ಗ್ರಾಹಕನೊಂದಿಗಿನ ಒಪ್ಪಂದದ ಸಂಬಂಧದಲ್ಲಿ ಹುದುಗಿರುವ ಜವಾಬ್ದಾರಿಯ ಅಳತೆಯಾಗಿದೆ. GNU/Linux - RHEL ಆಧಾರಿತ ಒಂದೇ ಒಂದು ಉದ್ಯಮದ ಬಗ್ಗೆ ನನಗೆ ತಿಳಿದಿದೆ. ಉಳಿದಂತೆ, ನನ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಕೇವಲ ಒಂದು ಉದ್ಯಮವಾಗಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ, ಆದರೆ ಒಂದಲ್ಲ. ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಏನಾದರೂ ಬೇಡಿಕೆಯಿದ್ದರೆ, ಯಾವಾಗಲೂ ಪೂರೈಕೆ ಇರುತ್ತದೆ (ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಉಲ್ಲೇಖಿಸಲಾದ "ಬೆಂಬಲ"). ಸಂಪೂರ್ಣವಾಗಿ ಎಲ್ಲದಕ್ಕೂ ಬೇಡಿಕೆ ಇದೆ, incl. ಮತ್ತು ಬಳಸಲಾಗದ ಸಾಫ್ಟ್ವೇರ್. ಅಂತಹ ಬೇಡಿಕೆಯು ಹೇಗೆ ರೂಪುಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಇಂಧನವನ್ನು ನೀಡುವವರು ಮತ್ತೊಂದು ವಿಷಯ.
ಹಾಗಾಗಿ, Facebook ತನ್ನ ಸರ್ವರ್‌ಗಳಲ್ಲಿ Btrfs ಅನ್ನು ನಿಯೋಜಿಸಿದೆ ಎಂಬ ವದಂತಿಯ ನಂತರ ನಾನು ಯಾವುದೇ ತೀರ್ಮಾನಗಳಿಗೆ ಹೋಗುವುದಿಲ್ಲ. ಮೇಲಾಗಿ, ಮೇಲಿನ ಕಾರಣಗಳಿಗಾಗಿ ಆ ಸರ್ವರ್‌ಗಳ ವಿಳಾಸಗಳನ್ನು ರಹಸ್ಯವಾಗಿಡಲು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.
ಇತ್ತೀಚೆಗೆ XFS ಕೋಡ್ ಅನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಏಕೆ ಹೆಚ್ಚಿನ ಪ್ರಯತ್ನವನ್ನು ಮಾಡಲಾಗಿದೆ? ಎಲ್ಲಾ ನಂತರ, ಆರಂಭದಲ್ಲಿ ಇದು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಆಗಿದೆ, ಮತ್ತು ext4 ದೀರ್ಘಕಾಲದವರೆಗೆ ಸ್ಥಿರವಾಗಿದೆ ಮತ್ತು ಹಿಂದಿನ ಸಮಾನವಾದ ಸ್ಥಿರ ಆವೃತ್ತಿಗಳಿಂದ ನಿರಂತರತೆಯನ್ನು ಹೊಂದಿದೆ. XFS ನಲ್ಲಿ Red Hat ಯಾವ ಆಸಕ್ತಿಯನ್ನು ಹೊಂದಿದೆ? ext4 ಮತ್ತು XFS - ಉದ್ದೇಶದಲ್ಲಿ ಹೋಲುವ ಎರಡು ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಸಕ್ರಿಯವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆಯೇ?
ಇದನ್ನು ಪ್ರೇರೇಪಿಸಿದ್ದು ನನಗೆ ನೆನಪಿಲ್ಲ. ಉಪಕ್ರಮವು Red Hat ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಬಂದಿರುವ ಸಾಧ್ಯತೆಯಿದೆ. ಈ ರೀತಿಯ ಸಂಶೋಧನೆಯನ್ನು ನಡೆಸಲಾಗಿದೆ ಎಂದು ನನಗೆ ನೆನಪಿದೆ: ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಿಂದ ಕೆಲವು ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ, ಹೊಸ ಪೀಳಿಗೆಯ ಉನ್ನತ-ಮಟ್ಟದ ಡ್ರೈವ್‌ಗಳಲ್ಲಿ ದೈತ್ಯಾಕಾರದ ಸಂಖ್ಯೆಯ ವಸ್ತುಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ. ಫಲಿತಾಂಶಗಳ ಪ್ರಕಾರ, XFS ext4 ಗಿಂತ ಉತ್ತಮವಾಗಿ ವರ್ತಿಸಿತು. ಆದ್ದರಿಂದ ಅವರು ಅದನ್ನು ಅತ್ಯಂತ ಭರವಸೆಯೆಂದು ಪ್ರಚಾರ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ನಾನು ಇಲ್ಲಿ ಸಂವೇದನೆಯ ಯಾವುದನ್ನೂ ಹುಡುಕುವುದಿಲ್ಲ.
ನನಗೆ, ಅವರು ಸೋಪ್ನೊಂದಿಗೆ awl ಅನ್ನು ಬದಲಿಸಿದಂತಿದೆ. ext4 ಮತ್ತು XFS ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದರಲ್ಲಿ ಯಾವುದೇ ಅರ್ಥವಿಲ್ಲ. ಎರಡೂ ಸಮಾನಾಂತರವಾಗಿ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಆಯ್ಕೆ ಮಾಡಲು. ಇದರಿಂದ ಒಳ್ಳೆಯದೇನೂ ಬರುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಪ್ರಕೃತಿಯಲ್ಲಿ ಬೆಳವಣಿಗೆಗೆ ಸಾಕಷ್ಟು ಸಾಮರ್ಥ್ಯವಿರುವಾಗ ಆಗಾಗ್ಗೆ ಸಂದರ್ಭಗಳಿವೆ, ಆದರೆ ಬೆಳೆಯಲು ಸ್ಥಳವಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ವಿವಿಧ ವಿಲಕ್ಷಣವಾದ ಕೊಳಕು ಹೊಸ ಬೆಳವಣಿಗೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ, ಅದಕ್ಕೆ ಪ್ರತಿಯೊಬ್ಬರೂ ಬೆರಳು ತೋರಿಸುತ್ತಾರೆ ("ಓಹ್, ನೋಡಿ, ಈ ಜೀವನದಲ್ಲಿ ನೀವು ಏನು ನೋಡುವುದಿಲ್ಲ!").
ext4, F2FS (Btrfs ನಲ್ಲಿ RAID ಅನ್ನು ನಮೂದಿಸಬಾರದು) ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಕಾರ್ಯಗಳ ಆಗಮನದೊಂದಿಗೆ ಲೇಯರ್ ಉಲ್ಲಂಘನೆಯ ಸಮಸ್ಯೆಯನ್ನು (ಋಣಾತ್ಮಕ ಅರ್ಥದಲ್ಲಿ) ಇತ್ಯರ್ಥಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ಭಾವಿಸುತ್ತೀರಾ?
ಸಾಮಾನ್ಯವಾಗಿ, ಯಾವುದೇ ಹಂತಗಳ ಪರಿಚಯ ಮತ್ತು ಅವುಗಳ ಉಲ್ಲಂಘನೆಯ ಬಗ್ಗೆ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವುದು ಸಾಮಾನ್ಯವಾಗಿ ನೀತಿಯ ವಿಷಯವಾಗಿದೆ, ಮತ್ತು ನಾನು ಇಲ್ಲಿ ಯಾವುದರ ಬಗ್ಗೆಯೂ ಕಾಮೆಂಟ್ ಮಾಡಲು ಕೈಗೊಳ್ಳುವುದಿಲ್ಲ. ಲೇಯರ್ ಉಲ್ಲಂಘನೆಯ ವಸ್ತುನಿಷ್ಠ ಅಂಶಗಳು ಯಾರಿಗೂ ಕಡಿಮೆ ಆಸಕ್ತಿಯನ್ನು ಹೊಂದಿಲ್ಲ, ಆದರೆ ಅವುಗಳಲ್ಲಿ ಕೆಲವನ್ನು "ಮೇಲಿನಿಂದ" ಉಲ್ಲಂಘನೆಯ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಪರಿಗಣಿಸಬಹುದು, ಅವುಗಳೆಂದರೆ, ಬ್ಲಾಕ್ ಲೇಯರ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ರಿಯಾತ್ಮಕತೆಯ ಎಫ್‌ಎಸ್‌ನಲ್ಲಿನ ಅನುಷ್ಠಾನ. ಅಂತಹ "ಉಲ್ಲಂಘನೆ" ಕೇವಲ ಅಪರೂಪದ ವಿನಾಯಿತಿಗಳೊಂದಿಗೆ ಸಮರ್ಥನೆಯಾಗಿದೆ. ಅಂತಹ ಪ್ರತಿಯೊಂದು ಪ್ರಕರಣಕ್ಕೂ, ನೀವು ಮೊದಲು ಎರಡು ವಿಷಯಗಳನ್ನು ಸಾಬೀತುಪಡಿಸಬೇಕು: ಅದು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ಹಾಗೆ ಮಾಡುವುದರಿಂದ ಸಿಸ್ಟಮ್ನ ವಿನ್ಯಾಸವು ಹಾನಿಯಾಗುವುದಿಲ್ಲ.
ಉದಾಹರಣೆಗೆ, ಬ್ಲಾಕ್ ಲೇಯರ್‌ಗೆ ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ ಚಟುವಟಿಕೆಯಾಗಿರುವ ಮಿರರಿಂಗ್, ಫೈಲ್ ಸಿಸ್ಟಮ್ ಮಟ್ಟದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ವಿವಿಧ ಕಾರಣಗಳಿಗಾಗಿ. ಉದಾಹರಣೆಗೆ, ಡಿಸ್ಕ್ ಡ್ರೈವ್‌ಗಳಲ್ಲಿ "ಮೂಕ" ಡೇಟಾ ಭ್ರಷ್ಟಾಚಾರ (ಬಿಟ್ ಕೊಳೆತ) ಸಂಭವಿಸುತ್ತದೆ. ಸಾಧನವು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವಾಗ ಇದು ಸಂಭವಿಸುತ್ತದೆ, ಆದರೆ ದೂರದ ಕ್ವೇಸರ್, ಇತ್ಯಾದಿಗಳಿಂದ ಹೊರಸೂಸಲ್ಪಟ್ಟ ಹಾರ್ಡ್ ಗಾಮಾ ಕ್ವಾಂಟಮ್ನ ಪ್ರಭಾವದ ಅಡಿಯಲ್ಲಿ ಬ್ಲಾಕ್ ಡೇಟಾವು ಅನಿರೀಕ್ಷಿತವಾಗಿ ಹಾನಿಗೊಳಗಾಗುತ್ತದೆ. ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ ಈ ಬ್ಲಾಕ್ ಎಫ್ಎಸ್ ಸಿಸ್ಟಮ್ ಬ್ಲಾಕ್ (ಸೂಪರ್ಬ್ಲಾಕ್, ಬಿಟ್ಮ್ಯಾಪ್ ಬ್ಲಾಕ್, ಸ್ಟೋರೇಜ್ ಟ್ರೀ ನೋಡ್, ಇತ್ಯಾದಿ) ಆಗಿ ಹೊರಹೊಮ್ಮಿದರೆ, ಇದು ಖಂಡಿತವಾಗಿಯೂ ಕರ್ನಲ್ ಪ್ಯಾನಿಕ್ಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಬ್ಲಾಕ್ ಲೇಯರ್ (RAID 1 ಎಂದು ಕರೆಯಲ್ಪಡುವ) ನೀಡುವ ಕನ್ನಡಿಗಳು ಈ ಸಮಸ್ಯೆಯಿಂದ ನಿಮ್ಮನ್ನು ಉಳಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ. ಸರಿ, ನಿಜವಾಗಿಯೂ: ಯಾರಾದರೂ ಚೆಕ್ಸಮ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಪ್ರತಿಕೃತಿಯನ್ನು ಓದಬೇಕೇ? ಹೆಚ್ಚುವರಿಯಾಗಿ, ಎಲ್ಲವನ್ನೂ ಪ್ರತಿಬಿಂಬಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ, ಆದರೆ ಮೆಟಾಡೇಟಾವನ್ನು ಮಾತ್ರ. ಕೆಲವು ಪ್ರಮುಖ ಡೇಟಾವನ್ನು (ಉದಾಹರಣೆಗೆ, ನಿರ್ಣಾಯಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್‌ಗಳು) ಮೆಟಾಡೇಟಾವಾಗಿ ಸಂಗ್ರಹಿಸಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅವರು ಸುರಕ್ಷತೆಯ ಅದೇ ಗ್ಯಾರಂಟಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ಉಳಿದ ಡೇಟಾದ ರಕ್ಷಣೆಯನ್ನು ಇತರ ಉಪವ್ಯವಸ್ಥೆಗಳಿಗೆ (ಬಹುಶಃ ಬಳಕೆದಾರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಹ) ವಹಿಸಿಕೊಡುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ - ಇದಕ್ಕಾಗಿ ನಾವು ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಷರತ್ತುಗಳನ್ನು ಒದಗಿಸಿದ್ದೇವೆ.
ಅಂತಹ "ಆರ್ಥಿಕ" ಕನ್ನಡಿಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿರಲು ಹಕ್ಕನ್ನು ಹೊಂದಿವೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಫೈಲ್ ಸಿಸ್ಟಮ್ ಮಟ್ಟದಲ್ಲಿ ಮಾತ್ರ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಆಯೋಜಿಸಬಹುದು. ಇಲ್ಲದಿದ್ದರೆ, ಲೇಯರಿಂಗ್ ಉಲ್ಲಂಘನೆಯು ಕೆಲವು ಸೂಕ್ಷ್ಮ ಪ್ರಯೋಜನಗಳ ಸಲುವಾಗಿ ನಕಲಿ ಕೋಡ್‌ನೊಂದಿಗೆ ಉಪವ್ಯವಸ್ಥೆಯನ್ನು ಅಸ್ತವ್ಯಸ್ತಗೊಳಿಸುತ್ತಿದೆ. FS ಅನ್ನು ಬಳಸಿಕೊಂಡು RAID-5 ಅನ್ನು ಅಳವಡಿಸುವುದು ಇದರ ಒಂದು ಗಮನಾರ್ಹ ಉದಾಹರಣೆಯಾಗಿದೆ. ಅಂತಹ ಪರಿಹಾರಗಳು (ಕಡತ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸ್ವಂತ RAID / LVM) ಎರಡನೆಯದನ್ನು ವಾಸ್ತುಶಿಲ್ಪದ ಪರಿಭಾಷೆಯಲ್ಲಿ ಕೊಲ್ಲುತ್ತವೆ. ವಿವಿಧ ರೀತಿಯ ಮಾರ್ಕೆಟಿಂಗ್ ಸ್ಕ್ಯಾಮರ್‌ಗಳಿಂದ ಲೇಯರಿಂಗ್ ಉಲ್ಲಂಘನೆಯನ್ನು "ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಇರಿಸಲಾಗಿದೆ" ಎಂದು ಸಹ ಇಲ್ಲಿ ಗಮನಿಸಬೇಕು. ಯಾವುದೇ ಆಲೋಚನೆಗಳ ಅನುಪಸ್ಥಿತಿಯಲ್ಲಿ, ನೆರೆಯ ಹಂತಗಳಲ್ಲಿ ದೀರ್ಘಕಾಲ ಅಳವಡಿಸಲಾಗಿರುವ ಕಾರ್ಯವನ್ನು ಉಪವ್ಯವಸ್ಥೆಗಳಿಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಇದನ್ನು ಹೊಸ ಅತ್ಯಂತ ಉಪಯುಕ್ತ ವೈಶಿಷ್ಟ್ಯವಾಗಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸಕ್ರಿಯವಾಗಿ ತಳ್ಳಲಾಗುತ್ತದೆ.
Reiser4 "ಕೆಳಗಿನಿಂದ" ಮಟ್ಟವನ್ನು ಉಲ್ಲಂಘಿಸಿದೆ ಎಂದು ಆರೋಪಿಸಲಾಗಿದೆ. ಕಡತ ವ್ಯವಸ್ಥೆಯು ಎಲ್ಲಾ ಇತರರಂತೆ ಏಕಶಿಲೆಯಾಗಿಲ್ಲ, ಆದರೆ ಮಾಡ್ಯುಲರ್ ಆಗಿದೆ ಎಂಬ ಅಂಶದ ಆಧಾರದ ಮೇಲೆ, ಮೇಲಿನ ಮಟ್ಟವು (VFS) ಏನು ಮಾಡಬೇಕೋ ಅದನ್ನು ಮಾಡುತ್ತದೆ ಎಂಬ ಆಧಾರರಹಿತ ಊಹೆಯನ್ನು ಮಾಡಲಾಯಿತು.
ReiserFS v3.6 ಮತ್ತು, ಉದಾಹರಣೆಗೆ, JFS ನ ಸಾವಿನ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಸಾಧ್ಯವೇ? ಇತ್ತೀಚೆಗೆ ಅವರು ಕೋರ್ನಲ್ಲಿ ಬಹುತೇಕ ಗಮನವನ್ನು ಪಡೆದಿಲ್ಲ. ಅವು ಬಳಕೆಯಲ್ಲಿಲ್ಲವೇ?
ಇಲ್ಲಿ ನಾವು ಸಾಫ್ಟ್ವೇರ್ ಉತ್ಪನ್ನದ ಸಾವಿನ ಅರ್ಥವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬೇಕಾಗಿದೆ. ಒಂದೆಡೆ, ಅವರು ಯಶಸ್ವಿಯಾಗಿ ಬಳಸುತ್ತಾರೆ (ಅದಕ್ಕಾಗಿ ಅವರು ರಚಿಸಲಾಗಿದೆ, ಎಲ್ಲಾ ನಂತರ), ಅಂದರೆ ಅವರು ವಾಸಿಸುತ್ತಿದ್ದಾರೆ. ಮತ್ತೊಂದೆಡೆ, ನಾನು JFS ಗಾಗಿ ಮಾತನಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ (ನನಗೆ ಹೆಚ್ಚು ತಿಳಿದಿಲ್ಲ), ಆದರೆ ReiserFS (v3) ಹೊಸ ಪ್ರವೃತ್ತಿಗಳಿಗೆ ಹೊಂದಿಕೊಳ್ಳಲು ತುಂಬಾ ಕಷ್ಟ (ಆಚರಣೆಯಲ್ಲಿ ಪರೀಕ್ಷಿಸಲಾಗಿದೆ). ಇದರರ್ಥ ಭವಿಷ್ಯದಲ್ಲಿ ಡೆವಲಪರ್‌ಗಳು ಅದರತ್ತ ಗಮನ ಹರಿಸುವುದಿಲ್ಲ, ಆದರೆ ಹೊಂದಿಕೊಳ್ಳಲು ಸುಲಭವಾದವುಗಳಿಗೆ. ಈ ಕಡೆಯಿಂದ, ಅಯ್ಯೋ, ಇದು ವಾಸ್ತುಶಿಲ್ಪದ ಪರಿಭಾಷೆಯಲ್ಲಿ ಸತ್ತಿದೆ ಎಂದು ತಿರುಗುತ್ತದೆ. ನಾನು "ನೈತಿಕವಾಗಿ ಬಳಕೆಯಲ್ಲಿಲ್ಲದ" ಪರಿಕಲ್ಪನೆಯನ್ನು ಕುಶಲತೆಯಿಂದ ನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಇದು ಚೆನ್ನಾಗಿ ಅನ್ವಯಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ವಾರ್ಡ್ರೋಬ್ಗೆ, ಆದರೆ ಸಾಫ್ಟ್ವೇರ್ ಉತ್ಪನ್ನಗಳಿಗೆ ಅಲ್ಲ. ಯಾವುದೋ ಒಂದು ವಿಷಯದಲ್ಲಿ ಕೀಳರಿಮೆ, ಶ್ರೇಷ್ಠತೆಯ ಪರಿಕಲ್ಪನೆ ಇರುತ್ತದೆ. ReserFS v3 ಈಗ ಎಲ್ಲದರಲ್ಲೂ Reiser4 ಗಿಂತ ಕೆಳಮಟ್ಟದಲ್ಲಿದೆ ಎಂದು ನಾನು ಸಂಪೂರ್ಣವಾಗಿ ಹೇಳಬಲ್ಲೆ, ಆದರೆ ಕೆಲವು ರೀತಿಯ ಕೆಲಸದ ಹೊರೆಯಲ್ಲಿ ಇದು ಎಲ್ಲಾ ಇತರ ಅಪ್‌ಸ್ಟ್ರೀಮ್ FS ಗಳಿಗಿಂತ ಉತ್ತಮವಾಗಿದೆ.
FS Tux3 ಮತ್ತು HAMMER/HAMMER2 (DragonFly BSD ಗಾಗಿ FS) ಅಭಿವೃದ್ಧಿಯ ಬಗ್ಗೆ ನಿಮಗೆ ತಿಳಿದಿದೆಯೇ?
ಹೌದು, ನಮಗೆ ತಿಳಿದಿದೆ. Tux3 ನಲ್ಲಿ ನಾನು ಒಮ್ಮೆ ಅವರ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳ ತಂತ್ರಜ್ಞಾನದಲ್ಲಿ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೆ ("ಆವೃತ್ತಿ ಪಾಯಿಂಟರ್‌ಗಳು" ಎಂದು ಕರೆಯಲ್ಪಡುವ), ಆದರೆ Reiser4 ನಲ್ಲಿ ನಾವು ಹೆಚ್ಚಾಗಿ ಬೇರೆ ಮಾರ್ಗದಲ್ಲಿ ಹೋಗುತ್ತೇವೆ. ನಾನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುವ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಿದ್ದೇನೆ ಮತ್ತು ಸರಳವಾದ Reiser4 ಸಂಪುಟಗಳಿಗೆ ಅವುಗಳನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕೆಂದು ಇನ್ನೂ ನಿರ್ಧರಿಸಿಲ್ಲ. ವಾಸ್ತವವಾಗಿ, ಓಹಾದ್ ರೋಡೆ ಅವರು ಪ್ರಸ್ತಾಪಿಸಿದ ಹೊಸ "ಸೋಮಾರಿ" ಉಲ್ಲೇಖ ಕೌಂಟರ್ ತಂತ್ರವು ಬಿ-ಟ್ರೀಗಳಿಗೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ನಮ್ಮಲ್ಲಿ ಅವರಿಲ್ಲ. Reiesr4 ನಲ್ಲಿ ಬಳಸಲಾದ ಡೇಟಾ ರಚನೆಗಳಿಗಾಗಿ, “ಸೋಮಾರಿಯಾದ” ಕೌಂಟರ್‌ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿಲ್ಲ - ಅವುಗಳನ್ನು ಪರಿಚಯಿಸಲು, ಕೆಲವು ಅಲ್ಗಾರಿದಮಿಕ್ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವುದು ಅವಶ್ಯಕ, ಅದನ್ನು ಯಾರೂ ಇನ್ನೂ ತೆಗೆದುಕೊಂಡಿಲ್ಲ.
ಹ್ಯಾಮರ್ ಪ್ರಕಾರ: ನಾನು ರಚನೆಕಾರರಿಂದ ಲೇಖನವನ್ನು ಓದಿದ್ದೇನೆ. ಆಸಕ್ತಿಯಿಲ್ಲ. ಮತ್ತೆ, ಬಿ-ಟ್ರೀಗಳು. ಈ ಡೇಟಾ ರಚನೆಯು ಹತಾಶವಾಗಿ ಹಳೆಯದಾಗಿದೆ. ಕಳೆದ ಶತಮಾನದಲ್ಲಿ ನಾವು ಅದನ್ನು ಕೈಬಿಟ್ಟಿದ್ದೇವೆ.
CephFS/GlusterFS/ಇತ್ಯಾದಿ ನೆಟ್ವರ್ಕ್ ಕ್ಲಸ್ಟರ್ FSಗಳಿಗೆ ಹೆಚ್ಚುತ್ತಿರುವ ಬೇಡಿಕೆಯನ್ನು ನೀವು ಹೇಗೆ ನಿರ್ಣಯಿಸುತ್ತೀರಿ? ಈ ಬೇಡಿಕೆಯು ನೆಟ್ವರ್ಕ್ FS ಕಡೆಗೆ ಡೆವಲಪರ್ಗಳ ಆದ್ಯತೆಗಳಲ್ಲಿ ಬದಲಾವಣೆ ಮತ್ತು ಸ್ಥಳೀಯ FS ಗೆ ಸಾಕಷ್ಟು ಗಮನ ನೀಡುವುದಿಲ್ಲ ಎಂದರ್ಥವೇ?
ಹೌದು, ಆದ್ಯತೆಗಳಲ್ಲಿ ಅಂತಹ ಬದಲಾವಣೆ ಸಂಭವಿಸಿದೆ. ಸ್ಥಳೀಯ ಕಡತ ವ್ಯವಸ್ಥೆಗಳ ಅಭಿವೃದ್ಧಿ ಕುಂಠಿತಗೊಂಡಿದೆ. ಅಯ್ಯೋ, ಸ್ಥಳೀಯ ಸಂಪುಟಗಳಿಗೆ ಗಮನಾರ್ಹವಾದದ್ದನ್ನು ಮಾಡುವುದು ಈಗ ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿದೆ ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರೂ ಅದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅವರ ಅಭಿವೃದ್ಧಿಗೆ ಯಾರೂ ಹೂಡಿಕೆ ಮಾಡಲು ಬಯಸುವುದಿಲ್ಲ. ಇದು ಗಣಿತದ ಸಂಶೋಧನೆಗಾಗಿ ಹಣವನ್ನು ನಿಯೋಜಿಸಲು ವಾಣಿಜ್ಯ ಸಂಸ್ಥೆಯನ್ನು ಕೇಳುವಂತೆಯೇ ಇರುತ್ತದೆ - ಯಾವುದೇ ಉತ್ಸಾಹವಿಲ್ಲದೆ ಅವರು ಹೊಸ ಪ್ರಮೇಯದಲ್ಲಿ ನೀವು ಹೇಗೆ ಹಣವನ್ನು ಗಳಿಸಬಹುದು ಎಂದು ಕೇಳುತ್ತಾರೆ. ಈಗ ಸ್ಥಳೀಯ ಎಫ್ಎಸ್ ಎಂದರೆ "ಪೆಟ್ಟಿಗೆಯ ಹೊರಗೆ" ಮತ್ತು "ಯಾವಾಗಲೂ ಕೆಲಸ ಮಾಡಬೇಕು" ಎಂದು ಮಾಂತ್ರಿಕವಾಗಿ ಗೋಚರಿಸುತ್ತದೆ ಮತ್ತು ಅದು ಕೆಲಸ ಮಾಡದಿದ್ದರೆ, ಅದು ವಿಳಾಸವಿಲ್ಲದ ಗೊಣಗಾಟವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ: "ಹೌದು, ಅವರು ಏನು ಯೋಚಿಸುತ್ತಿದ್ದಾರೆ!"
ಆದ್ದರಿಂದ ಸ್ಥಳೀಯ ಎಫ್‌ಎಸ್‌ಗೆ ಗಮನ ಕೊರತೆ, ಆ ಪ್ರದೇಶದಲ್ಲಿ ಇನ್ನೂ ಸಾಕಷ್ಟು ಕೆಲಸಗಳಿವೆ. ಮತ್ತು ಹೌದು, ಪ್ರತಿಯೊಬ್ಬರೂ ವಿತರಿಸಿದ ಸಂಗ್ರಹಣೆಗೆ ತಿರುಗಿದ್ದಾರೆ, ಇದನ್ನು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸ್ಥಳೀಯ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳ ಆಧಾರದ ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಇದು ಈಗ ತುಂಬಾ ಫ್ಯಾಶನ್ ಆಗಿದೆ. "ಬಿಗ್ ಡೇಟಾ" ಎಂಬ ನುಡಿಗಟ್ಟು ಅನೇಕರಿಗೆ ಅಡ್ರಿನಾಲಿನ್ ವಿಪರೀತವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಅದನ್ನು ಸಮ್ಮೇಳನಗಳು, ಕಾರ್ಯಾಗಾರಗಳು, ದೊಡ್ಡ ಸಂಬಳ ಇತ್ಯಾದಿಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತದೆ.
ನೆಟ್ವರ್ಕ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಕೆದಾರ ಸ್ಥಳಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಕರ್ನಲ್ ಜಾಗದಲ್ಲಿ ಅಳವಡಿಸುವುದು ತಾತ್ವಿಕವಾಗಿ ಎಷ್ಟು ಸಮಂಜಸವಾಗಿದೆ?
ಇನ್ನೂ ಎಲ್ಲಿಯೂ ಕಾರ್ಯಗತಗೊಳಿಸದ ಅತ್ಯಂತ ಸಮಂಜಸವಾದ ವಿಧಾನ. ಸಾಮಾನ್ಯವಾಗಿ, ನೆಟ್ವರ್ಕ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಯಾವ ಜಾಗದಲ್ಲಿ ಅಳವಡಿಸಬೇಕು ಎಂಬ ಪ್ರಶ್ನೆಯು "ಎರಡು ಅಂಚಿನ ಕತ್ತಿ" ಆಗಿದೆ. ಸರಿ, ಒಂದು ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ. ಕ್ಲೈಂಟ್ ರಿಮೋಟ್ ಯಂತ್ರದಲ್ಲಿ ಡೇಟಾವನ್ನು ದಾಖಲಿಸಿದ್ದಾರೆ. ಅವು ಕೊಳಕು ಪುಟಗಳ ರೂಪದಲ್ಲಿ ಅವಳ ಪುಟ ಸಂಗ್ರಹಕ್ಕೆ ಬಿದ್ದವು. ಕರ್ನಲ್ ಜಾಗದಲ್ಲಿ "ತೆಳುವಾದ ಗೇಟ್‌ವೇ" ನೆಟ್ವರ್ಕ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗೆ ಇದು ಕೆಲಸವಾಗಿದೆ. ನಂತರ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಬೇಗ ಅಥವಾ ನಂತರ ಆ ಪುಟಗಳನ್ನು ಮುಕ್ತಗೊಳಿಸಲು ಡಿಸ್ಕ್ಗೆ ಬರೆಯಲು ನಿಮ್ಮನ್ನು ಕೇಳುತ್ತದೆ. ನಂತರ IO- ಫಾರ್ವರ್ಡ್ ಮಾಡುವ (ಕಳುಹಿಸುವ) ನೆಟ್ವರ್ಕ್ FS ಮಾಡ್ಯೂಲ್ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತದೆ. ಈ ಪುಟಗಳು ಯಾವ ಸರ್ವರ್ ಯಂತ್ರಕ್ಕೆ (ಸರ್ವರ್ ನೋಡ್) ಹೋಗುತ್ತವೆ ಎಂಬುದನ್ನು ಇದು ನಿರ್ಧರಿಸುತ್ತದೆ.
ನಂತರ ನೆಟ್ವರ್ಕ್ ಸ್ಟಾಕ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ (ಮತ್ತು, ನಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಇದನ್ನು ಕರ್ನಲ್ ಜಾಗದಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ). ಮುಂದೆ, ಸರ್ವರ್ ನೋಡ್ ಆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಡೇಟಾ ಅಥವಾ ಮೆಟಾಡೇಟಾದೊಂದಿಗೆ ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಈ ಎಲ್ಲಾ ವಿಷಯವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಲು ಬ್ಯಾಕೆಂಡ್ ಸ್ಟೋರೇಜ್ ಮಾಡ್ಯೂಲ್ (ಅಂದರೆ, ಕರ್ನಲ್ ಜಾಗದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸ್ಥಳೀಯ FS) ಗೆ ಸೂಚನೆ ನೀಡುತ್ತದೆ. ಆದ್ದರಿಂದ, "ಕಳುಹಿಸುವ" ಮತ್ತು "ಸ್ವೀಕರಿಸುವ" ಮಾಡ್ಯೂಲ್‌ಗಳು ಎಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ನಾವು ಕಡಿಮೆಗೊಳಿಸಿದ್ದೇವೆ. ಆ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಬಳಕೆದಾರರ ಜಾಗದಲ್ಲಿ ರನ್ ಆಗಿದ್ದರೆ, ಇದು ಅನಿವಾರ್ಯವಾಗಿ ಸಂದರ್ಭ ಸ್ವಿಚಿಂಗ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ (ಕರ್ನಲ್ ಸೇವೆಗಳನ್ನು ಬಳಸುವ ಅಗತ್ಯತೆಯಿಂದಾಗಿ). ಅಂತಹ ಸ್ವಿಚ್ಗಳ ಸಂಖ್ಯೆಯು ಅನುಷ್ಠಾನದ ವಿವರಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.
ಅಂತಹ ಹಲವು ಸ್ವಿಚ್‌ಗಳು ಇದ್ದರೆ, ನಂತರ ಶೇಖರಣಾ ಥ್ರೋಪುಟ್ (I/O ಕಾರ್ಯಕ್ಷಮತೆ) ಕಡಿಮೆಯಾಗುತ್ತದೆ. ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಸಂಗ್ರಹಣೆಯು ನಿಧಾನವಾದ ಡಿಸ್ಕ್‌ಗಳಿಂದ ಮಾಡಲ್ಪಟ್ಟಿದ್ದರೆ, ನೀವು ಗಮನಾರ್ಹ ಕುಸಿತವನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ. ಆದರೆ ನೀವು ವೇಗದ ಡಿಸ್ಕ್ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ (SSD, NVRAM, ಇತ್ಯಾದಿ), ನಂತರ ಸಂದರ್ಭ ಸ್ವಿಚಿಂಗ್ ಈಗಾಗಲೇ "ಅಡಚಣೆ" ಆಗುತ್ತದೆ ಮತ್ತು ಸಂದರ್ಭ ಸ್ವಿಚಿಂಗ್ನಲ್ಲಿ ಉಳಿಸುವ ಮೂಲಕ, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಿಸಬಹುದು. ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಕರ್ನಲ್ ಜಾಗಕ್ಕೆ ಸರಿಸುವುದು ಹಣವನ್ನು ಉಳಿಸುವ ಪ್ರಮಾಣಿತ ಮಾರ್ಗವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, 9p ಸರ್ವರ್ ಅನ್ನು QEMU ನಿಂದ ಹೋಸ್ಟ್ ಗಣಕದಲ್ಲಿನ ಕರ್ನಲ್ಗೆ ಸ್ಥಳಾಂತರಿಸುವುದು VirtFS ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಮೂರು ಪಟ್ಟು ಹೆಚ್ಚಳಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ ಎಂದು ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ.
ಇದು ಸಹಜವಾಗಿ, ನೆಟ್ವರ್ಕ್ ಎಫ್ಎಸ್ ಅಲ್ಲ, ಆದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ವಸ್ತುಗಳ ಸಾರವನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. ಈ ಆಪ್ಟಿಮೈಸೇಶನ್‌ನ ತೊಂದರೆಯೆಂದರೆ ಪೋರ್ಟಬಿಲಿಟಿ ಸಮಸ್ಯೆಗಳು. ಕೆಲವರಿಗೆ, ಎರಡನೆಯದು ವಿಮರ್ಶಾತ್ಮಕವಾಗಿರಬಹುದು. ಉದಾಹರಣೆಗೆ, GlusterFS ಕರ್ನಲ್‌ನಲ್ಲಿ ಯಾವುದೇ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಇದಕ್ಕೆ ಧನ್ಯವಾದಗಳು, ಇದು ಈಗ NetBSD ಸೇರಿದಂತೆ ಹಲವು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
ಸ್ಥಳೀಯ ಎಫ್‌ಎಸ್‌ಗಳು ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಯಾವ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಎರವಲು ಪಡೆಯಬಹುದು ಮತ್ತು ಪ್ರತಿಯಾಗಿ?
ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ, ನೆಟ್ವರ್ಕ್ ಎಫ್‌ಎಸ್‌ಗಳು, ನಿಯಮದಂತೆ, ಸ್ಥಳೀಯ ಎಫ್‌ಎಸ್‌ಗಳ ಮೇಲೆ ಆಡ್-ಆನ್‌ಗಳನ್ನು ಹೊಂದಿವೆ, ಆದ್ದರಿಂದ ನೀವು ಎರಡನೆಯದರಿಂದ ಏನನ್ನಾದರೂ ಹೇಗೆ ಎರವಲು ಪಡೆಯಬಹುದು ಎಂದು ನನಗೆ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ. ಸರಿ, ವಾಸ್ತವವಾಗಿ, 4 ಉದ್ಯೋಗಿಗಳ ಕಂಪನಿಯನ್ನು ಪರಿಗಣಿಸೋಣ, ಇದರಲ್ಲಿ ಪ್ರತಿಯೊಬ್ಬರೂ ತಮ್ಮದೇ ಆದ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಾರೆ: ಒಬ್ಬರು ವಿತರಿಸುತ್ತಾರೆ, ಇನ್ನೊಬ್ಬರು ಕಳುಹಿಸುತ್ತಾರೆ, ಮೂರನೆಯವರು ಸ್ವೀಕರಿಸುತ್ತಾರೆ, ನಾಲ್ಕನೇ ಮಳಿಗೆಗಳು. ಮತ್ತು ಕಂಪನಿಯು ಅದನ್ನು ಸಂಗ್ರಹಿಸುವ ತನ್ನ ಉದ್ಯೋಗಿಯಿಂದ ಏನು ಎರವಲು ಪಡೆಯಬಹುದು ಎಂಬ ಪ್ರಶ್ನೆಯು ಹೇಗಾದರೂ ತಪ್ಪಾಗಿದೆ (ಅದು ದೀರ್ಘಕಾಲದವರೆಗೆ ಅವನಿಂದ ಎರವಲು ಪಡೆಯಬಹುದೆಂದು ಅದು ಈಗಾಗಲೇ ಹೊಂದಿದೆ).
ಆದರೆ ಸ್ಥಳೀಯ ಎಫ್‌ಎಸ್‌ಗಳು ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಕಲಿಯಲು ಬಹಳಷ್ಟು ಹೊಂದಿವೆ. ಮೊದಲನೆಯದಾಗಿ, ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ ತಾರ್ಕಿಕ ಸಂಪುಟಗಳನ್ನು ಹೇಗೆ ಒಟ್ಟುಗೂಡಿಸುವುದು ಎಂಬುದನ್ನು ನೀವು ಅವರಿಂದ ಕಲಿಯಬೇಕು. ಈಗ ಕರೆಯಲ್ಪಡುವ "ಸುಧಾರಿತ" ಸ್ಥಳೀಯ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳು LVM ನಿಂದ ಎರವಲು ಪಡೆದ "ವರ್ಚುವಲ್ ಸಾಧನ" ತಂತ್ರಜ್ಞಾನವನ್ನು ಬಳಸಿಕೊಂಡು ತಾರ್ಕಿಕ ಪರಿಮಾಣಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುತ್ತದೆ (ಅದೇ ಸಾಂಕ್ರಾಮಿಕ ಲೇಯರಿಂಗ್ ಉಲ್ಲಂಘನೆ ZFS ನಲ್ಲಿ ಮೊದಲು ಅಳವಡಿಸಲಾಗಿದೆ). ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ವರ್ಚುವಲ್ ವಿಳಾಸಗಳ (ಬ್ಲಾಕ್ ಸಂಖ್ಯೆಗಳು) ನೈಜ ಮತ್ತು ಹಿಂದಕ್ಕೆ ಅನುವಾದವು ಕಡಿಮೆ ಮಟ್ಟದಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ (ಅಂದರೆ, ಫೈಲ್ ಸಿಸ್ಟಮ್ I/O ವಿನಂತಿಯನ್ನು ನೀಡಿದ ನಂತರ).
ಬ್ಲಾಕ್ ಲೇಯರ್‌ನಲ್ಲಿ ಜೋಡಿಸಲಾದ ಲಾಜಿಕಲ್ ವಾಲ್ಯೂಮ್‌ಗಳಿಗೆ (ಕನ್ನಡಿಗಳಲ್ಲ) ಸಾಧನಗಳನ್ನು ಸೇರಿಸುವುದು ಮತ್ತು ತೆಗೆದುಹಾಕುವುದು ಅಂತಹ “ವೈಶಿಷ್ಟ್ಯಗಳ” ಪೂರೈಕೆದಾರರು ಸಾಧಾರಣವಾಗಿ ಮೌನವಾಗಿರುವ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ. ನಾನು ನಿಜವಾದ ಸಾಧನಗಳಲ್ಲಿ ವಿಘಟನೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ, ಇದು ದೈತ್ಯಾಕಾರದ ಮೌಲ್ಯಗಳನ್ನು ತಲುಪಬಹುದು, ಆದರೆ ವರ್ಚುವಲ್ ಸಾಧನದಲ್ಲಿ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಕೆಲವು ಜನರು ವರ್ಚುವಲ್ ಸಾಧನಗಳಲ್ಲಿ ಆಸಕ್ತರಾಗಿರುತ್ತಾರೆ: ನಿಮ್ಮ ನೈಜ ಸಾಧನಗಳಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಪ್ರತಿಯೊಬ್ಬರೂ ಆಸಕ್ತಿ ವಹಿಸುತ್ತಾರೆ. ಆದರೆ ZFS ತರಹದ FS (ಹಾಗೆಯೇ LVM ಜೊತೆಗೆ ಯಾವುದೇ FS) ವರ್ಚುವಲ್ ಡಿಸ್ಕ್ ಸಾಧನಗಳೊಂದಿಗೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (ಉಚಿತವಾದವುಗಳಿಂದ ವರ್ಚುವಲ್ ಡಿಸ್ಕ್ ವಿಳಾಸಗಳನ್ನು ನಿಯೋಜಿಸಿ, ಈ ವರ್ಚುವಲ್ ಸಾಧನಗಳನ್ನು ಡಿಫ್ರಾಗ್ಮೆಂಟ್ ಮಾಡಿ, ಇತ್ಯಾದಿ.). ಮತ್ತು ನಿಜವಾದ ಸಾಧನಗಳಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ ಎಂದು ಅವರಿಗೆ ತಿಳಿದಿಲ್ಲ!
ಈಗ ನೀವು ವರ್ಚುವಲ್ ಸಾಧನದಲ್ಲಿ ಶೂನ್ಯ ವಿಘಟನೆಯನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಊಹಿಸಿ (ಅಂದರೆ, ನೀವು ಅಲ್ಲಿ ಕೇವಲ ಒಂದು ದೈತ್ಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಹೊಂದಿದ್ದೀರಿ), ನಿಮ್ಮ ತಾರ್ಕಿಕ ಪರಿಮಾಣಕ್ಕೆ ನೀವು ಡಿಸ್ಕ್ ಅನ್ನು ಸೇರಿಸಿ, ತದನಂತರ ನಿಮ್ಮ ತಾರ್ಕಿಕ ಪರಿಮಾಣದಿಂದ ಮತ್ತೊಂದು ಯಾದೃಚ್ಛಿಕ ಡಿಸ್ಕ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ ಮತ್ತು ನಂತರ ಮರುಸಮತೋಲನ ಮಾಡಿ. ಮತ್ತು ಹಲವು ಬಾರಿ. ವರ್ಚುವಲ್ ಸಾಧನದಲ್ಲಿ ನೀವು ಇನ್ನೂ ಅದೇ ಪ್ರಮಾಣದಲ್ಲಿ ವಾಸಿಸುವಿರಿ ಎಂದು ಊಹಿಸುವುದು ಕಷ್ಟವೇನಲ್ಲ, ಆದರೆ ನೈಜ ಸಾಧನಗಳಲ್ಲಿ ನೀವು ಯಾವುದನ್ನೂ ಉತ್ತಮವಾಗಿ ಕಾಣುವುದಿಲ್ಲ.
ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ಸರಿಪಡಿಸಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ! ಇಲ್ಲಿ ನೀವು ಮಾಡಬಹುದಾದ ಏಕೈಕ ವಿಷಯವೆಂದರೆ ವರ್ಚುವಲ್ ಸಾಧನವನ್ನು ಡಿಫ್ರಾಗ್ಮೆಂಟ್ ಮಾಡಲು ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಕೇಳುವುದು. ಆದರೆ ಅಲ್ಲಿ ಎಲ್ಲವೂ ಅದ್ಭುತವಾಗಿದೆ ಎಂದು ಅವಳು ನಿಮಗೆ ಹೇಳುತ್ತಾಳೆ - ಒಂದೇ ಒಂದು ವ್ಯಾಪ್ತಿ ಇದೆ, ವಿಘಟನೆ ಶೂನ್ಯವಾಗಿದೆ ಮತ್ತು ಅದು ಉತ್ತಮವಾಗಿರಲು ಸಾಧ್ಯವಿಲ್ಲ! ಆದ್ದರಿಂದ, ಬ್ಲಾಕ್ ಮಟ್ಟದಲ್ಲಿ ಜೋಡಿಸಲಾದ ತಾರ್ಕಿಕ ಸಂಪುಟಗಳು ಸಾಧನಗಳ ಪುನರಾವರ್ತಿತ ಸೇರ್ಪಡೆ/ತೆಗೆದುಹಾಕಲು ಉದ್ದೇಶಿಸಿಲ್ಲ. ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ, ನೀವು ಒಮ್ಮೆ ಮಾತ್ರ ಬ್ಲಾಕ್ ಮಟ್ಟದಲ್ಲಿ ತಾರ್ಕಿಕ ಪರಿಮಾಣವನ್ನು ಜೋಡಿಸಬೇಕಾಗಿದೆ, ಅದನ್ನು ಫೈಲ್ ಸಿಸ್ಟಮ್ಗೆ ನೀಡಿ, ಮತ್ತು ಅದರೊಂದಿಗೆ ಬೇರೆ ಏನನ್ನೂ ಮಾಡಬೇಡಿ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸ್ವತಂತ್ರ FS+LVM ಉಪವ್ಯವಸ್ಥೆಗಳ ಸಂಯೋಜನೆಯು ತಾರ್ಕಿಕ ಪರಿಮಾಣಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸಲಾದ ಡ್ರೈವ್‌ಗಳ ವಿಭಿನ್ನ ಸ್ವರೂಪವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. ವಾಸ್ತವವಾಗಿ, ನೀವು HDD ಮತ್ತು ಘನ-ಸ್ಥಿತಿಯ ಸಾಧನಗಳಿಂದ ತಾರ್ಕಿಕ ಪರಿಮಾಣವನ್ನು ಜೋಡಿಸಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸೋಣ. ಆದರೆ ನಂತರ ಮೊದಲನೆಯದು ಡಿಫ್ರಾಗ್ಮೆಂಟೇಶನ್ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಎರಡನೆಯದು ಆಗುವುದಿಲ್ಲ. ಎರಡನೆಯದಕ್ಕಾಗಿ, ನೀವು ತಿರಸ್ಕರಿಸುವ ವಿನಂತಿಗಳನ್ನು ನೀಡಬೇಕಾಗಿದೆ, ಆದರೆ ಮೊದಲನೆಯದು, ಅಲ್ಲ, ಇತ್ಯಾದಿ. ಆದಾಗ್ಯೂ, ಈ ಸಂಯೋಜನೆಯಲ್ಲಿ ಅಂತಹ ಆಯ್ಕೆಯನ್ನು ಪ್ರದರ್ಶಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ.
ಫೈಲ್ ಸಿಸ್ಟಂನಲ್ಲಿ ನಿಮ್ಮ ಸ್ವಂತ LVM ಅನ್ನು ರಚಿಸಿದ ನಂತರ, ಪರಿಸ್ಥಿತಿಯು ಹೆಚ್ಚು ಉತ್ತಮವಾಗುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಇದಲ್ಲದೆ, ಇದನ್ನು ಮಾಡುವ ಮೂಲಕ ನೀವು ಭವಿಷ್ಯದಲ್ಲಿ ಅದನ್ನು ಸುಧಾರಿಸುವ ನಿರೀಕ್ಷೆಯನ್ನು ನಿಜವಾಗಿಯೂ ಕೊನೆಗೊಳಿಸುತ್ತೀರಿ. ಇದು ತುಂಬಾ ಕೆಟ್ಟದು. ವಿಭಿನ್ನ ರೀತಿಯ ಡ್ರೈವ್‌ಗಳು ಒಂದೇ ಯಂತ್ರದಲ್ಲಿ ವಾಸಿಸಬಹುದು. ಮತ್ತು ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅವುಗಳ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ತೋರಿಸದಿದ್ದರೆ, ಯಾರು ಮಾಡುತ್ತಾರೆ?
ಮತ್ತೊಂದು ಸಮಸ್ಯೆ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಕಾಯುತ್ತಿದೆ. "ಬರೆಯಿರಿ-ಎಲ್ಲಿಯಾದರೂ" ಕಡತ ವ್ಯವಸ್ಥೆಗಳು (ಆರೋಹಿಸುವಾಗ ಸೂಕ್ತವಾದ ವಹಿವಾಟಿನ ಮಾದರಿಯನ್ನು ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ ಇದು Reiser4 ಅನ್ನು ಸಹ ಒಳಗೊಂಡಿದೆ). ಅಂತಹ ಕಡತ ವ್ಯವಸ್ಥೆಗಳು ತಮ್ಮ ಶಕ್ತಿಯಲ್ಲಿ ಅಭೂತಪೂರ್ವವಾದ ಡಿಫ್ರಾಗ್ಮೆಂಟೇಶನ್ ಉಪಕರಣಗಳನ್ನು ಒದಗಿಸಬೇಕು. ಮತ್ತು ಕಡಿಮೆ ಮಟ್ಟದ ವಾಲ್ಯೂಮ್ ಮ್ಯಾನೇಜರ್ ಇಲ್ಲಿ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ, ಆದರೆ ದಾರಿಯಲ್ಲಿ ಮಾತ್ರ ಸಿಗುತ್ತದೆ. ವಾಸ್ತವವೆಂದರೆ ಅಂತಹ ಮ್ಯಾನೇಜರ್‌ನೊಂದಿಗೆ, ನಿಮ್ಮ ಎಫ್ಎಸ್ ಕೇವಲ ಒಂದು ಸಾಧನದ ಉಚಿತ ಬ್ಲಾಕ್‌ಗಳ ನಕ್ಷೆಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ - ವರ್ಚುವಲ್. ಅಂತೆಯೇ, ನೀವು ವರ್ಚುವಲ್ ಸಾಧನವನ್ನು ಮಾತ್ರ ಡಿಫ್ರಾಗ್ಮೆಂಟ್ ಮಾಡಬಹುದು. ಇದರರ್ಥ ನಿಮ್ಮ ಡಿಫ್ರಾಗ್ಮೆಂಟರ್ ವರ್ಚುವಲ್ ವಿಳಾಸಗಳ ಒಂದು ದೊಡ್ಡ ಜಾಗದಲ್ಲಿ ದೀರ್ಘಕಾಲ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
ಮತ್ತು ನೀವು ಯಾದೃಚ್ಛಿಕ ತಿದ್ದಿ ಬರೆಯುವ ಬಹಳಷ್ಟು ಬಳಕೆದಾರರನ್ನು ಹೊಂದಿದ್ದರೆ, ಅಂತಹ ಡಿಫ್ರಾಗ್ಮೆಂಟರ್ನ ಉಪಯುಕ್ತ ಪರಿಣಾಮವು ಶೂನ್ಯಕ್ಕೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನಿವಾರ್ಯವಾಗಿ ನಿಧಾನವಾಗಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಮತ್ತು ನಿರಾಶಾದಾಯಕ ರೋಗನಿರ್ಣಯದ "ಮುರಿದ ವಿನ್ಯಾಸ" ದ ಮುಂದೆ ನೀವು ನಿಮ್ಮ ಕೈಗಳನ್ನು ಮಾತ್ರ ಮಡಚಬೇಕಾಗುತ್ತದೆ. ಒಂದೇ ವಿಳಾಸ ಜಾಗದಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಹಲವಾರು ಡಿಫ್ರಾಗ್ಮೆಂಟರ್‌ಗಳು ಪರಸ್ಪರ ಹಸ್ತಕ್ಷೇಪ ಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ನೈಜ ಸಾಧನಕ್ಕಾಗಿ ಉಚಿತ ಬ್ಲಾಕ್‌ಗಳ ನಿಮ್ಮ ಸ್ವಂತ ನಕ್ಷೆಯನ್ನು ನೀವು ನಿರ್ವಹಿಸಿದರೆ ಅದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ವಿಷಯವಾಗಿದೆ. ಇದು ಡಿಫ್ರಾಗ್ಮೆಂಟೇಶನ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸಮಾನಾಂತರಗೊಳಿಸುತ್ತದೆ.
ಆದರೆ ನೀವು ಉನ್ನತ ಮಟ್ಟದ ತಾರ್ಕಿಕ ಪರಿಮಾಣ ವ್ಯವಸ್ಥಾಪಕವನ್ನು ಹೊಂದಿದ್ದರೆ ಮಾತ್ರ ಇದನ್ನು ಮಾಡಬಹುದು. ಅಂತಹ ನಿರ್ವಾಹಕರೊಂದಿಗೆ ಸ್ಥಳೀಯ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳು ಹಿಂದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ (ಕನಿಷ್ಠ, ಅವರ ಬಗ್ಗೆ ನನಗೆ ಗೊತ್ತಿಲ್ಲ). ಕೇವಲ ನೆಟ್ವರ್ಕ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳು (ಉದಾಹರಣೆಗೆ ಗ್ಲುಸ್ಟರ್‌ಎಫ್‌ಎಸ್) ಅಂತಹ ನಿರ್ವಾಹಕರನ್ನು ಹೊಂದಿದ್ದವು. ಇನ್ನೊಂದು ಪ್ರಮುಖ ಉದಾಹರಣೆಯೆಂದರೆ ವಾಲ್ಯೂಮ್ ಇಂಟೆಗ್ರಿಟಿ ಚೆಕ್ (fsck) ಯುಟಿಲಿಟಿ. ಪ್ರತಿ ಸಬ್ವಾಲ್ಯೂಮ್ಗೆ ನಿಮ್ಮ ಸ್ವಂತ ಸ್ವತಂತ್ರ ನಕ್ಷೆಯನ್ನು ನೀವು ಉಚಿತ ಬ್ಲಾಕ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, ನಂತರ ತಾರ್ಕಿಕ ಪರಿಮಾಣವನ್ನು ಪರಿಶೀಲಿಸುವ ವಿಧಾನವನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸಮಾನಾಂತರಗೊಳಿಸಬಹುದು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಉನ್ನತ ಮಟ್ಟದ ವ್ಯವಸ್ಥಾಪಕರೊಂದಿಗಿನ ತಾರ್ಕಿಕ ಸಂಪುಟಗಳು ಉತ್ತಮವಾಗಿ ಅಳೆಯುತ್ತವೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕಡಿಮೆ ಮಟ್ಟದ ವಾಲ್ಯೂಮ್ ಮ್ಯಾನೇಜರ್‌ಗಳೊಂದಿಗೆ ನೀವು ಪೂರ್ಣ ಪ್ರಮಾಣದ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ಸಂಘಟಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. LVM ಮತ್ತು ZFS-ರೀತಿಯ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳೊಂದಿಗೆ, ನೀವು ಸ್ಥಳೀಯ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ಮಾತ್ರ ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಆದರೆ ಜಾಗತಿಕ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ಅಲ್ಲ. ಸ್ಥಳೀಯ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಸಾಮಾನ್ಯ ಫೈಲ್ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾತ್ರ ತಕ್ಷಣವೇ ಹಿಂತಿರುಗಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಮತ್ತು ಅಲ್ಲಿ ಯಾರೂ ತಾರ್ಕಿಕ ಪರಿಮಾಣಗಳೊಂದಿಗೆ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸುವುದಿಲ್ಲ (ಸಾಧನಗಳನ್ನು ಸೇರಿಸುವುದು/ತೆಗೆದುಹಾಕುವುದು). ಇದನ್ನು ಒಂದು ಉದಾಹರಣೆಯೊಂದಿಗೆ ನೋಡೋಣ. ಕೆಲವು ಸಮಯದಲ್ಲಿ, ನೀವು 100 ಫೈಲ್ಗಳನ್ನು ಹೊಂದಿರುವ A ಮತ್ತು B ಎರಡು ಸಾಧನಗಳ ತಾರ್ಕಿಕ ಪರಿಮಾಣವನ್ನು ಹೊಂದಿರುವಾಗ, ನೀವು ಸಿಸ್ಟಮ್ S ನ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡು ನಂತರ ಇನ್ನೊಂದು ನೂರು ಫೈಲ್ಗಳನ್ನು ರಚಿಸಿ.
ಅದರ ನಂತರ, ನೀವು ನಿಮ್ಮ ವಾಲ್ಯೂಮ್‌ಗೆ ಸಾಧನ C ಅನ್ನು ಸೇರಿಸುತ್ತೀರಿ ಮತ್ತು ಅಂತಿಮವಾಗಿ ನಿಮ್ಮ ಸಿಸ್ಟಂ ಅನ್ನು ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ S ಗೆ ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾಡಿ. ಪ್ರಶ್ನೆ: S ಗೆ ರೋಲ್‌ಬ್ಯಾಕ್ ಮಾಡಿದ ನಂತರ ನಿಮ್ಮ ಲಾಜಿಕಲ್ ವಾಲ್ಯೂಮ್ ಎಷ್ಟು ಫೈಲ್‌ಗಳು ಮತ್ತು ಸಾಧನಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ? ನೀವು ಊಹಿಸಿದಂತೆ 100 ಫೈಲ್‌ಗಳು ಇರುತ್ತವೆ, ಆದರೆ 3 ಸಾಧನಗಳು ಇರುತ್ತವೆ - ಇವು ಒಂದೇ ಸಾಧನಗಳು A, B ಮತ್ತು C, ಆದರೂ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ರಚಿಸುವ ಸಮಯದಲ್ಲಿ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಕೇವಲ ಎರಡು ಸಾಧನಗಳು ಇದ್ದವು (A ಮತ್ತು B ) ಆಡ್ ಡಿವೈಸ್ ಸಿ ಕಾರ್ಯಾಚರಣೆಯು ಹಿಂತಿರುಗಲಿಲ್ಲ, ಮತ್ತು ನೀವು ಈಗ ಕಂಪ್ಯೂಟರ್‌ನಿಂದ ಡಿವೈಸ್ ಸಿ ಅನ್ನು ತೆಗೆದುಹಾಕಿದರೆ, ಅದು ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಭ್ರಷ್ಟಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅಳಿಸುವ ಮೊದಲು ನೀವು ರಿಬ್ಯಾಲೆನ್ಸ್ ಲಾಜಿಕಲ್ ವಾಲ್ಯೂಮ್‌ನಿಂದ ಸಾಧನವನ್ನು ತೆಗೆದುಹಾಕಲು ಮೊದಲು ದುಬಾರಿ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಸಾಧನ C ನಿಂದ A ಮತ್ತು B ಸಾಧನಗಳಿಗೆ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಚದುರಿಸುತ್ತದೆ. ಆದರೆ ನಿಮ್ಮ FS ಜಾಗತಿಕ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ಅಂತಹ ಮರುಸಮತೋಲನದ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ ಮತ್ತು S ಗೆ ತ್ವರಿತ ರೋಲ್‌ಬ್ಯಾಕ್ ನಂತರ, ನೀವು ಕಂಪ್ಯೂಟರ್‌ನಿಂದ ಸಾಧನ C ಅನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ತೆಗೆದುಹಾಕಬಹುದು.
ಆದ್ದರಿಂದ, ಜಾಗತಿಕ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಉತ್ತಮವಾಗಿವೆ ಏಕೆಂದರೆ ಅವುಗಳು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾದೊಂದಿಗೆ (ಸಹಜವಾಗಿ, ನಿಮ್ಮ ಸಿಸ್ಟಂ ಅನ್ನು "ಸ್ನ್ಯಾಪ್‌ಶಾಟ್" ಮಾಡಲು ನೀವು ನೆನಪಿಸಿಕೊಂಡರೆ, ಲಾಜಿಕಲ್ ವಾಲ್ಯೂಮ್‌ನಿಂದ (ತಾರ್ಕಿಕ ಪರಿಮಾಣಕ್ಕೆ) ಸಾಧನವನ್ನು ದುಬಾರಿ ತೆಗೆದುಹಾಕುವುದನ್ನು (ಸೇರಿಸುವುದನ್ನು) ತಪ್ಪಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಸರಿಯಾದ ಸಮಯದಲ್ಲಿ). ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಅವುಗಳಿಗೆ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುವುದು ತ್ವರಿತ ಕಾರ್ಯಾಚರಣೆಗಳು ಎಂದು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ. ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸಬಹುದು: ನೀವು ಮೂರು ದಿನಗಳನ್ನು ತೆಗೆದುಕೊಂಡ ತಾರ್ಕಿಕ ಪರಿಮಾಣದಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ತ್ವರಿತವಾಗಿ ಹಿಂತಿರುಗಿಸುವುದು ಹೇಗೆ ಸಾಧ್ಯ? ಆದರೆ ಇದು ಸಾಧ್ಯ! ನಿಮ್ಮ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸರಿಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ಒದಗಿಸಲಾಗಿದೆ. ನಾನು ಮೂರು ವರ್ಷಗಳ ಹಿಂದೆ ಅಂತಹ "3D ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳ" ಕಲ್ಪನೆಯೊಂದಿಗೆ ಬಂದಿದ್ದೇನೆ ಮತ್ತು ಕಳೆದ ವರ್ಷ ನಾನು ಈ ತಂತ್ರವನ್ನು ಪೇಟೆಂಟ್ ಮಾಡಿದ್ದೇನೆ.
ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಸ್ಥಳೀಯ ಎಫ್‌ಎಸ್‌ಗಳು ಕಲಿಯಬೇಕಾದ ಮುಂದಿನ ವಿಷಯವೆಂದರೆ ಮೆಟಾಡೇಟಾವನ್ನು ಪ್ರತ್ಯೇಕ ಸಾಧನಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದು ಅದೇ ರೀತಿಯಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಎಫ್‌ಎಸ್‌ಗಳು ಪ್ರತ್ಯೇಕ ಯಂತ್ರಗಳಲ್ಲಿ (ಮೆಟಾಡೇಟಾ ಸರ್ವರ್‌ಗಳು ಎಂದು ಕರೆಯಲ್ಪಡುವ) ಅವುಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತವೆ. ಪ್ರಾಥಮಿಕವಾಗಿ ಮೆಟಾಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿವೆ ಮತ್ತು ಮೆಟಾಡೇಟಾವನ್ನು ದುಬಾರಿ ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಶೇಖರಣಾ ಸಾಧನಗಳಲ್ಲಿ ಇರಿಸುವ ಮೂಲಕ ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಹೆಚ್ಚು ವೇಗಗೊಳಿಸಬಹುದು. FS+LVM ಸಂಯೋಜನೆಯೊಂದಿಗೆ, ಅಂತಹ ಆಯ್ಕೆಯನ್ನು ಪ್ರದರ್ಶಿಸಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ: LVM ಗೆ ನೀವು ರವಾನಿಸಿದ ಬ್ಲಾಕ್‌ನಲ್ಲಿ ಏನಿದೆ ಎಂದು ತಿಳಿದಿರುವುದಿಲ್ಲ (ಅಲ್ಲಿನ ಡೇಟಾ ಅಥವಾ ಮೆಟಾಡೇಟಾ).
FS+LVM ಸಂಯೋಜನೆಗೆ ಹೋಲಿಸಿದರೆ FS ನಲ್ಲಿ ನಿಮ್ಮ ಸ್ವಂತ ಕಡಿಮೆ-ಮಟ್ಟದ LVM ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದರಿಂದ ನೀವು ಹೆಚ್ಚು ಪ್ರಯೋಜನವನ್ನು ಪಡೆಯುವುದಿಲ್ಲ, ಆದರೆ FS ಅನ್ನು ಅಸ್ತವ್ಯಸ್ತಗೊಳಿಸುವುದು ನೀವು ಚೆನ್ನಾಗಿ ಮಾಡಬಹುದಾದದ್ದು ನಂತರ ಅದರ ಕೋಡ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಅಸಾಧ್ಯವಾಗುತ್ತದೆ. ವರ್ಚುವಲ್ ಸಾಧನಗಳೊಂದಿಗೆ ಧಾವಿಸಿದ ZFS ಮತ್ತು Btrf ಗಳು, ಲೇಯರಿಂಗ್ ಉಲ್ಲಂಘನೆಯು ವಾಸ್ತುಶಿಲ್ಪದ ಪರಿಭಾಷೆಯಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೇಗೆ ಕೊಲ್ಲುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸ್ಪಷ್ಟ ಉದಾಹರಣೆಗಳಾಗಿವೆ. ಮೇಲಾಗಿ, ಕಡತ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ನಿಮ್ಮ ಸ್ವಂತ ಕಡಿಮೆ ಮಟ್ಟದ LVM ಅನ್ನು ನಿರ್ಮಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಬದಲಾಗಿ, ಕೆಲವು ನೆಟ್ವರ್ಕ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳು ವಿಭಿನ್ನ ಯಂತ್ರಗಳೊಂದಿಗೆ (ಸ್ಟೋರೇಜ್ ನೋಡ್‌ಗಳು) ಮಾಡುವಂತೆ ನೀವು ಹೆಚ್ಚಿನ ಮಟ್ಟದಲ್ಲಿ ಸಾಧನಗಳನ್ನು ಲಾಜಿಕಲ್ ವಾಲ್ಯೂಮ್‌ಗಳಾಗಿ ಒಟ್ಟುಗೂಡಿಸಬೇಕಾಗುತ್ತದೆ. ನಿಜ, ಕೆಟ್ಟ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಬಳಕೆಯಿಂದಾಗಿ ಅವರು ಇದನ್ನು ಅಸಹ್ಯಕರವಾಗಿ ಮಾಡುತ್ತಾರೆ.
GlusterFS ಕಡತ ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ DHT ಭಾಷಾಂತರಕಾರ ಮತ್ತು Ceph ಕಡತ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ CRUSH ನಕ್ಷೆ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಸಂಪೂರ್ಣ ಭಯಾನಕ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಉದಾಹರಣೆಗಳು. ನಾನು ನೋಡಿದ ಯಾವುದೇ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಸರಳತೆ ಮತ್ತು ಉತ್ತಮ ಸ್ಕೇಲೆಬಿಲಿಟಿ ವಿಷಯದಲ್ಲಿ ನನ್ನನ್ನು ತೃಪ್ತಿಪಡಿಸಲಿಲ್ಲ. ಹಾಗಾಗಿ ನಾನು ಬೀಜಗಣಿತವನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳಬೇಕಾಗಿತ್ತು ಮತ್ತು ಎಲ್ಲವನ್ನೂ ನಾನೇ ಆವಿಷ್ಕರಿಸಬೇಕಾಗಿತ್ತು. 2015 ರಲ್ಲಿ, ಹ್ಯಾಶ್ ಫಂಕ್ಷನ್‌ಗಳ ಮೇಲೆ ಬಂಡಲ್‌ಗಳನ್ನು ಪ್ರಯೋಗಿಸುತ್ತಿರುವಾಗ, ನನಗೆ ಸರಿಹೊಂದುವ ಯಾವುದನ್ನಾದರೂ ನಾನು ಕಂಡುಹಿಡಿದಿದ್ದೇನೆ ಮತ್ತು ಪೇಟೆಂಟ್ ಪಡೆದಿದ್ದೇನೆ. ಈಗ ಇದನ್ನೆಲ್ಲ ಆಚರಣೆಗೆ ತರುವ ಪ್ರಯತ್ನ ಯಶಸ್ವಿಯಾಗಿದೆ ಎನ್ನಬಹುದು. ಹೊಸ ವಿಧಾನದಲ್ಲಿ ನಾನು ಸ್ಕೇಲೆಬಿಲಿಟಿಗೆ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಕಾಣುತ್ತಿಲ್ಲ.
ಹೌದು, ಪ್ರತಿ ಸಬ್ವಾಲ್ಯೂಮ್ಗೆ ಮೆಮೊರಿಯಲ್ಲಿ ಸೂಪರ್‌ಬ್ಲಾಕ್‌ನಂತಹ ಪ್ರತ್ಯೇಕ ರಚನೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ಇದು ತುಂಬಾ ಭಯಾನಕವಾಗಿದೆಯೇ? ಸಾಮಾನ್ಯವಾಗಿ, ಯಾರು "ಸಾಗರವನ್ನು ಕುದಿಸುತ್ತಾರೆ" ಮತ್ತು ಒಂದು ಸ್ಥಳೀಯ ಯಂತ್ರದಲ್ಲಿ ನೂರಾರು ಸಾವಿರ ಅಥವಾ ಹೆಚ್ಚಿನ ಸಾಧನಗಳ ತಾರ್ಕಿಕ ಸಂಪುಟಗಳನ್ನು ರಚಿಸುತ್ತಾರೆ ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ. ಯಾರಾದರೂ ಇದನ್ನು ನನಗೆ ವಿವರಿಸಿದರೆ, ನಾನು ತುಂಬಾ ಕೃತಜ್ಞನಾಗಿದ್ದೇನೆ. ಈ ಮಧ್ಯೆ, ನನಗೆ ಇದು ಮಾರ್ಕೆಟಿಂಗ್ ಬುಲ್ಶಿಟ್ ಆಗಿದೆ.
ಕರ್ನಲ್ ಬ್ಲಾಕ್ ಸಾಧನ ಉಪವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಬದಲಾವಣೆಗಳು (ಉದಾಹರಣೆಗೆ, blk-mq ನ ನೋಟ) FS ಅನುಷ್ಠಾನದ ಅವಶ್ಯಕತೆಗಳ ಮೇಲೆ ಹೇಗೆ ಪರಿಣಾಮ ಬೀರಿತು?
ಅವರು ಯಾವುದೇ ಪ್ರಭಾವ ಬೀರಲಿಲ್ಲ. ಹೊಸ FS ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲು ಅಗತ್ಯವಿರುವ ಬ್ಲಾಕ್ ಲೇಯರ್‌ನಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ. ಈ ಉಪವ್ಯವಸ್ಥೆಗಳ ಸಂವಹನ ಇಂಟರ್ಫೇಸ್ ತುಂಬಾ ಕಳಪೆಯಾಗಿದೆ. ಚಾಲಕ ಬದಿಯಿಂದ, FS ಹೊಸ ರೀತಿಯ ಡ್ರೈವ್‌ಗಳ ಗೋಚರಿಸುವಿಕೆಯಿಂದ ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರಬೇಕು, ಅದಕ್ಕೆ ಮೊದಲು ಬ್ಲಾಕ್ ಲೇಯರ್ ಅನ್ನು ಸರಿಹೊಂದಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ FS (reiser4 ಗಾಗಿ ಇದು ಹೊಸ ಪ್ಲಗಿನ್‌ಗಳ ನೋಟವನ್ನು ಅರ್ಥೈಸುತ್ತದೆ).
ಹೊಸ ರೀತಿಯ ಮಾಧ್ಯಮಗಳ ಹೊರಹೊಮ್ಮುವಿಕೆ (ಉದಾಹರಣೆಗೆ, SMR, ಅಥವಾ SSD ಗಳ ಸರ್ವತ್ರ) ಫೈಲ್ ಸಿಸ್ಟಮ್ ವಿನ್ಯಾಸಕ್ಕೆ ಮೂಲಭೂತವಾಗಿ ಹೊಸ ಸವಾಲುಗಳನ್ನು ಅರ್ಥೈಸುತ್ತದೆಯೇ?
ಹೌದು. ಮತ್ತು ಇವು ಎಫ್ಎಸ್ ಅಭಿವೃದ್ಧಿಗೆ ಸಾಮಾನ್ಯ ಪ್ರೋತ್ಸಾಹಗಳಾಗಿವೆ. ಸವಾಲುಗಳು ವಿಭಿನ್ನವಾಗಿರಬಹುದು ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಅನಿರೀಕ್ಷಿತವಾಗಿರಬಹುದು. ಉದಾಹರಣೆಗೆ, I/O ಕಾರ್ಯಾಚರಣೆಯ ವೇಗವು ಡೇಟಾದ ತುಣುಕಿನ ಗಾತ್ರ ಮತ್ತು ಅದರ ಆಫ್‌ಸೆಟ್‌ನ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿರುವ ಡ್ರೈವ್‌ಗಳ ಬಗ್ಗೆ ನಾನು ಕೇಳಿದ್ದೇನೆ. Linux ನಲ್ಲಿ, FS ಬ್ಲಾಕ್‌ನ ಗಾತ್ರವು ಪುಟದ ಗಾತ್ರವನ್ನು ಮೀರಬಾರದು, ಅಂತಹ ಡ್ರೈವ್ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅದರ ಪೂರ್ಣ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ತೋರಿಸುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ನಿಮ್ಮ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸರಿಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದರೆ, ಅದರಿಂದ ಹೆಚ್ಚಿನದನ್ನು ಪಡೆಯಲು ಅವಕಾಶವಿದೆ.
ನಿಮ್ಮ ಹೊರತಾಗಿ ಪ್ರಸ್ತುತ ಎಷ್ಟು ಜನರು Reiser4 ಕೋಡ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ?
ನಾನು ಬಯಸುವುದಕ್ಕಿಂತ ಕಡಿಮೆ, ಆದರೆ ನಾನು ಸಂಪನ್ಮೂಲಗಳ ತೀವ್ರ ಕೊರತೆಯನ್ನು ಅನುಭವಿಸುವುದಿಲ್ಲ. Reiser4 ನ ಅಭಿವೃದ್ಧಿಯ ವೇಗದಿಂದ ನಾನು ಹೆಚ್ಚು ತೃಪ್ತನಾಗಿದ್ದೇನೆ. ನಾನು "ಕುದುರೆಗಳನ್ನು ಓಡಿಸಲು" ಹೋಗುವುದಿಲ್ಲ - ಇದು ಸರಿಯಾದ ಪ್ರದೇಶವಲ್ಲ. ಇಲ್ಲಿ, "ನೀವು ಹೆಚ್ಚು ಶಾಂತವಾಗಿ ಚಾಲನೆ ಮಾಡಿದರೆ, ನೀವು ಮುಂದುವರಿಯುತ್ತೀರಿ!" ಆಧುನಿಕ ಕಡತ ವ್ಯವಸ್ಥೆಯು ಅತ್ಯಂತ ಸಂಕೀರ್ಣವಾದ ಕರ್ನಲ್ ಉಪವ್ಯವಸ್ಥೆಯಾಗಿದೆ, ಅದರ ತಪ್ಪು ವಿನ್ಯಾಸ ನಿರ್ಧಾರಗಳು ನಂತರದ ವರ್ಷಗಳ ಮಾನವ ಕೆಲಸವನ್ನು ರದ್ದುಗೊಳಿಸಬಹುದು.
ಏನನ್ನಾದರೂ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸ್ವಯಂಸೇವಕರನ್ನು ನೀಡುವ ಮೂಲಕ, ಪ್ರಯತ್ನಗಳು ಖಂಡಿತವಾಗಿಯೂ ಸರಿಯಾದ ಫಲಿತಾಂಶಕ್ಕೆ ಕಾರಣವಾಗುತ್ತವೆ ಎಂದು ನಾನು ಯಾವಾಗಲೂ ಖಾತರಿಪಡಿಸುತ್ತೇನೆ, ಇದು ಗಂಭೀರ ಅಗತ್ಯಗಳಿಗೆ ಬೇಡಿಕೆಯಾಗಿರುತ್ತದೆ. ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಒಂದೇ ಬಾರಿಗೆ ಅಂತಹ ಹಲವು ಖಾತರಿಗಳು ಇರುವಂತಿಲ್ಲ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಿಸ್ಸಂಶಯವಾಗಿ ಬಳಸಲಾಗದ ಸಾಫ್ಟ್‌ವೇರ್‌ನ "ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು" ನಾಚಿಕೆಯಿಲ್ಲದೆ ಪ್ರಚಾರ ಮಾಡುವ, ನೂರಾರು ಬಳಕೆದಾರರು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳನ್ನು ಮೋಸಗೊಳಿಸುವ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಕರ್ನಲ್ ಶಿಖರಗಳಲ್ಲಿ ಕುಳಿತು ಕಿರುನಗೆ ಮಾಡುವ "ಅಂಕಿ" ಗಳನ್ನು ನಾನು ನಿಲ್ಲಲು ಸಾಧ್ಯವಿಲ್ಲ.
Reiser4 ನ ಅಭಿವೃದ್ಧಿಯನ್ನು ಬೆಂಬಲಿಸಲು ಯಾವುದೇ ಕಂಪನಿಯು ಇಚ್ಛೆ ವ್ಯಕ್ತಪಡಿಸಿದೆಯೇ?
ಹೌದು, ಅಂತಹ ಪ್ರಸ್ತಾಪಗಳು ಇದ್ದವು, incl. ಮತ್ತು ಪ್ರಮುಖ ಮಾರಾಟಗಾರರಿಂದ. ಆದರೆ ಇದಕ್ಕಾಗಿ ನಾನು ಬೇರೆ ದೇಶಕ್ಕೆ ಹೋಗಬೇಕಾಯಿತು. ದುರದೃಷ್ಟವಶಾತ್, ನನಗೆ ಇನ್ನು 30 ವರ್ಷ ವಯಸ್ಸಾಗಿಲ್ಲ, ಮೊದಲ ಸೀಟಿಯಲ್ಲಿ ನಾನು ದೂರವಿರಲು ಮತ್ತು ಹಾಗೆ ಬಿಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
Reiser4 ನಿಂದ ಪ್ರಸ್ತುತ ಯಾವ ವೈಶಿಷ್ಟ್ಯಗಳು ಕಾಣೆಯಾಗಿವೆ?
ReiserFS(v3) ನಲ್ಲಿ ಕಂಡುಬರುವಂತೆಯೇ ಸರಳ ಸಂಪುಟಗಳಿಗೆ ಯಾವುದೇ "ಮರುಗಾತ್ರಗೊಳಿಸು" ಕಾರ್ಯವಿಲ್ಲ. ಹೆಚ್ಚುವರಿಯಾಗಿ, DIRECT_IO ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ಫೈಲ್ ಕಾರ್ಯಾಚರಣೆಗಳು ನೋಯಿಸುವುದಿಲ್ಲ. ಮುಂದೆ, ನಾನು ಪರಿಮಾಣವನ್ನು "ಶಬ್ದಾರ್ಥದ ಉಪಸಂಪುಟಗಳಾಗಿ" ಪ್ರತ್ಯೇಕಿಸಲು ಬಯಸುತ್ತೇನೆ, ಇದು ಸ್ಥಿರ ಗಾತ್ರವನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು ಸ್ವತಂತ್ರ ಸಂಪುಟಗಳಾಗಿ ಅಳವಡಿಸಬಹುದಾಗಿದೆ. "ನೈಜ ವಿಷಯ" ದಲ್ಲಿ ತಮ್ಮ ಕೈಯನ್ನು ಪ್ರಯತ್ನಿಸಲು ಬಯಸುವ ಆರಂಭಿಕರಿಗಾಗಿ ಈ ಸಮಸ್ಯೆಗಳು ಒಳ್ಳೆಯದು.
ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಸರಳವಾದ ಅನುಷ್ಠಾನ ಮತ್ತು ಆಡಳಿತದೊಂದಿಗೆ ನೆಟ್ವರ್ಕ್ ತಾರ್ಕಿಕ ಸಂಪುಟಗಳನ್ನು ಹೊಂದಲು ನಾನು ಬಯಸುತ್ತೇನೆ (ಆಧುನಿಕ ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಈಗಾಗಲೇ ಇದನ್ನು ಅನುಮತಿಸುತ್ತವೆ). ಆದರೆ Reiser4 ಖಂಡಿತವಾಗಿಯೂ ಎಂದಿಗೂ ಹೊಂದಿರುವುದಿಲ್ಲ RAID-Z, ಸ್ಕ್ರಬ್‌ಗಳು, ಉಚಿತ ಸ್ಥಳ ಸಂಗ್ರಹಗಳು, 128-ಬಿಟ್ ವೇರಿಯೇಬಲ್‌ಗಳು ಮತ್ತು ಕೆಲವು ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳ ಡೆವಲಪರ್‌ಗಳಲ್ಲಿ ಕಲ್ಪನೆಗಳ ಕೊರತೆಯ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಉದ್ಭವಿಸಿದ ಇತರ ಮಾರ್ಕೆಟಿಂಗ್ ಅಸಂಬದ್ಧತೆ.
ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಪ್ಲಗಿನ್‌ಗಳಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದೇ?
ನಾವು ಅವುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಇಂಟರ್ಫೇಸ್‌ಗಳು ಮತ್ತು ಪ್ಲಗಿನ್‌ಗಳ (ಮಾಡ್ಯೂಲ್‌ಗಳು) ವಿಷಯದಲ್ಲಿ ಮಾತ್ರ ಮಾತನಾಡಿದರೆ, ಆಗ ಎಲ್ಲವೂ ಅಲ್ಲ. ಆದರೆ ನೀವು ಈ ಇಂಟರ್ಫೇಸ್‌ಗಳಲ್ಲಿ ಸಂಬಂಧಗಳನ್ನು ಸಹ ಪರಿಚಯಿಸಿದರೆ, ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ನೀವು ಈಗಾಗಲೇ ಹೆಚ್ಚಿನ ಬಹುರೂಪತೆಗಳ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಹೊಂದಿರುತ್ತೀರಿ, ಅದನ್ನು ನೀವು ಈಗಾಗಲೇ ಪಡೆಯಬಹುದು. ನೀವು ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ರನ್‌ಟೈಮ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಕಾಲ್ಪನಿಕವಾಗಿ ಫ್ರೀಜ್ ಮಾಡಿ, ಅದೇ X ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಅಳವಡಿಸುವ ಮತ್ತೊಂದು ಪ್ಲಗ್‌ಇನ್‌ಗೆ ಸೂಚಿಸಲು ಸೂಚನಾ ಪಾಯಿಂಟರ್‌ನ ಮೌಲ್ಯವನ್ನು ಬದಲಾಯಿಸಿದ್ದೀರಿ ಮತ್ತು ನಂತರ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದನ್ನು ಮುಂದುವರಿಸಲು ಸಿಸ್ಟಮ್ ಅನ್ನು ಅನ್ಫ್ರೋಜ್ ಮಾಡಿ.
ಅಂತಿಮ ಬಳಕೆದಾರನು ಅಂತಹ "ಬದಲಿ" ಅನ್ನು ಗಮನಿಸದಿದ್ದರೆ, X ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸಿಸ್ಟಮ್ ಶೂನ್ಯ-ಕ್ರಮದ ಪಾಲಿಮಾರ್ಫಿಸಮ್ ಅನ್ನು ಹೊಂದಿದೆ ಎಂದು ನಾವು ಹೇಳುತ್ತೇವೆ (ಅಥವಾ X ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಸಿಸ್ಟಮ್ ವೈವಿಧ್ಯಮಯವಾಗಿದೆ, ಅದು ಒಂದೇ ವಿಷಯವಾಗಿದೆ). ಈಗ ನೀವು ಇಂಟರ್ಫೇಸ್‌ಗಳ ಗುಂಪನ್ನು ಹೊಂದಿದ್ದರೆ, ಆದರೆ ಅವುಗಳ ಮೇಲೆ ಸಂಬಂಧಗಳನ್ನು ಹೊಂದಿದ್ದರೆ (ಇಂಟರ್ಫೇಸ್ ಗ್ರಾಫ್), ನಂತರ ನೀವು ಉನ್ನತ ಆದೇಶಗಳ ಪಾಲಿಮಾರ್ಫಿಸಮ್‌ಗಳನ್ನು ಪರಿಚಯಿಸಬಹುದು, ಇದು ಯಾವುದೇ ಇಂಟರ್ಫೇಸ್‌ನ "ನೆರೆಹೊರೆಯಲ್ಲಿ" ಈಗಾಗಲೇ ಸಿಸ್ಟಮ್ನ ವೈವಿಧ್ಯತೆಯನ್ನು ನಿರೂಪಿಸುತ್ತದೆ. ನಾನು ಬಹಳ ಹಿಂದೆಯೇ ಅಂತಹ ವರ್ಗೀಕರಣವನ್ನು ಪರಿಚಯಿಸಿದೆ, ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ಅದು ಎಂದಿಗೂ ಸಂಭವಿಸಲಿಲ್ಲ.
ಆದ್ದರಿಂದ, ಪ್ಲಗಿನ್‌ಗಳು ಮತ್ತು ಅಂತಹ ಹೆಚ್ಚಿನ ಪಾಲಿಮಾರ್ಫಿಸಮ್‌ಗಳ ಸಹಾಯದಿಂದ, ನೀವು ತಿಳಿದಿರುವ ಯಾವುದೇ ವೈಶಿಷ್ಟ್ಯವನ್ನು ವಿವರಿಸಬಹುದು, ಹಾಗೆಯೇ ಎಂದಿಗೂ ಉಲ್ಲೇಖಿಸದಂತಹವುಗಳನ್ನು "ಮುನ್ಸೂಚಿಸಬಹುದು". ನಾನು ಇದನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸಾಬೀತುಪಡಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಆದರೆ ನನಗೆ ಇನ್ನೂ ಪ್ರತಿರೂಪದ ಬಗ್ಗೆ ತಿಳಿದಿಲ್ಲ. ಸಾಮಾನ್ಯವಾಗಿ, ಈ ಪ್ರಶ್ನೆಯು ಫೆಲಿಕ್ಸ್ ಕ್ಲೈನ್ ಅವರ "ಎರ್ಲಾಂಗೆನ್ ಪ್ರೋಗ್ರಾಂ" ಅನ್ನು ನೆನಪಿಸಿತು. ಒಂದು ಸಮಯದಲ್ಲಿ ಅವರು ಎಲ್ಲಾ ಜ್ಯಾಮಿತಿಯನ್ನು ಬೀಜಗಣಿತದ ಶಾಖೆಯಾಗಿ ಪ್ರತಿನಿಧಿಸಲು ಪ್ರಯತ್ನಿಸಿದರು (ನಿರ್ದಿಷ್ಟವಾಗಿ, ಗುಂಪು ಸಿದ್ಧಾಂತ).
ಈಗ ಮುಖ್ಯ ಪ್ರಶ್ನೆಗೆ - Reiser4 ಅನ್ನು ಮುಖ್ಯ ಕೋರ್‌ಗೆ ಪ್ರಚಾರ ಮಾಡುವುದರೊಂದಿಗೆ ವಿಷಯಗಳು ಹೇಗೆ ನಡೆಯುತ್ತಿವೆ? ಈ ಫೈಲ್ ಸಿಸ್ಟಂನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಕುರಿತು ನೀವು ಕೊನೆಯ ಸಂದರ್ಶನದಲ್ಲಿ ಮಾತನಾಡಿದ ಯಾವುದೇ ಪ್ರಕಟಣೆಗಳಿವೆಯೇ? ನಿಮ್ಮ ದೃಷ್ಟಿಕೋನದಿಂದ ಈ ಪ್ರಶ್ನೆ ಎಷ್ಟು ಪ್ರಸ್ತುತವಾಗಿದೆ?
ಸಾಮಾನ್ಯವಾಗಿ, ನಾವು ಮೂರು ವರ್ಷಗಳಿಂದ ಮುಖ್ಯ ಶಾಖೆಗೆ ಸೇರಿಸಲು ಕೇಳುತ್ತಿದ್ದೇವೆ. ಪುಲ್ ವಿನಂತಿಯನ್ನು ಮಾಡಿದ ಸಾರ್ವಜನಿಕ ಥ್ರೆಡ್‌ನಲ್ಲಿ ರೀಸರ್ ಅವರ ಕೊನೆಯ ಕಾಮೆಂಟ್‌ಗೆ ಉತ್ತರಿಸಲಾಗಿಲ್ಲ. ಆದ್ದರಿಂದ ಎಲ್ಲಾ ಮುಂದಿನ ಪ್ರಶ್ನೆಗಳು ನಮಗೆ ಅಲ್ಲ. ನಾವು ನಿರ್ದಿಷ್ಟ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ಗೆ "ವಿಲೀನಗೊಳ್ಳಲು" ಏಕೆ ಬೇಕು ಎಂದು ನನಗೆ ವೈಯಕ್ತಿಕವಾಗಿ ಅರ್ಥವಾಗುತ್ತಿಲ್ಲ. ಲಿನಕ್ಸ್‌ನಲ್ಲಿ, ಬೆಳಕು ಬೆಣೆಯಂತೆ ಒಮ್ಮುಖವಾಗಲಿಲ್ಲ. ಆದ್ದರಿಂದ, ಪ್ರತ್ಯೇಕ ರೆಪೊಸಿಟರಿ ಇದೆ, ಇದರಲ್ಲಿ ವಿವಿಧ OS ಗಳಿಗಾಗಿ ಹಲವಾರು ಶಾಖೆ-ಪೋರ್ಟ್‌ಗಳು ಇರುತ್ತವೆ. ಯಾರಿಗೆ ಬೇಕಾದರೂ ಅನುಗುಣವಾದ ಪೋರ್ಟ್ ಅನ್ನು ಕ್ಲೋನ್ ಮಾಡಬಹುದು ಮತ್ತು ಅದರೊಂದಿಗೆ ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಮಾಡಬಹುದು (ಪರವಾನಗಿಯೊಳಗೆ, ಸಹಜವಾಗಿ). ಒಳ್ಳೆಯದು, ಯಾರಿಗಾದರೂ ಇದು ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ, ಅದು ನನ್ನ ಸಮಸ್ಯೆಯಲ್ಲ. ಈ ಹಂತದಲ್ಲಿ, "ಮುಖ್ಯ ಲಿನಕ್ಸ್ ಕರ್ನಲ್ಗೆ ಪ್ರಚಾರ" ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಲು ನಾನು ಪ್ರಸ್ತಾಪಿಸುತ್ತೇನೆ.
FS ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿನ ಪ್ರಕಟಣೆಗಳು ಪ್ರಸ್ತುತವಾಗಿವೆ, ಆದರೆ ಇಲ್ಲಿಯವರೆಗೆ ನಾನು ನನ್ನ ಹೊಸ ಫಲಿತಾಂಶಗಳಿಗಾಗಿ ಸಮಯವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇನೆ, ಅದನ್ನು ನಾನು ಹೆಚ್ಚಿನ ಆದ್ಯತೆ ಎಂದು ಪರಿಗಣಿಸುತ್ತೇನೆ. ಇನ್ನೊಂದು ವಿಷಯವೆಂದರೆ ನಾನು ಗಣಿತಜ್ಞ, ಮತ್ತು ಗಣಿತಶಾಸ್ತ್ರದಲ್ಲಿ ಯಾವುದೇ ಪ್ರಕಟಣೆಯು ಪ್ರಮೇಯಗಳು ಮತ್ತು ಅವುಗಳ ಪುರಾವೆಗಳ ಸಾರಾಂಶವಾಗಿದೆ. ಪುರಾವೆ ಇಲ್ಲದೆ ಏನನ್ನೂ ಪ್ರಕಟಿಸುವುದು ಕೆಟ್ಟ ಅಭಿರುಚಿಯ ಸಂಕೇತವಾಗಿದೆ. ಎಫ್‌ಎಸ್‌ನ ವಾಸ್ತುಶಿಲ್ಪದ ಬಗ್ಗೆ ಯಾವುದೇ ಹೇಳಿಕೆಯನ್ನು ನಾನು ಸಂಪೂರ್ಣವಾಗಿ ಸಾಬೀತುಪಡಿಸಿದರೆ ಅಥವಾ ನಿರಾಕರಿಸಿದರೆ, ಫಲಿತಾಂಶವು ಅಂತಹ ರಾಶಿಗಳಾಗಿರುತ್ತದೆ, ಅದನ್ನು ಪಡೆಯಲು ಸಾಕಷ್ಟು ಕಷ್ಟವಾಗುತ್ತದೆ. ಯಾರಿಗೆ ಬೇಕು? ಬಹುಶಃ ಅದಕ್ಕಾಗಿಯೇ ಎಲ್ಲವೂ ಅದರ ಹಳೆಯ ರೂಪದಲ್ಲಿ ಮುಂದುವರಿಯುತ್ತದೆ - ಮೂಲ ಕೋಡ್ ಮತ್ತು ಅದಕ್ಕೆ ಕಾಮೆಂಟ್‌ಗಳು.
ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಿಂದ Reiser4 ನಲ್ಲಿ ಹೊಸದೇನಿದೆ?
ಬಹುನಿರೀಕ್ಷಿತ ಸ್ಥಿರತೆ ಅಂತಿಮವಾಗಿ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬಂದಿದೆ. "ಅಳಿಸಲಾಗದ" ಡೈರೆಕ್ಟರಿಗಳಿಗೆ ಕಾರಣವಾದ ದೋಷವು ಕೊನೆಯದಾಗಿ ಕಾಣಿಸಿಕೊಂಡಿದೆ. ತೊಂದರೆಯು ಹ್ಯಾಶ್ ಘರ್ಷಣೆಗಳ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಮತ್ತು ಮರದ ನೋಡ್‌ನಲ್ಲಿ ಡೈರೆಕ್ಟರಿ ದಾಖಲೆಗಳ ನಿರ್ದಿಷ್ಟ ಸ್ಥಳದೊಂದಿಗೆ ಮಾತ್ರ ಕಾಣಿಸಿಕೊಂಡಿದೆ. ಆದಾಗ್ಯೂ, ನಾನು ಇನ್ನೂ ಉತ್ಪಾದನೆಗೆ Reiser4 ಅನ್ನು ಶಿಫಾರಸು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ: ಇದಕ್ಕಾಗಿ ನೀವು ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಯ ನಿರ್ವಾಹಕರೊಂದಿಗೆ ಸಕ್ರಿಯ ಸಂವಹನದೊಂದಿಗೆ ಕೆಲವು ಕೆಲಸವನ್ನು ಮಾಡಬೇಕಾಗಿದೆ.
ನಾವು ಅಂತಿಮವಾಗಿ ನಮ್ಮ ದೀರ್ಘಕಾಲದ ಕಲ್ಪನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ - ವಿಭಿನ್ನ ವಹಿವಾಟು ಮಾದರಿಗಳು. ಹಿಂದೆ, Reiser4 ಕೇವಲ ಒಂದು ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡಲಾದ ಮ್ಯಾಕ್‌ಡೊನಾಲ್ಡ್-ರೈಸರ್ ಮಾದರಿಯನ್ನು ನಡೆಸುತ್ತಿತ್ತು. ಇದು ವಿನ್ಯಾಸ ಸಮಸ್ಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸಿತು. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಅಂತಹ ವಹಿವಾಟಿನ ಮಾದರಿಯಲ್ಲಿ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಸಾಧ್ಯವಿಲ್ಲ - ಅವುಗಳು "ಓವರ್‌ರೈಟ್ ಸೆಟ್" ಎಂಬ ಪರಮಾಣು ಘಟಕದಿಂದ ದೋಷಪೂರಿತವಾಗುತ್ತವೆ. Reiser4 ಪ್ರಸ್ತುತ ಮೂರು ವಹಿವಾಟು ಮಾದರಿಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ (ಬರೆಯಿರಿ-ಎಲ್ಲಿಯಾದರೂ), ಪರಮಾಣು ಘಟಕ ಓವರ್‌ರೈಟ್ ಸೆಟ್ ಸಿಸ್ಟಮ್ ಪುಟಗಳನ್ನು ಮಾತ್ರ ಒಳಗೊಂಡಿದೆ (ಡಿಸ್ಕ್ ಬಿಟ್‌ಮ್ಯಾಪ್‌ಗಳ ಚಿತ್ರಗಳು, ಇತ್ಯಾದಿ), ಅದನ್ನು "ಫೋಟೋಗ್ರಾಫ್" ಮಾಡಲಾಗುವುದಿಲ್ಲ (ಕೋಳಿ ಮತ್ತು ಮೊಟ್ಟೆಯ ಸಮಸ್ಯೆ).
ಆದ್ದರಿಂದ ಚಿತ್ರಗಳನ್ನು ಈಗ ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ ಅರಿತುಕೊಳ್ಳಬಹುದು. ಮತ್ತೊಂದು ವಹಿವಾಟಿನ ಮಾದರಿಯಲ್ಲಿ, ಎಲ್ಲಾ ಮಾರ್ಪಡಿಸಿದ ಪುಟಗಳು ಓವರ್‌ರೈಟ್ ಸೆಟ್‌ಗೆ ಮಾತ್ರ ಹೋಗುತ್ತವೆ (ಅಂದರೆ, ಇದು ಮೂಲಭೂತವಾಗಿ ಶುದ್ಧ ಜರ್ನಲಿಂಗ್ ಆಗಿದೆ). Reiser4 ವಿಭಾಗಗಳ ತ್ವರಿತ ವಿಘಟನೆಯ ಬಗ್ಗೆ ದೂರು ನೀಡಿದವರಿಗೆ ಈ ಮಾದರಿಯಾಗಿದೆ. ಈಗ ಈ ಮಾದರಿಯಲ್ಲಿ ನಿಮ್ಮ ವಿಭಾಗವು ReiserFS (v3) ಗಿಂತ ವೇಗವಾಗಿ ವಿಭಜನೆಯಾಗುವುದಿಲ್ಲ. ಎಲ್ಲಾ ಮೂರು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾದರಿಗಳು, ಕೆಲವು ಮೀಸಲಾತಿಗಳೊಂದಿಗೆ, ಕಾರ್ಯಾಚರಣೆಗಳ ಪರಮಾಣುತ್ವವನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ, ಆದರೆ ಪರಮಾಣು ನಷ್ಟದೊಂದಿಗೆ ಮತ್ತು ವಿಭಾಗದ ಸಮಗ್ರತೆಯನ್ನು ಮಾತ್ರ ಸಂರಕ್ಷಿಸುವ ಮಾದರಿಗಳು ಸಹ ಉಪಯುಕ್ತವಾಗಬಹುದು. ಅಂತಹ ಮಾದರಿಗಳು ಎಲ್ಲಾ ರೀತಿಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ (ಡೇಟಾಬೇಸ್‌ಗಳು, ಇತ್ಯಾದಿ) ಉಪಯುಕ್ತವಾಗಬಹುದು, ಅವುಗಳು ಈಗಾಗಲೇ ಈ ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿವೆ. ಈ ಮಾದರಿಗಳನ್ನು Reiser4 ಗೆ ಸೇರಿಸುವುದು ತುಂಬಾ ಸುಲಭ, ಆದರೆ ನಾನು ಅದನ್ನು ಮಾಡಲಿಲ್ಲ, ಏಕೆಂದರೆ ಯಾರೂ ನನ್ನನ್ನು ಕೇಳಲಿಲ್ಲ, ಮತ್ತು ನನಗೆ ವೈಯಕ್ತಿಕವಾಗಿ ಇದು ಅಗತ್ಯವಿಲ್ಲ.
ಮೆಟಾಡೇಟಾ ಚೆಕ್‌ಸಮ್‌ಗಳು ಕಾಣಿಸಿಕೊಂಡವು ಮತ್ತು ನಾನು ಇತ್ತೀಚೆಗೆ ಅವುಗಳನ್ನು "ಆರ್ಥಿಕ" ಕನ್ನಡಿಗಳು" (ಇನ್ನೂ ಅಸ್ಥಿರವಾದ ವಸ್ತು) ನೊಂದಿಗೆ ಪೂರಕಗೊಳಿಸಿದೆ. ಯಾವುದೇ ಬ್ಲಾಕ್‌ನ ಚೆಕ್‌ಸಮ್ ವಿಫಲವಾದಲ್ಲಿ, Reiser4 ತಕ್ಷಣವೇ ಪ್ರತಿಕೃತಿ ಸಾಧನದಿಂದ ಅನುಗುಣವಾದ ಬ್ಲಾಕ್ ಅನ್ನು ಓದುತ್ತದೆ. ZFS ಮತ್ತು Btrfs ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ: ವಿನ್ಯಾಸವು ಅದನ್ನು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಅಲ್ಲಿ ನೀವು "ಸ್ಕ್ರಬ್" ಎಂಬ ವಿಶೇಷ ಹಿನ್ನೆಲೆ ಸ್ಕ್ಯಾನಿಂಗ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಚಲಾಯಿಸಬೇಕು ಮತ್ತು ಅದು ಸಮಸ್ಯಾತ್ಮಕ ಬ್ಲಾಕ್‌ಗೆ ಬರಲು ಕಾಯಬೇಕು. ಪ್ರೋಗ್ರಾಮರ್ಗಳು ಅಂತಹ ಘಟನೆಗಳನ್ನು ಸಾಂಕೇತಿಕವಾಗಿ "ಊರುಗೋಲು" ಎಂದು ಕರೆಯುತ್ತಾರೆ.
ಮತ್ತು ಅಂತಿಮವಾಗಿ, ವೈವಿಧ್ಯಮಯ ತಾರ್ಕಿಕ ಸಂಪುಟಗಳು ಕಾಣಿಸಿಕೊಂಡಿವೆ, ZFS, Btrfs, ಬ್ಲಾಕ್ ಲೇಯರ್, ಹಾಗೆಯೇ FS+LVM ಸಂಯೋಜನೆಗಳು ತಾತ್ವಿಕವಾಗಿ ಒದಗಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ - ಸಮಾನಾಂತರ ಸ್ಕೇಲಿಂಗ್, O(1) ಡಿಸ್ಕ್ ವಿಳಾಸ ಹಂಚಿಕೆ, ಉಪ ಸಂಪುಟಗಳ ನಡುವೆ ಪಾರದರ್ಶಕ ಡೇಟಾ ವಲಸೆ. ಎರಡನೆಯದು ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಸಹ ಹೊಂದಿದೆ. ಈಗ ನೀವು ನಿಮ್ಮ ವಾಲ್ಯೂಮ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಡ್ರೈವ್‌ಗೆ ಹಾಟೆಸ್ಟ್ ಡೇಟಾವನ್ನು ಸುಲಭವಾಗಿ ಸರಿಸಬಹುದು.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಅಂತಹ ಡ್ರೈವ್‌ಗೆ ಯಾವುದೇ ಕೊಳಕು ಪುಟಗಳನ್ನು ತುರ್ತಾಗಿ ಫ್ಲಶ್ ಮಾಡಲು ಸಾಧ್ಯವಿದೆ, ಇದರಿಂದಾಗಿ ಸಾಮಾನ್ಯವಾಗಿ fsync(2) ಎಂದು ಕರೆಯುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಗಮನಾರ್ಹವಾಗಿ ವೇಗಗೊಳಿಸುತ್ತದೆ. Bcache ಎಂದು ಕರೆಯಲ್ಪಡುವ ಬ್ಲಾಕ್ ಲೇಯರ್ ಕಾರ್ಯವು ಅಂತಹ ಕ್ರಿಯೆಯ ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ ಎಂದು ನಾನು ಗಮನಿಸುತ್ತೇನೆ. ಹೊಸ ತಾರ್ಕಿಕ ಸಂಪುಟಗಳು ನನ್ನ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಆಧರಿಸಿವೆ (ಅನುಗುಣವಾದ ಪೇಟೆಂಟ್‌ಗಳಿವೆ). ಸಾಫ್ಟ್ವೇರ್ ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಸ್ಥಿರವಾಗಿದೆ, ಅದನ್ನು ಪ್ರಯತ್ನಿಸಲು, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಳೆಯಲು ಸಾಕಷ್ಟು ಸಾಧ್ಯವಿದೆ. ಕೇವಲ ಅನಾನುಕೂಲವೆಂದರೆ ಇದೀಗ ನೀವು ವಾಲ್ಯೂಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನವೀಕರಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಎಲ್ಲೋ ಸಂಗ್ರಹಿಸಬೇಕು.
ಇಲ್ಲಿಯವರೆಗೆ ನಾನು ನನ್ನ ಆಲೋಚನೆಗಳನ್ನು 10 ಪ್ರತಿಶತದಷ್ಟು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಮರ್ಥನಾಗಿದ್ದೇನೆ, ಆದರೆ ನಾನು ಅತ್ಯಂತ ಕಷ್ಟಕರವಾದ ವಿಷಯವೆಂದು ಪರಿಗಣಿಸಿದ್ದೇನೆ - ತಾರ್ಕಿಕ ಸಂಪುಟಗಳನ್ನು ರೀಸರ್ 4 ನಲ್ಲಿ ಎಲ್ಲಾ ಮುಂದೂಡಲ್ಪಟ್ಟ ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಒಂದು ಫ್ಲಾಶ್ ಕಾರ್ಯವಿಧಾನದೊಂದಿಗೆ ಸಂಪರ್ಕಿಸುವುದು. ಇದು ಇನ್ನೂ ಪ್ರಾಯೋಗಿಕ "ಫಾರ್ಮ್ಯಾಟ್ 41" ಶಾಖೆಯಲ್ಲಿದೆ.
Reiser4 xfstests ಅನ್ನು ಪಾಸ್ ಮಾಡುತ್ತದೆಯೇ?
ನಾನು ಕೊನೆಯ ಬಿಡುಗಡೆಯನ್ನು ಸಿದ್ಧಪಡಿಸುವಾಗ ಕನಿಷ್ಠ ಅದು ನನಗೆ ಮಾಡಿದೆ.
ಪ್ಲಗಿನ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು Reiser4 ಅನ್ನು ನೆಟ್ವರ್ಕ್ (ಕ್ಲಸ್ಟರ್) FS ಮಾಡಲು ತಾತ್ವಿಕವಾಗಿ ಸಾಧ್ಯವೇ?
ಇದು ಸಾಧ್ಯ, ಮತ್ತು ಅಗತ್ಯವೂ ಸಹ! ಸರಿಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಸ್ಥಳೀಯ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಆಧರಿಸಿ ನೀವು ನೆಟ್ವರ್ಕ್ ಫೈಲ್ ಅನ್ನು ರಚಿಸಿದರೆ, ಫಲಿತಾಂಶವು ತುಂಬಾ ಪ್ರಭಾವಶಾಲಿಯಾಗಿರುತ್ತದೆ! ಆಧುನಿಕ ನೆಟ್ವರ್ಕ್ ಎಫ್‌ಎಸ್‌ಗಳಲ್ಲಿ, ಯಾವುದೇ ಸ್ಥಳೀಯ ಎಫ್ಎಸ್ ಬಳಸಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾದ ಬ್ಯಾಕೆಂಡ್ ಸ್ಟೋರೇಜ್ ಮಟ್ಟದ ಉಪಸ್ಥಿತಿಯಿಂದ ನಾನು ತೃಪ್ತನಾಗುವುದಿಲ್ಲ. ಈ ಮಟ್ಟದ ಅಸ್ತಿತ್ವವು ಸಂಪೂರ್ಣವಾಗಿ ನ್ಯಾಯಸಮ್ಮತವಲ್ಲ. ನೆಟ್ವರ್ಕ್ FS ನೇರವಾಗಿ ಬ್ಲಾಕ್ ಲೇಯರ್ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಬೇಕು ಮತ್ತು ಯಾವುದೇ ಇತರ ಸೇವಾ ಫೈಲ್ಗಳನ್ನು ರಚಿಸಲು ಸ್ಥಳೀಯ FS ಅನ್ನು ಕೇಳಬಾರದು!
ಸಾಮಾನ್ಯವಾಗಿ, ಕಡತ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಸ್ಥಳೀಯ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಆಗಿ ವಿಭಜಿಸುವುದು ದುಷ್ಟರಿಂದ. ಮೂವತ್ತು ವರ್ಷಗಳ ಹಿಂದೆ ಬಳಸಿದ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಅಪೂರ್ಣತೆಯಿಂದ ಇದು ಹುಟ್ಟಿಕೊಂಡಿತು ಮತ್ತು ಅದರ ಸ್ಥಳದಲ್ಲಿ ಇನ್ನೂ ಏನನ್ನೂ ಪ್ರಸ್ತಾಪಿಸಲಾಗಿಲ್ಲ. ಅನಗತ್ಯ ಸಾಫ್ಟ್ವೇರ್ ಘಟಕಗಳ (ವಿವಿಧ ಸೇವೆಗಳು, ಇತ್ಯಾದಿ) ಕಾಣಿಸಿಕೊಳ್ಳಲು ಇದು ಕಾರಣವಾಗಿದೆ. ಉತ್ತಮ ರೀತಿಯಲ್ಲಿ, ಕರ್ನಲ್ ಮಾಡ್ಯೂಲ್ ರೂಪದಲ್ಲಿ ಕೇವಲ ಒಂದು ಎಫ್ಎಸ್ ಇರಬೇಕು ಮತ್ತು ಪ್ರತಿ ಗಣಕದಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾದ ಬಳಕೆದಾರರ ಉಪಯುಕ್ತತೆಗಳ ಒಂದು ಸೆಟ್ - ಕ್ಲಸ್ಟರ್ ನೋಡ್. ಈ ಎಫ್ಎಸ್ ಸ್ಥಳೀಯ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಎರಡೂ ಆಗಿದೆ. ಮತ್ತು ಹೆಚ್ಚೇನೂ ಇಲ್ಲ!
Linux ನಲ್ಲಿ Reiser4 ನೊಂದಿಗೆ ಏನೂ ಕೆಲಸ ಮಾಡದಿದ್ದರೆ, ನಾನು FreeBSD ಗಾಗಿ FS ಅನ್ನು ನೀಡಲು ಬಯಸುತ್ತೇನೆ (ಹಿಂದಿನ ಸಂದರ್ಶನದ ಉಲ್ಲೇಖ: “...FreeBSD... ಶೈಕ್ಷಣಿಕ ಬೇರುಗಳನ್ನು ಹೊಂದಿದೆ... ಮತ್ತು ಇದರರ್ಥ ನಾವು ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ ಸಾಮಾನ್ಯ ಭಾಷೆಯನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ”) ?
ಆದ್ದರಿಂದ, ನಾವು ಈಗಷ್ಟೇ ಕಂಡುಕೊಂಡಂತೆ, ಎಲ್ಲವೂ ಈಗಾಗಲೇ ಲಿನಕ್ಸ್‌ನೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ: ನಮ್ಮ ರೆಪೊಸಿಟರಿಯ ಮಾಸ್ಟರ್ ಶಾಖೆಯ ರೂಪದಲ್ಲಿ ಅದಕ್ಕಾಗಿ ಪ್ರತ್ಯೇಕ ಕೆಲಸ ಮಾಡುವ Reiser4 ಪೋರ್ಟ್ ಇದೆ. ನಾನು FreeBSD ಬಗ್ಗೆ ಮರೆತಿಲ್ಲ! ಆಫರ್! FreeBSD ಯ ಒಳಭಾಗವನ್ನು ಚೆನ್ನಾಗಿ ತಿಳಿದಿರುವವರೊಂದಿಗೆ ನಿಕಟವಾಗಿ ಕೆಲಸ ಮಾಡಲು ನಾನು ಸಿದ್ಧನಿದ್ದೇನೆ. ಅಂದಹಾಗೆ: ಅವರ ಸಮುದಾಯದ ಬಗ್ಗೆ ನಾನು ನಿಜವಾಗಿಯೂ ಇಷ್ಟಪಡುವ ವಿಷಯವೆಂದರೆ ಅಲ್ಲಿ ನಿರ್ಧಾರಗಳನ್ನು ಸ್ವತಂತ್ರ ತಜ್ಞರ ನವೀಕರಿಸಿದ ಮಂಡಳಿಯು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಇದು ಒಬ್ಬ ಶಾಶ್ವತ ವ್ಯಕ್ತಿಯ ಸರ್ಕಾರದ ವಂಚನೆಯೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವನ್ನು ಹೊಂದಿಲ್ಲ.
ಇಂದು ನೀವು Linux ಬಳಕೆದಾರರ ಸಮುದಾಯವನ್ನು ಹೇಗೆ ರೇಟ್ ಮಾಡುತ್ತೀರಿ? ಇದು ಹೆಚ್ಚು "ಪಾಪ್" ಆಗಿ ಮಾರ್ಪಟ್ಟಿದೆಯೇ?
ನನ್ನ ಕೆಲಸದ ಸ್ವರೂಪವನ್ನು ಗಮನಿಸಿದರೆ, ಇದನ್ನು ನಿರ್ಣಯಿಸುವುದು ನನಗೆ ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿದೆ. ಹೆಚ್ಚಾಗಿ ಬಳಕೆದಾರರು ದೋಷ ವರದಿಗಳು ಮತ್ತು ವಿಭಾಗವನ್ನು ಸರಿಪಡಿಸಲು ವಿನಂತಿಗಳೊಂದಿಗೆ ನನ್ನ ಬಳಿಗೆ ಬರುತ್ತಾರೆ. ಬಳಕೆದಾರರಂತೆ ಬಳಕೆದಾರರು. ಕೆಲವರು ಹೆಚ್ಚು ಬುದ್ಧಿವಂತರು, ಕೆಲವರು ಕಡಿಮೆ. ಎಲ್ಲರನ್ನೂ ಒಂದೇ ರೀತಿ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಸರಿ, ಬಳಕೆದಾರರು ನನ್ನ ಸೂಚನೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದರೆ, ನನ್ನನ್ನು ಕ್ಷಮಿಸಿ: ನಿರ್ಲಕ್ಷಿಸುವ ಆದೇಶವನ್ನು ನನ್ನ ಕಡೆಯಿಂದ ನಮೂದಿಸಲಾಗುತ್ತದೆ.
ಮುಂದಿನ ಐದರಿಂದ ಹತ್ತು ವರ್ಷಗಳವರೆಗೆ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳ ಅಭಿವೃದ್ಧಿಯನ್ನು ಊಹಿಸಲು ಸಾಧ್ಯವೇ? FS ಡೆವಲಪರ್‌ಗಳು ಎದುರಿಸಬಹುದಾದ ಪ್ರಮುಖ ಸವಾಲುಗಳು ಯಾವುವು ಎಂದು ನೀವು ಯೋಚಿಸುತ್ತೀರಿ?
ಹೌದು, ಅಂತಹ ಮುನ್ಸೂಚನೆಯನ್ನು ಮಾಡುವುದು ಕಷ್ಟವೇನಲ್ಲ. ದೀರ್ಘಕಾಲದವರೆಗೆ ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳ ಯಾವುದೇ ಅಭಿವೃದ್ಧಿಯಾಗಿಲ್ಲ. ಅಂತಹವುಗಳ ನೋಟವನ್ನು ಮಾತ್ರ ರಚಿಸಲಾಗಿದೆ. ಸ್ಥಳೀಯ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳ ಡೆವಲಪರ್‌ಗಳು ಕಳಪೆ ವಿನ್ಯಾಸದೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದರು. ಇಲ್ಲಿ ಒಂದು ಎಚ್ಚರಿಕೆಯನ್ನು ಮಾಡಬೇಕಾಗಿದೆ. "ಸಂಗ್ರಹಣೆ", "ನೆಕ್ಕುವಿಕೆ" ಮತ್ತು ಕೋಡ್‌ನ ಪೋರ್ಟಿಂಗ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಅಭಿವೃದ್ಧಿ ಎಂದು ನಾನು ಪರಿಗಣಿಸುವುದಿಲ್ಲ. ಮತ್ತು ನಾನು ಈಗಾಗಲೇ ವಿವರಿಸಿರುವ ಕಾರಣಗಳಿಗಾಗಿ ನಾನು "Btrfs" ಎಂಬ ತಪ್ಪುಗ್ರಹಿಕೆಯನ್ನು ಬೆಳವಣಿಗೆಯಾಗಿ ವರ್ಗೀಕರಿಸುವುದಿಲ್ಲ.
ಪ್ರತಿಯೊಂದು ಪ್ಯಾಚ್ ತನ್ನ ಸಮಸ್ಯೆಗಳನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸುತ್ತದೆ. ಸರಿ. ಮತ್ತು ಯಾವಾಗಲೂ ವಿವಿಧ ರೀತಿಯ "ಸುವಾರ್ತಾಬೋಧಕರು" ಇರುತ್ತಾರೆ, ಅವರಿಗೆ "ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ." ಮೂಲತಃ, ಇವರು ಶಾಲಾ ಮಕ್ಕಳು ಮತ್ತು ವಿದ್ಯಾರ್ಥಿಗಳು ಉಪನ್ಯಾಸಗಳನ್ನು ಬಿಡುತ್ತಾರೆ. ಕೇವಲ ಊಹಿಸಿ: ಇದು ಅವನಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದರೆ ಪ್ರೊಫೆಸರ್ ಮಾಡುವುದಿಲ್ಲ. ಇದು ಎಂತಹ ಅಡ್ರಿನಾಲಿನ್ ರಶ್! ನನ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ, "ಕುಶಲಕರ್ಮಿಗಳು" ಉತ್ಸಾಹದಿಂದ Btrfs ನ ಅದ್ಭುತ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು systemd, ಡಾಕರ್, ಇತ್ಯಾದಿಗಳಂತಹ ಎಲ್ಲಾ ರೀತಿಯ ಲೇಯರ್‌ಗಳಲ್ಲಿ "ಸ್ಕ್ರೂ" ಮಾಡಲು ಧಾವಿಸುತ್ತಾರೆ. - ಇದು ಈಗಾಗಲೇ ಮೆಟಾಸ್ಟೇಸ್‌ಗಳನ್ನು ಹೋಲುತ್ತದೆ.
ಈಗ ಐದರಿಂದ ಹತ್ತು ವರ್ಷಗಳ ಮುನ್ಸೂಚನೆಯನ್ನು ಮಾಡಲು ಪ್ರಯತ್ನಿಸೋಣ. Reiser4 ನಲ್ಲಿ ನಾವು ಏನು ಮಾಡುತ್ತೇವೆ ಎಂದು ನಾನು ಈಗಾಗಲೇ ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಪಟ್ಟಿ ಮಾಡಿದ್ದೇನೆ. ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಿಂದ ಸ್ಥಳೀಯ ಎಫ್ಎಸ್ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಮುಖ್ಯ ಸವಾಲು ಎಂದರೆ (ಹೌದು, ಇದು ಈಗಾಗಲೇ ಮಾರ್ಪಟ್ಟಿದೆ) ಸಂಬಳಕ್ಕಾಗಿ ಯೋಗ್ಯವಾದ ಕೆಲಸವನ್ನು ಮಾಡಲು ಅಸಮರ್ಥತೆ. ಡೇಟಾ ಸಂಗ್ರಹಣೆಯ ಕ್ಷೇತ್ರದಲ್ಲಿ ಯಾವುದೇ ಆಲೋಚನೆಗಳಿಲ್ಲದೆ, ಅವರು ಈ ದುರದೃಷ್ಟಕರ VFS, XFS ಮತ್ತು ext4 ಅನ್ನು ಪ್ಯಾಚ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ. ವಿಎಫ್‌ಎಸ್‌ನೊಂದಿಗಿನ ಪರಿಸ್ಥಿತಿಯು ಈ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ವಿಶೇಷವಾಗಿ ಹಾಸ್ಯಮಯವಾಗಿ ಕಾಣುತ್ತದೆ, ಯಾವುದೇ ಬಾಣಸಿಗರು ಇಲ್ಲದ ಮತ್ತು ಯಾವುದೇ ಬಾಣಸಿಗರನ್ನು ನಿರೀಕ್ಷಿಸದ ರೆಸ್ಟೋರೆಂಟ್‌ನ ಉನ್ಮಾದದ ಆಧುನೀಕರಣವನ್ನು ನೆನಪಿಸುತ್ತದೆ.
ಈಗ VFS ಕೋಡ್, ಯಾವುದೇ ಷರತ್ತುಗಳಿಲ್ಲದೆ, ಅದೇ ಸಮಯದಲ್ಲಿ ಹಲವಾರು ಮೆಮೊರಿ ಪುಟಗಳನ್ನು ಲಾಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅವುಗಳ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಆಧಾರವಾಗಿರುವ FS ಅನ್ನು ಆಹ್ವಾನಿಸುತ್ತದೆ. ಅಳಿಸುವ ಕಾರ್ಯಾಚರಣೆಗಳಲ್ಲಿ Ext4 ನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಇದನ್ನು ಪರಿಚಯಿಸಲಾಗಿದೆ, ಆದರೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾದಂತೆ, ಅಂತಹ ಏಕಕಾಲಿಕ ಲಾಕಿಂಗ್ ಸುಧಾರಿತ ವಹಿವಾಟು ಮಾದರಿಗಳೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಅಂದರೆ, ಕರ್ನಲ್‌ನಲ್ಲಿ ಕೆಲವು ಸ್ಮಾರ್ಟ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗೆ ಸರಳವಾಗಿ ಬೆಂಬಲವನ್ನು ಸೇರಿಸಲು ನಿಮಗೆ ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಲಿನಕ್ಸ್‌ನ ಇತರ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಪರಿಸ್ಥಿತಿ ಏನೆಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಇಲ್ಲಿನ ಯಾವುದೇ ಅಭಿವೃದ್ಧಿಯು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಟೊರ್ವಾಲ್ಡ್ಸ್ ಅನುಸರಿಸಿದ ನೀತಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಸಾಧ್ಯತೆಯಿಲ್ಲ (ಶೈಕ್ಷಣಿಕ ಯೋಜನೆಗಳನ್ನು ಹೊರಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ಸ್ಕ್ಯಾಮರ್‌ಗಳು ಯಾವ ಬಿ-ಟ್ರೀ , ಟ್ರಸ್ಟ್‌ನ ಅಂತ್ಯವಿಲ್ಲದ ಕ್ರೆಡಿಟ್‌ಗಳನ್ನು ನೀಡಲಾಗುತ್ತದೆ ಎಂದು ತಿಳಿದಿಲ್ಲ). ಆದ್ದರಿಂದ, ನಿಧಾನಗತಿಯ ಕೊಳೆಯುವಿಕೆಗೆ ಕೋರ್ಸ್ ಅನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ. ಸಹಜವಾಗಿ, ಅವರು ಅದನ್ನು "ಅಭಿವೃದ್ಧಿ" ಎಂದು ರವಾನಿಸಲು ತಮ್ಮ ಎಲ್ಲಾ ಶಕ್ತಿಯಿಂದ ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ.
ಇದಲ್ಲದೆ, ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳ "ಪಾಲಕರು", ನೀವು ಕೇವಲ "ಸಂಗ್ರಹಣೆ" ಯಿಂದ ಹೆಚ್ಚು ಗಳಿಸುವುದಿಲ್ಲ ಎಂದು ಅರಿತುಕೊಂಡು, ಹೆಚ್ಚು ಲಾಭದಾಯಕ ವ್ಯವಹಾರದಲ್ಲಿ ತಮ್ಮ ಕೈಯನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ಇವುಗಳು ನಿಯಮದಂತೆ, ವಿತರಿಸಿದ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳು ಮತ್ತು ವರ್ಚುವಲೈಸೇಶನ್. ಬಹುಶಃ ಅವರು ಫ್ಯಾಶನ್ ZFS ಅನ್ನು ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಬೇರೆಡೆಗೆ ಪೋರ್ಟ್ ಮಾಡುತ್ತಾರೆ. ಆದರೆ ಇದು, ಅಪ್‌ಸ್ಟ್ರೀಮ್‌ನಿಂದ ಎಲ್ಲಾ ಎಫ್‌ಎಸ್‌ಗಳಂತೆ, ಹೊಸ ವರ್ಷದ ಮರವನ್ನು ಹೋಲುತ್ತದೆ: ನೀವು ಇತರ ಕೆಲವು ಸಣ್ಣ ವಸ್ತುಗಳನ್ನು ಮೇಲೆ ಸ್ಥಗಿತಗೊಳಿಸಬಹುದಾದರೆ, ನೀವು ಯಾವುದೇ ಆಳವನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ZFS ಅನ್ನು ಆಧರಿಸಿ ಗಂಭೀರವಾದ ಎಂಟರ್‌ಪ್ರೈಸ್ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಿದೆ ಎಂದು ನಾನು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತೇನೆ, ಆದರೆ ನಾವು ಈಗ ಭವಿಷ್ಯದ ಬಗ್ಗೆ ಚರ್ಚಿಸುತ್ತಿರುವುದರಿಂದ, ಈ ವಿಷಯದಲ್ಲಿ ZFS ಹತಾಶವಾಗಿದೆ ಎಂದು ನಾನು ದುಃಖದಿಂದ ಹೇಳಬಲ್ಲೆ: ಅವರ ವರ್ಚುವಲ್ ಸಾಧನಗಳೊಂದಿಗೆ, ಹುಡುಗರು ಆಮ್ಲಜನಕವನ್ನು ಕಡಿತಗೊಳಿಸಿದ್ದಾರೆ ಮತ್ತಷ್ಟು ಅಭಿವೃದ್ಧಿಗಾಗಿ ತಮ್ಮನ್ನು ಮತ್ತು ಭವಿಷ್ಯದ ಪೀಳಿಗೆಗೆ. ZFS ಹಿಂದಿನ ವಿಷಯವಾಗಿದೆ. ಮತ್ತು ext4 ಮತ್ತು XFS ಹಿಂದಿನ ದಿನವೂ ಅಲ್ಲ.
"ಮುಂದಿನ ಪೀಳಿಗೆಯ ಲಿನಕ್ಸ್ ಫೈಲ್ ಸಿಸ್ಟಮ್" ಎಂಬ ಸಂವೇದನಾಶೀಲ ಪರಿಕಲ್ಪನೆಯ ಬಗ್ಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಪ್ರಸ್ತಾಪಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ. ಲಿನಕ್ಸ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಅಕ್ಷರಗಳ ಹಿಂದೆ "ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳ ಭವಿಷ್ಯವನ್ನು ಪಿನ್ ಮಾಡಲು" ಅವಕಾಶಕ್ಕಾಗಿ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ರಾಜಕೀಯ ಮತ್ತು ಮಾರುಕಟ್ಟೆ ಯೋಜನೆಯಾಗಿದೆ. ವಾಸ್ತವವೆಂದರೆ ಲಿನಕ್ಸ್ "ಕೇವಲ ಮೋಜಿಗಾಗಿ" ಆಗಿತ್ತು. ಆದರೆ ಈಗ ಇದು ಪ್ರಾಥಮಿಕವಾಗಿ ಹಣ ಮಾಡುವ ಯಂತ್ರವಾಗಿದೆ. ಸಾಧ್ಯವಿರುವ ಎಲ್ಲದರ ಮೇಲೆ ಅವುಗಳನ್ನು ತಯಾರಿಸಲಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಉತ್ತಮ ಸಾಫ್ಟ್ವೇರ್ ಉತ್ಪನ್ನವನ್ನು ರಚಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ, ಆದರೆ ಸ್ಮಾರ್ಟ್ “ಡೆವಲಪರ್‌ಗಳು” ಯಾವುದೇ ಒತ್ತಡದ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಬಹಳ ಹಿಂದೆಯೇ ಅರಿತುಕೊಂಡಿದ್ದಾರೆ: ನೀವು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಮಾರಾಟ ಮಾಡಬಹುದು, ಅದನ್ನು ಎಲ್ಲಾ ರೀತಿಯ ಸಾರ್ವಜನಿಕರಿಗೆ ಘೋಷಿಸಲಾಗಿದೆ ಮತ್ತು ಪ್ರಚಾರ ಮಾಡಲಾಗಿದೆ. ಘಟನೆಗಳು - ಮುಖ್ಯ ವಿಷಯವೆಂದರೆ ಪ್ರಸ್ತುತಿ ಸ್ಲೈಡ್‌ಗಳು ಹೆಚ್ಚು “ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು” ಹೊಂದಿರಬೇಕು.
ಫೈಲ್ ಸಿಸ್ಟಮ್ಸ್ ಇದಕ್ಕಾಗಿ ಪರಿಪೂರ್ಣವಾಗಿದೆ, ಏಕೆಂದರೆ ನೀವು ಫಲಿತಾಂಶದ ಮೇಲೆ ಹತ್ತು ವರ್ಷಗಳವರೆಗೆ ಸುರಕ್ಷಿತವಾಗಿ ಚೌಕಾಶಿ ಮಾಡಬಹುದು. ಒಳ್ಳೆಯದು, ಈ ಫಲಿತಾಂಶದ ಕೊರತೆಯ ಬಗ್ಗೆ ಯಾರಾದರೂ ನಂತರ ದೂರು ನೀಡಿದರೆ, ಅವನು ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ! ಇದು ಹಣಕಾಸಿನ ಪಿರಮಿಡ್ ಅನ್ನು ನೆನಪಿಸುತ್ತದೆ: ಮೇಲ್ಭಾಗದಲ್ಲಿ ಈ ಅವ್ಯವಸ್ಥೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ ಸಾಹಸಿಗರು ಮತ್ತು "ಅದೃಷ್ಟವಂತರು" ಕೆಲವರು: ಅವರು "ಲಾಭಾಂಶಗಳನ್ನು ಹಿಂತೆಗೆದುಕೊಂಡರು," ಅಂದರೆ. ಅಭಿವೃದ್ಧಿಗಾಗಿ ಹಣವನ್ನು ಪಡೆದರು, ವ್ಯವಸ್ಥಾಪಕರಾಗಿ ಉತ್ತಮ ಸಂಬಳದ ಕೆಲಸವನ್ನು ಪಡೆದರು, ಸಮ್ಮೇಳನಗಳಲ್ಲಿ "ತೋರಿಸಿದರು", ಇತ್ಯಾದಿ.
ಮುಂದೆ "ದುರದೃಷ್ಟಕರ" ಯಾರು ಬರುತ್ತಾರೆ: ಅವರು ನಷ್ಟವನ್ನು ಎಣಿಸುತ್ತಾರೆ, ಬಳಕೆಯಾಗದ ಸಾಫ್ಟ್ವೇರ್ ಉತ್ಪನ್ನವನ್ನು ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸುವ ಪರಿಣಾಮಗಳನ್ನು ಎದುರಿಸುತ್ತಾರೆ, "ಇತ್ಯಾದಿ. ಅವುಗಳಲ್ಲಿ ಇನ್ನೂ ಹಲವು ಇವೆ. ಒಳ್ಳೆಯದು, ಪಿರಮಿಡ್ನ ತಳದಲ್ಲಿ ನಿಷ್ಪ್ರಯೋಜಕ ಕೋಡ್ ಅನ್ನು "ಗರಗಸ" ಮಾಡುವ ಡೆವಲಪರ್ಗಳ ಒಂದು ದೊಡ್ಡ ಸಮೂಹವಿದೆ. ಅವರು ದೊಡ್ಡ ಸೋತವರು, ಏಕೆಂದರೆ ವ್ಯರ್ಥ ಸಮಯವನ್ನು ಹಿಂತಿರುಗಿಸಲಾಗುವುದಿಲ್ಲ. ಅಂತಹ ಪಿರಮಿಡ್‌ಗಳು ಟೊರ್ವಾಲ್ಡ್ಸ್ ಮತ್ತು ಅವನ ಸಹವರ್ತಿಗಳಿಗೆ ಅತ್ಯಂತ ಪ್ರಯೋಜನಕಾರಿ. ಮತ್ತು ಈ ಪಿರಮಿಡ್‌ಗಳು ಹೆಚ್ಚು, ಅವರಿಗೆ ಉತ್ತಮ. ಅಂತಹ ಪಿರಮಿಡ್‌ಗಳನ್ನು ಪೋಷಿಸಲು, ಯಾವುದನ್ನಾದರೂ ಕೋರ್‌ಗೆ ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಸಹಜವಾಗಿ, ಸಾರ್ವಜನಿಕವಾಗಿ ಅವರು ವಿರುದ್ಧವಾಗಿ ಹೇಳುತ್ತಾರೆ. ಆದರೆ ನಾನು ಮಾತುಗಳಿಂದ ಅಲ್ಲ ಕ್ರಿಯೆಗಳಿಂದ ನಿರ್ಣಯಿಸುತ್ತೇನೆ.
ಆದ್ದರಿಂದ, "ಲಿನಕ್ಸ್‌ನಲ್ಲಿನ ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳ ಭವಿಷ್ಯ" ಇನ್ನೂ ಹೆಚ್ಚು ಪ್ರಚಾರ ಮಾಡಲಾದ, ಆದರೆ ಅಷ್ಟೇನೂ ಬಳಸಲಾಗದ ಸಾಫ್ಟ್ವೇರ್ ಆಗಿದೆ. Btrfs ನಂತರ, ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ, ಅಂತಹ "ಭವಿಷ್ಯದ" ಸ್ಥಳವನ್ನು Bcachefs ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಇದು ಫೈಲ್ ಸಿಸ್ಟಮ್ನೊಂದಿಗೆ Linux ಬ್ಲಾಕ್ ಪದರವನ್ನು ದಾಟಲು ಮತ್ತೊಂದು ಪ್ರಯತ್ನವಾಗಿದೆ (ಕೆಟ್ಟ ಉದಾಹರಣೆ ಸಾಂಕ್ರಾಮಿಕವಾಗಿದೆ). ಮತ್ತು ವಿಶಿಷ್ಟವಾದದ್ದು: Btrfs ನಲ್ಲಿನ ಅದೇ ಸಮಸ್ಯೆಗಳಿವೆ. ನಾನು ಇದನ್ನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಅನುಮಾನಿಸಿದೆ, ಮತ್ತು ನಂತರ ಹೇಗಾದರೂ ನಾನು ವಿರೋಧಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಮತ್ತು ಕೋಡ್ ಅನ್ನು ನೋಡಿದೆ - ಇದು ನಿಜ!
Bcachefs ಮತ್ತು Btrfs ನ ಲೇಖಕರು, ತಮ್ಮ FS ಅನ್ನು ರಚಿಸುವಾಗ, ಇತರ ಜನರ ಮೂಲಗಳನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸುತ್ತಾರೆ, ಅವರ ಬಗ್ಗೆ ಸ್ವಲ್ಪ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಪರಿಸ್ಥಿತಿಯು ಮಕ್ಕಳ ಆಟ "ಮುರಿದ ಫೋನ್" ಅನ್ನು ನೆನಪಿಸುತ್ತದೆ. ಮತ್ತು ಈ ಕೋಡ್ ಅನ್ನು ಕರ್ನಲ್‌ನಲ್ಲಿ ಹೇಗೆ ಸೇರಿಸಲಾಗುವುದು ಎಂದು ನಾನು ಸ್ಥೂಲವಾಗಿ ಊಹಿಸಬಲ್ಲೆ. ವಾಸ್ತವವಾಗಿ, ಯಾರೂ "ಕುಂಟೆಗಳನ್ನು" ನೋಡುವುದಿಲ್ಲ (ಎಲ್ಲರೂ ನಂತರ ಅವರ ಮೇಲೆ ಹೆಜ್ಜೆ ಹಾಕುತ್ತಾರೆ). ಕೋಡ್‌ನ ಶೈಲಿ, ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಉಲ್ಲಂಘನೆಗಳ ಆರೋಪಗಳು ಇತ್ಯಾದಿಗಳ ಬಗ್ಗೆ ಹಲವಾರು ಕ್ವಿಬಲ್‌ಗಳ ನಂತರ, ಲೇಖಕರ “ನಿಷ್ಠೆ”, ಅವರು ಇತರ ಡೆವಲಪರ್‌ಗಳೊಂದಿಗೆ ಎಷ್ಟು ಚೆನ್ನಾಗಿ “ಸಂವಹಿಸುತ್ತಾರೆ” ಮತ್ತು ಇದೆಲ್ಲವೂ ಎಷ್ಟು ಯಶಸ್ವಿಯಾಗಿ ಮಾಡಬಹುದು ಎಂಬುದರ ಕುರಿತು ತೀರ್ಮಾನವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ. ನಂತರ ನಿಗಮಗಳಿಗೆ ಮಾರಲಾಗುತ್ತದೆ.
ಅಂತಿಮ ಫಲಿತಾಂಶವು ಯಾರಿಗೂ ಆಸಕ್ತಿಯನ್ನುಂಟು ಮಾಡುವುದಿಲ್ಲ. ಇಪ್ಪತ್ತು ವರ್ಷಗಳ ಹಿಂದೆ, ಬಹುಶಃ, ನಾನು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ, ಆದರೆ ಈಗ ಪ್ರಶ್ನೆಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ಕೇಳಲಾಗುತ್ತದೆ: ಮುಂದಿನ ಹತ್ತು ವರ್ಷಗಳಲ್ಲಿ ಕೆಲವು ಜನರಿಗೆ ಉದ್ಯೋಗ ನೀಡುವಂತೆ ಇದನ್ನು ಪ್ರಚಾರ ಮಾಡಲು ಸಾಧ್ಯವೇ? ಮತ್ತು, ಅಯ್ಯೋ, ಅಂತಿಮ ಫಲಿತಾಂಶದ ಬಗ್ಗೆ ಆಶ್ಚರ್ಯಪಡುವುದು ವಾಡಿಕೆಯಲ್ಲ.
ಸಾಮಾನ್ಯವಾಗಿ, ಮೊದಲಿನಿಂದಲೂ ನಿಮ್ಮ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಮರುಶೋಧಿಸಲು ಪ್ರಾರಂಭಿಸುವುದರ ವಿರುದ್ಧ ನಾನು ಬಲವಾಗಿ ಸಲಹೆ ನೀಡುತ್ತೇನೆ. ಏಕೆಂದರೆ ಹತ್ತು ವರ್ಷಗಳಲ್ಲಿ ಏನಾದರೂ ಸ್ಪರ್ಧಾತ್ಮಕತೆಯನ್ನು ಪಡೆಯಲು ಗಮನಾರ್ಹ ಹಣಕಾಸಿನ ಹೂಡಿಕೆಗಳು ಸಹ ಸಾಕಾಗುವುದಿಲ್ಲ. ಸಹಜವಾಗಿ, ನಾನು ಗಂಭೀರವಾದ ಯೋಜನೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ ಮತ್ತು ಕರ್ನಲ್ಗೆ "ತಳ್ಳಲು" ಉದ್ದೇಶಿಸಿರುವ ಬಗ್ಗೆ ಅಲ್ಲ. ಆದ್ದರಿಂದ, ನಿಮ್ಮನ್ನು ವ್ಯಕ್ತಪಡಿಸಲು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗವೆಂದರೆ ನಮ್ಮಂತೆ ನೈಜ ಬೆಳವಣಿಗೆಗಳಿಗೆ ಸೇರುವುದು. ಸಹಜವಾಗಿ, ಇದನ್ನು ಮಾಡುವುದು ಸುಲಭವಲ್ಲ - ಆದರೆ ಯಾವುದೇ ಉನ್ನತ ಮಟ್ಟದ ಯೋಜನೆಯಲ್ಲಿ ಇದು ಸಂಭವಿಸುತ್ತದೆ.
ಮೊದಲಿಗೆ, ನಾನು ನೀಡುವ ಸಮಸ್ಯೆಯನ್ನು ನೀವು ಸ್ವತಂತ್ರವಾಗಿ ನಿವಾರಿಸಬೇಕಾಗಿದೆ. ಅದರ ನಂತರ, ನಿಮ್ಮ ಉದ್ದೇಶಗಳ ಗಂಭೀರತೆಯನ್ನು ಮನವರಿಕೆ ಮಾಡಿ, ನಾನು ಸಹಾಯ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತೇನೆ. ಸಾಂಪ್ರದಾಯಿಕವಾಗಿ, ನಾವು ನಮ್ಮ ಸ್ವಂತ ಬೆಳವಣಿಗೆಗಳನ್ನು ಮಾತ್ರ ಬಳಸುತ್ತೇವೆ. ವಿನಾಯಿತಿಗಳು ಸಂಕೋಚನ ಕ್ರಮಾವಳಿಗಳು ಮತ್ತು ಕೆಲವು ಹ್ಯಾಶ್ ಕಾರ್ಯಗಳು. ನಾವು ಕಾನ್ಫರೆನ್ಸ್‌ಗಳಿಗೆ ಪ್ರಯಾಣಿಸಲು ಡೆವಲಪರ್‌ಗಳನ್ನು ಕಳುಹಿಸುವುದಿಲ್ಲ, ಮತ್ತು ನಂತರ ನಾವು ಕುಳಿತುಕೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಇತರ ಜನರ ಆಲೋಚನೆಗಳನ್ನು ("ಬಹುಶಃ ಏನಾಗಬಹುದು") ಸಂಯೋಜಿಸುವುದಿಲ್ಲ, ಹೆಚ್ಚಿನ ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ಗಳಲ್ಲಿ ವಾಡಿಕೆಯಂತೆ.
ನಾವು ಎಲ್ಲಾ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ನಾವೇ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇವೆ. ಡೇಟಾ ಶೇಖರಣಾ ವಿಜ್ಞಾನದ ಬೀಜಗಣಿತ ಮತ್ತು ಸಂಯೋಜಿತ ಅಂಶಗಳಲ್ಲಿ ನಾನು ಪ್ರಸ್ತುತ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ, ಸೀಮಿತ ಕ್ಷೇತ್ರಗಳು, ಅಸಿಂಪ್ಟೋಟಿಕ್ಸ್, ಅಸಮಾನತೆಗಳ ಪುರಾವೆ. ಸಾಮಾನ್ಯ ಪ್ರೋಗ್ರಾಮರ್ಗಳಿಗೆ ಕೆಲಸವೂ ಇದೆ, ಆದರೆ ನಾನು ಈಗಿನಿಂದಲೇ ನಿಮಗೆ ಎಚ್ಚರಿಕೆ ನೀಡಬೇಕು: "ಮತ್ತೊಂದು ಎಫ್ಎಸ್ ಅನ್ನು ನೋಡಿ ಮತ್ತು ಅದೇ ರೀತಿ ಮಾಡಿ" ಎಲ್ಲಾ ಸಲಹೆಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತದೆ. VFS ಮೂಲಕ ಲಿನಕ್ಸ್‌ನೊಂದಿಗೆ ನಿಕಟವಾದ ಏಕೀಕರಣದ ಗುರಿಯನ್ನು ಹೊಂದಿರುವ ಪ್ಯಾಚ್‌ಗಳು ಸಹ ಅಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ.
ಆದ್ದರಿಂದ, ನಮಗೆ ಕುಂಟೆ ಇಲ್ಲ, ಆದರೆ ನಾವು ಎಲ್ಲಿಗೆ ಚಲಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ನಮಗೆ ತಿಳುವಳಿಕೆ ಇದೆ, ಮತ್ತು ಈ ನಿರ್ದೇಶನವು ಸರಿಯಾಗಿದೆ ಎಂದು ನಮಗೆ ವಿಶ್ವಾಸವಿದೆ. ಈ ತಿಳುವಳಿಕೆಯು ಸ್ವರ್ಗದಿಂದ ಮನ್ನ ರೂಪದಲ್ಲಿ ಬಂದಿಲ್ಲ. ನಮ್ಮ ಹಿಂದೆ 29 ವರ್ಷಗಳ ಅಭಿವೃದ್ಧಿ ಅನುಭವವಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ, ಮೊದಲಿನಿಂದ ಬರೆಯಲಾದ ಎರಡು ಫೈಲ್ ಸಿಸ್ಟಮ್ಗಳು. ಮತ್ತು ಅದೇ ಸಂಖ್ಯೆಯ ಡೇಟಾ ಮರುಪಡೆಯುವಿಕೆ ಉಪಯುಕ್ತತೆಗಳು. ಮತ್ತು ಇದು ಬಹಳಷ್ಟು!
ಮೂಲ: opennet.ru