ಈ ವಸಂತಕಾಲದಲ್ಲಿ ನಾವು ಈಗಾಗಲೇ ಕೆಲವು ಪರಿಚಯಾತ್ಮಕ ವಿಷಯಗಳನ್ನು ಚರ್ಚಿಸಿದ್ದೇವೆ, ಉದಾ. ನಿಮ್ಮ ಡ್ರೈವ್‌ಗಳ ವೇಗವನ್ನು ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು и RAID ಎಂದರೇನು. ಇವುಗಳಲ್ಲಿ ಎರಡನೆಯದರಲ್ಲಿ, ನಾವು ZFS ನಲ್ಲಿ ವಿವಿಧ ಮಲ್ಟಿ-ಡಿಸ್ಕ್ ಟೋಪೋಲಜಿಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಅಧ್ಯಯನ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಲು ಭರವಸೆ ನೀಡಿದ್ದೇವೆ. ಇದು ಮುಂದಿನ ಪೀಳಿಗೆಯ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಆಗಿದ್ದು ಅದನ್ನು ಈಗ ಎಲ್ಲೆಡೆಯಿಂದ ನಿಯೋಜಿಸಲಾಗುತ್ತಿದೆ ಆಪಲ್ ಗೆ ಉಬುಂಟು.

ಕುತೂಹಲಕಾರಿ ಓದುಗರು, ZFS ನೊಂದಿಗೆ ಪರಿಚಯ ಮಾಡಿಕೊಳ್ಳಲು ಇಂದು ಉತ್ತಮ ದಿನವಾಗಿದೆ. OpenZFS ಡೆವಲಪರ್ ಮ್ಯಾಟ್ ಅಹ್ರೆನ್ಸ್ ಅವರ ವಿನಮ್ರ ಮೌಲ್ಯಮಾಪನದಲ್ಲಿ, "ಇದು ನಿಜವಾಗಿಯೂ ಕಷ್ಟ" ಎಂದು ತಿಳಿಯಿರಿ.

ಆದರೆ ನಾವು ಸಂಖ್ಯೆಗಳನ್ನು ಪಡೆಯುವ ಮೊದಲು-ಮತ್ತು ಇರುತ್ತದೆ, ನಾನು ಭರವಸೆ ನೀಡುತ್ತೇನೆ-ಎಲ್ಲಾ ಎಂಟು-ಡಿಸ್ಕ್ ZFS ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗಳಿಗಾಗಿ, ನಾವು ಮಾತನಾಡಬೇಕಾಗಿದೆ ಹೇಗೆ ಸಾಮಾನ್ಯವಾಗಿ, ZFS ಡಿಸ್ಕ್ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ.

Zpool, vdev ಮತ್ತು ಸಾಧನ

ಈ ಪೂರ್ಣ ಪೂಲ್ ರೇಖಾಚಿತ್ರವು ಮೂರು ಸಹಾಯಕ vdevಗಳನ್ನು ಒಳಗೊಂಡಿದೆ, ಪ್ರತಿ ತರಗತಿಯಲ್ಲಿ ಒಂದು, ಮತ್ತು RAIDz2 ಗಾಗಿ ನಾಲ್ಕು

ಹೊಂದಿಕೆಯಾಗದ vdev ಪ್ರಕಾರಗಳು ಮತ್ತು ಗಾತ್ರಗಳ ಪೂಲ್ ಅನ್ನು ರಚಿಸಲು ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದೇ ಕಾರಣವಿಲ್ಲ - ಆದರೆ ನೀವು ಬಯಸಿದರೆ, ಹಾಗೆ ಮಾಡುವುದರಿಂದ ನಿಮ್ಮನ್ನು ತಡೆಯಲು ಏನೂ ಇಲ್ಲ

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

zpool

zpool ಶೇಖರಣಾ ಪೂಲ್ ಉನ್ನತ ZFS ರಚನೆಯಾಗಿದೆ. ಪ್ರತಿಯೊಂದು ಪೂಲ್ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ವರ್ಚುವಲ್ ಸಾಧನಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಪ್ರತಿಯಾಗಿ, ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ನೈಜ ಸಾಧನಗಳನ್ನು (ಸಾಧನ) ಒಳಗೊಂಡಿರುತ್ತದೆ. ವರ್ಚುವಲ್ ಪೂಲ್‌ಗಳು ಸ್ವಯಂ-ಒಳಗೊಂಡಿರುವ ಘಟಕಗಳಾಗಿವೆ. ಒಂದು ಭೌತಿಕ ಕಂಪ್ಯೂಟರ್ ಎರಡು ಅಥವಾ ಹೆಚ್ಚು ಪ್ರತ್ಯೇಕ ಪೂಲ್‌ಗಳನ್ನು ಹೊಂದಿರಬಹುದು, ಆದರೆ ಪ್ರತಿಯೊಂದೂ ಇತರರಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವತಂತ್ರವಾಗಿರುತ್ತದೆ. ಪೂಲ್‌ಗಳು ವರ್ಚುವಲ್ ಸಾಧನಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ.

ZFS ಪುನರುಕ್ತಿಯು ವರ್ಚುವಲ್ ಸಾಧನ ಮಟ್ಟದಲ್ಲಿದೆ, ಪೂಲ್ ಮಟ್ಟದಲ್ಲಿ ಅಲ್ಲ. ಪೂಲ್ ಮಟ್ಟದಲ್ಲಿ ಯಾವುದೇ ಪುನರುಕ್ತಿ ಇಲ್ಲ - ಒಂದು ವೇಳೆ vdev ಅಥವಾ ಮೀಸಲಾದ vdev ಕಳೆದುಹೋದರೆ, ಅದರೊಂದಿಗೆ ಸಂಪೂರ್ಣ ಪೂಲ್ ಕಳೆದುಹೋಗುತ್ತದೆ.

ಆಧುನಿಕ ಶೇಖರಣಾ ಪೂಲ್‌ಗಳು ವರ್ಚುವಲ್ ಸಾಧನದ ಸಂಗ್ರಹ ಅಥವಾ ಲಾಗ್‌ನ ನಷ್ಟದಿಂದ ಬದುಕಬಲ್ಲವು - ಆದಾಗ್ಯೂ ವಿದ್ಯುತ್ ನಿಲುಗಡೆ ಅಥವಾ ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್‌ನಲ್ಲಿ vdev ಲಾಗ್ ಅನ್ನು ಕಳೆದುಕೊಂಡರೆ ಅವು ಸ್ವಲ್ಪ ಪ್ರಮಾಣದ ಕೊಳಕು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು.

ZFS "ಡೇಟಾ ಸ್ಟ್ರೈಪ್ಸ್" ಅನ್ನು ಸಂಪೂರ್ಣ ಪೂಲ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ ಎಂಬ ಸಾಮಾನ್ಯ ತಪ್ಪು ಕಲ್ಪನೆಯಿದೆ. ಇದು ನಿಜವಲ್ಲ. Zpool ತಮಾಷೆಯ RAID0 ಅಲ್ಲ, ಇದು ಹೆಚ್ಚು ತಮಾಷೆಯಾಗಿದೆ ಜೆಬಿಒಡಿ ಸಂಕೀರ್ಣ ವೇರಿಯಬಲ್ ವಿತರಣಾ ಕಾರ್ಯವಿಧಾನದೊಂದಿಗೆ.

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

ಆಧುನಿಕ ZFS ಬರೆಯುವ ಹಂಚಿಕೆ ವಿಧಾನಗಳಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಮರುಬಳಕೆ ಪತ್ತೆ ಕಾರ್ಯವಿಧಾನವು ಅಸಾಧಾರಣವಾಗಿ ಹೆಚ್ಚಿನ ಹೊರೆಯ ಅವಧಿಯಲ್ಲಿ ಸುಪ್ತತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಥ್ರೋಪುಟ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ - ಆದರೆ ಅದು ಮಾಡುವುದಿಲ್ಲ. ಪೂರ್ಣಾಧಿಕಾರ ಒಂದು ಪೂಲ್‌ನಲ್ಲಿ ನಿಧಾನ HDD ಗಳು ಮತ್ತು ವೇಗದ SSD ಗಳ ಅನೈಚ್ಛಿಕ ಮಿಶ್ರಣಕ್ಕೆ. ಅಂತಹ ಅಸಮಾನ ಪೂಲ್ ಇನ್ನೂ ನಿಧಾನವಾದ ಸಾಧನದ ವೇಗದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅಂದರೆ, ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಅಂತಹ ಸಾಧನಗಳಿಂದ ಕೂಡಿದೆ.

vdev

ಪ್ರತಿಯೊಂದು ಶೇಖರಣಾ ಪೂಲ್ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ವರ್ಚುವಲ್ ಸಾಧನಗಳನ್ನು (vdev) ಒಳಗೊಂಡಿರುತ್ತದೆ. ಪ್ರತಿಯಾಗಿ, ಪ್ರತಿ vdev ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ನೈಜ ಸಾಧನಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಹೆಚ್ಚಿನ ವರ್ಚುವಲ್ ಸಾಧನಗಳನ್ನು ಸರಳ ಡೇಟಾ ಸಂಗ್ರಹಣೆಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ CACHE, LOG ಮತ್ತು SPECIAL ಸೇರಿದಂತೆ ಹಲವಾರು vdev ಸಹಾಯಕ ವರ್ಗಗಳಿವೆ. ಈ ಪ್ರತಿಯೊಂದು vdev ಪ್ರಕಾರಗಳು ಐದು ಟೋಪೋಲಾಜಿಗಳಲ್ಲಿ ಒಂದನ್ನು ಹೊಂದಬಹುದು: ಏಕ-ಸಾಧನ, RAIDz1, RAIDz2, RAIDz3 ಅಥವಾ ಕನ್ನಡಿ.

RAIDz1, RAIDz2 ಮತ್ತು RAIDz3 ಗಳು ಹಳೆಯ ಜನರು ಡಬಲ್ (ಕರ್ಣೀಯ) ಪ್ಯಾರಿಟಿ RAID ಎಂದು ಕರೆಯುವ ವಿಶೇಷ ಪ್ರಭೇದಗಳಾಗಿವೆ. 1, 2 ಮತ್ತು 3 ಪ್ರತಿ ಡೇಟಾ ಲೇನ್‌ಗೆ ಎಷ್ಟು ಪ್ಯಾರಿಟಿ ಬ್ಲಾಕ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ. ಸಮಾನತೆಯನ್ನು ಒದಗಿಸಲು ಪ್ರತ್ಯೇಕ ಡಿಸ್ಕ್‌ಗಳನ್ನು ಹೊಂದುವ ಬದಲು, ವರ್ಚುವಲ್ RAIDz ಸಾಧನಗಳು ಡಿಸ್ಕ್‌ಗಳಾದ್ಯಂತ ಪ್ಯಾರಿಟಿಯನ್ನು ಅರೆ-ಸಮಾನವಾಗಿ ವಿತರಿಸುತ್ತವೆ. ಒಂದು RAIDz ಅರೇಯು ಪ್ಯಾರಿಟಿ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಹೊಂದಿರುವಷ್ಟು ಡಿಸ್ಕ್‌ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು; ಅದು ಇನ್ನೊಂದನ್ನು ಕಳೆದುಕೊಂಡರೆ, ಅದು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅದರೊಂದಿಗೆ ಶೇಖರಣಾ ಪೂಲ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

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

ಏಕ vdevs ಅಂತರ್ಗತವಾಗಿ ಅಪಾಯಕಾರಿ. ಅಂತಹ ವರ್ಚುವಲ್ ಸಾಧನವು ಒಂದೇ ವೈಫಲ್ಯದಿಂದ ಉಳಿಯುವುದಿಲ್ಲ - ಮತ್ತು ಶೇಖರಣಾ ಅಥವಾ ವಿಶೇಷ ವಿಡೆವ್ ಆಗಿ ಬಳಸಿದರೆ, ಅದರ ವೈಫಲ್ಯವು ಸಂಪೂರ್ಣ ಪೂಲ್ನ ನಾಶಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಇಲ್ಲಿ ಬಹಳ ಜಾಗರೂಕರಾಗಿರಿ.

CACHE, LOG ಮತ್ತು SPECIAL ವರ್ಚುವಲ್ ಸಾಧನಗಳನ್ನು ಮೇಲಿನ ಯಾವುದೇ ಟೊಪೊಲಾಜಿಗಳಲ್ಲಿ ರಚಿಸಬಹುದು - ಆದರೆ ವಿಶೇಷ ವರ್ಚುವಲ್ ಸಾಧನವನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು ಎಂದರೆ ಪೂಲ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದು ಎಂದರ್ಥ, ಆದ್ದರಿಂದ ಅನಗತ್ಯ ಟೋಪೋಲಜಿಯನ್ನು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ.

ಸಾಧನ

ಇದು ಬಹುಶಃ ZFS ನಲ್ಲಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾದ ಪದವಾಗಿದೆ - ಇದು ಅಕ್ಷರಶಃ ಬ್ಲಾಕ್ ಯಾದೃಚ್ಛಿಕ ಪ್ರವೇಶ ಸಾಧನವಾಗಿದೆ. ವರ್ಚುವಲ್ ಸಾಧನಗಳು ವೈಯಕ್ತಿಕ ಸಾಧನಗಳಿಂದ ಮಾಡಲ್ಪಟ್ಟಿದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ, ಮತ್ತು ಪೂಲ್ ಅನ್ನು ವರ್ಚುವಲ್ ಸಾಧನಗಳಿಂದ ಮಾಡಲಾಗಿದೆ.

ಡಿಸ್ಕ್ಗಳು, ಮ್ಯಾಗ್ನೆಟಿಕ್ ಅಥವಾ ಘನ ಸ್ಥಿತಿ, vdev ನ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್ಸ್ ಆಗಿ ಬಳಸುವ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಬ್ಲಾಕ್ ಸಾಧನಗಳಾಗಿವೆ. ಆದಾಗ್ಯೂ, /dev ನಲ್ಲಿ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಹೊಂದಿರುವ ಯಾವುದೇ ಸಾಧನವು ಮಾಡುತ್ತದೆ - ಆದ್ದರಿಂದ ಸಂಪೂರ್ಣ ಹಾರ್ಡ್‌ವೇರ್ RAID ಅರೇಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಸಾಧನಗಳಾಗಿ ಬಳಸಬಹುದು.

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

ನೀವು ಕೆಲವೇ ಸೆಕೆಂಡುಗಳಲ್ಲಿ ವಿರಳ ಫೈಲ್‌ಗಳಿಂದ ಪರೀಕ್ಷಾ ಪೂಲ್ ಅನ್ನು ರಚಿಸಬಹುದು - ಆದರೆ ನಂತರ ಸಂಪೂರ್ಣ ಪೂಲ್ ಮತ್ತು ಅದರ ಘಟಕಗಳನ್ನು ಅಳಿಸಲು ಮರೆಯಬೇಡಿ

ನಿಮಗೆ ಎಂಟು-ಡಿಸ್ಕ್ ಸರ್ವರ್ ಬೇಕು ಮತ್ತು 10TB (~9300 GiB) ಡಿಸ್ಕ್‌ಗಳನ್ನು ಬಳಸಲು ಯೋಜಿಸಲಾಗಿದೆ ಎಂದು ಹೇಳೋಣ, ಆದರೆ ನಿಮ್ಮ ಅಗತ್ಯಗಳಿಗೆ ಯಾವ ಟೋಪೋಲಜಿ ಉತ್ತಮವಾಗಿ ಸರಿಹೊಂದುತ್ತದೆ ಎಂದು ನಿಮಗೆ ಖಚಿತವಾಗಿಲ್ಲ. ಮೇಲಿನ ಉದಾಹರಣೆಯಲ್ಲಿ, ನಾವು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ವಿರಳ ಫೈಲ್‌ಗಳ ಪರೀಕ್ಷಾ ಪೂಲ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತೇವೆ-ಮತ್ತು ಈಗ ಎಂಟು 2TB ಡ್ರೈವ್‌ಗಳ RAIDz10 vdev ಬಳಸಬಹುದಾದ ಸಾಮರ್ಥ್ಯವನ್ನು 50TiB ಒದಗಿಸುತ್ತದೆ ಎಂದು ತಿಳಿದಿದೆ.

ಸಾಧನಗಳ ಮತ್ತೊಂದು ವಿಶೇಷ ವರ್ಗ SPARE ಆಗಿದೆ. ಸಾಮಾನ್ಯ ಸಾಧನಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ ಹಾಟ್-ಸ್ವಾಪ್ ಸಾಧನಗಳು ಒಂದೇ ವರ್ಚುವಲ್ ಸಾಧನಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಸಂಪೂರ್ಣ ಪೂಲ್‌ಗೆ ಸೇರಿವೆ. ಪೂಲ್‌ನಲ್ಲಿರುವ ಯಾವುದೇ vdev ವಿಫಲವಾದಲ್ಲಿ ಮತ್ತು ಒಂದು ಬಿಡಿ ಸಾಧನವು ಪೂಲ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡಿದ್ದರೆ ಮತ್ತು ಲಭ್ಯವಿದ್ದರೆ, ಅದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪೀಡಿತ vdev ಅನ್ನು ಸೇರುತ್ತದೆ.

ಒಮ್ಮೆ ಪೀಡಿತ vdev ಗೆ ಸಂಪರ್ಕಗೊಂಡ ನಂತರ, ಬದಲಿ ಸಾಧನವು ಕಾಣೆಯಾದ ಸಾಧನದಲ್ಲಿ ಇರಬೇಕಾದ ಡೇಟಾದ ನಕಲುಗಳು ಅಥವಾ ಮರುನಿರ್ಮಾಣಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಸಾಂಪ್ರದಾಯಿಕ RAID ನಲ್ಲಿ ಇದನ್ನು "ಪುನರ್ನಿರ್ಮಾಣ" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಮತ್ತು ZFS ನಲ್ಲಿ ಇದು "ರಿಸಿಲ್ವರಿಂಗ್" ಆಗಿದೆ.

ಬದಲಿ ಸಾಧನಗಳು ವಿಫಲವಾದ ಸಾಧನಗಳನ್ನು ಶಾಶ್ವತವಾಗಿ ಬದಲಾಯಿಸುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ. vdev ಕ್ಷೀಣಿಸಲು ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಇದು ತಾತ್ಕಾಲಿಕ ಬದಲಿಯಾಗಿದೆ. ನಿರ್ವಾಹಕರು ವಿಫಲವಾದ vdev ಸಾಧನವನ್ನು ಬದಲಾಯಿಸಿದ ನಂತರ, ಆ ಶಾಶ್ವತ ಸಾಧನಕ್ಕೆ ಪುನರುಜ್ಜೀವನವನ್ನು ಮರುಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ ಮತ್ತು SPARE ಅನ್ನು vdev ನಿಂದ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಸಂಪೂರ್ಣ ಪೂಲ್‌ಗೆ ಒಂದು ಬಿಡಿಯಾಗಿ ಮರಳುತ್ತದೆ.

ಡೇಟಾ ಸೆಟ್‌ಗಳು, ಬ್ಲಾಕ್‌ಗಳು ಮತ್ತು ಸೆಕ್ಟರ್‌ಗಳು

ನಮ್ಮ ZFS ಪ್ರಯಾಣದಲ್ಲಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮುಂದಿನ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್‌ಗಳು ಹಾರ್ಡ್‌ವೇರ್‌ಗೆ ಕಡಿಮೆ ಸಂಬಂಧಿಸಿವೆ ಮತ್ತು ಡೇಟಾವನ್ನು ಹೇಗೆ ಆಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಹೆಚ್ಚಿನದನ್ನು ಮಾಡುತ್ತವೆ. ಒಟ್ಟಾರೆ ರಚನೆಯ ತಿಳುವಳಿಕೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವಾಗ ವಿವರಗಳನ್ನು ಅಸ್ತವ್ಯಸ್ತಗೊಳಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ನಾವು ಇಲ್ಲಿ ಕೆಲವು ಲೇಯರ್‌ಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತೇವೆ - ಉದಾಹರಣೆಗೆ ಮೆಟಾಸ್ಲ್ಯಾಬ್.

ಡೇಟಾಸೆಟ್

ನಾವು ಮೊದಲು ಡೇಟಾಸೆಟ್ ಅನ್ನು ರಚಿಸಿದಾಗ, ಅದು ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ ಪೂಲ್ ಜಾಗವನ್ನು ತೋರಿಸುತ್ತದೆ. ನಂತರ ನಾವು ಕೋಟಾವನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ - ಮತ್ತು ಮೌಂಟ್ ಪಾಯಿಂಟ್ ಅನ್ನು ಬದಲಾಯಿಸಿ. ಮ್ಯಾಜಿಕ್!

Zvol ಹೆಚ್ಚಾಗಿ ಅದರ ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಲೇಯರ್‌ನಿಂದ ತೆಗೆದುಹಾಕಲಾದ ಡೇಟಾಸೆಟ್ ಆಗಿದೆ, ಅದನ್ನು ನಾವು ಇಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಸಾಮಾನ್ಯ ext4 ಫೈಲ್‌ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ

ZFS ಡೇಟಾ ಸೆಟ್ ಪ್ರಮಾಣಿತ ಮೌಂಟೆಡ್ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಂತೆಯೇ ಇರುತ್ತದೆ. ಸಾಮಾನ್ಯ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಂತೆ, ಮೊದಲ ನೋಟದಲ್ಲಿ ಇದು "ಇನ್ನೊಂದು ಫೋಲ್ಡರ್" ಎಂದು ತೋರುತ್ತದೆ. ಆದರೆ ಸಾಮಾನ್ಯ ಮೌಂಟೆಡ್ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳಂತೆಯೇ, ಪ್ರತಿಯೊಂದು ZFS ಡೇಟಾ ಸೆಟ್ ತನ್ನದೇ ಆದ ಮೂಲಭೂತ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿದೆ.

ಮೊದಲನೆಯದಾಗಿ, ಡೇಟಾಸೆಟ್ ನಿಯೋಜಿತ ಕೋಟಾವನ್ನು ಹೊಂದಿರಬಹುದು. ನೀವು ಸ್ಥಾಪಿಸಿದರೆ zfs set quota=100G poolname/datasetname, ನಂತರ ನೀವು ಆರೋಹಿತವಾದ ಫೋಲ್ಡರ್‌ಗೆ ಬರೆಯಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ /poolname/datasetname 100 GiB ಗಿಂತ ಹೆಚ್ಚು.

ಪ್ರತಿ ಸಾಲಿನ ಆರಂಭದಲ್ಲಿ ಸ್ಲ್ಯಾಶ್‌ಗಳ ಉಪಸ್ಥಿತಿ ಮತ್ತು ಅನುಪಸ್ಥಿತಿಯನ್ನು ಗಮನಿಸಿ? ಪ್ರತಿಯೊಂದು ಡೇಟಾ ಸೆಟ್ ZFS ಕ್ರಮಾನುಗತ ಮತ್ತು ಸಿಸ್ಟಮ್ ಮೌಂಟ್ ಕ್ರಮಾನುಗತ ಎರಡರಲ್ಲೂ ತನ್ನದೇ ಆದ ಸ್ಥಾನವನ್ನು ಹೊಂದಿದೆ. ZFS ಕ್ರಮಾನುಗತದಲ್ಲಿ ಯಾವುದೇ ಪ್ರಮುಖ ಸ್ಲ್ಯಾಷ್ ಇಲ್ಲ - ನೀವು ಪೂಲ್ ಹೆಸರಿನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ನಂತರ ಒಂದು ಡೇಟಾ ಸೆಟ್‌ನಿಂದ ಮುಂದಿನದಕ್ಕೆ ಮಾರ್ಗವನ್ನು ಹೊಂದಿಸಿ. ಉದಾಹರಣೆಗೆ, pool/parent/child ಹೆಸರಿನ ಡೇಟಾ ಸೆಟ್‌ಗಾಗಿ child ಪೋಷಕ ಡೇಟಾಸೆಟ್ ಅಡಿಯಲ್ಲಿ parent ಸೃಜನಾತ್ಮಕ ಹೆಸರಿನೊಂದಿಗೆ ಕೊಳದಲ್ಲಿ pool.

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಡೇಟಾಸೆಟ್‌ನ ಮೌಂಟ್ ಪಾಯಿಂಟ್ ZFS ಶ್ರೇಣಿಯಲ್ಲಿನ ಅದರ ಹೆಸರಿಗೆ ಸಮನಾಗಿರುತ್ತದೆ, ಪ್ರಮುಖ ಸ್ಲ್ಯಾಷ್‌ನೊಂದಿಗೆ - ಪೂಲ್ ಹೆಸರಿಸಲಾಗಿದೆ pool ಎಂದು ಜೋಡಿಸಲಾಗಿದೆ /pool, ಡೇಟಾ ಸೆಟ್ parent ಅಳವಡಿಸಲಾಗಿದೆ /pool/parent, ಮತ್ತು ಮಕ್ಕಳ ಡೇಟಾ ಸೆಟ್ child ಅಳವಡಿಸಲಾಗಿದೆ /pool/parent/child. ಆದಾಗ್ಯೂ, ಡೇಟಾ ಸೆಟ್‌ನ ಸಿಸ್ಟಮ್ ಮೌಂಟ್ ಪಾಯಿಂಟ್ ಅನ್ನು ಬದಲಾಯಿಸಬಹುದು.

ನಾವು ಸೂಚಿಸಿದರೆ zfs set mountpoint=/lol pool/parent/child, ನಂತರ ಡೇಟಾ ಸೆಟ್ pool/parent/child ಎಂದು ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ /lol.

ಡೇಟಾಸೆಟ್‌ಗಳ ಜೊತೆಗೆ, ನಾವು ಸಂಪುಟಗಳನ್ನು (zvols) ನಮೂದಿಸಬೇಕು. ಪರಿಮಾಣವು ಡೇಟಾ ಸೆಟ್‌ನಂತೆಯೇ ಇರುತ್ತದೆ, ಅದು ವಾಸ್ತವವಾಗಿ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ - ಇದು ಕೇವಲ ಒಂದು ಬ್ಲಾಕ್ ಸಾಧನವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನೀವು ರಚಿಸಬಹುದು zvol ಹೆಸರಿನೊಂದಿಗೆ mypool/myzvol, ನಂತರ ಅದನ್ನು ext4 ಫೈಲ್‌ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಿ, ತದನಂತರ ಆ ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಅನ್ನು ಆರೋಹಿಸಿ - ಈಗ ನೀವು ext4 ಫೈಲ್‌ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಆದರೆ ZFS ನ ಎಲ್ಲಾ ಭದ್ರತಾ ವೈಶಿಷ್ಟ್ಯಗಳೊಂದಿಗೆ! ಇದು ಒಂದು ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ ಸಿಲ್ಲಿಯಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೆ iSCSI ಸಾಧನವನ್ನು ರಫ್ತು ಮಾಡುವಾಗ ಬ್ಯಾಕೆಂಡ್‌ನಂತೆ ಹೆಚ್ಚು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ.

ನಿರ್ಬಂಧಗಳು

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

ನಾವು ನಿಜವಾಗಿಯೂ ನಿಜವಾಗಿಯೂ ನೀವು ಶಿಫ್ಟ್ ಅನ್ನು ತುಂಬಾ ಕಡಿಮೆ ಹೊಂದಿಸಿದರೆ ದೊಡ್ಡ ಕಾರ್ಯಕ್ಷಮತೆಯ ದಂಡದ ಬಗ್ಗೆ ನಾವು ತಮಾಷೆ ಮಾಡುತ್ತಿಲ್ಲ

ZFS ಪೂಲ್‌ನಲ್ಲಿ, ಮೆಟಾಡೇಟಾ ಸೇರಿದಂತೆ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ಪ್ರತಿ ಡೇಟಾ ಸೆಟ್‌ಗೆ ಗರಿಷ್ಠ ಬ್ಲಾಕ್ ಗಾತ್ರವನ್ನು ಆಸ್ತಿಯಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ recordsize (ದಾಖಲೆ ಗಾತ್ರ). ರೆಕಾರ್ಡ್ ಗಾತ್ರವು ಬದಲಾಗಬಹುದು, ಆದರೆ ಇದು ಈಗಾಗಲೇ ಡೇಟಾ ಸೆಟ್‌ಗೆ ಬರೆಯಲಾದ ಯಾವುದೇ ಬ್ಲಾಕ್‌ಗಳ ಗಾತ್ರ ಅಥವಾ ಸ್ಥಳವನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ - ಇದು ಹೊಸ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಬರೆದಂತೆ ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.

ನಿರ್ದಿಷ್ಟಪಡಿಸದ ಹೊರತು, ಪ್ರಸ್ತುತ ಡೀಫಾಲ್ಟ್ ಪ್ರವೇಶ ಗಾತ್ರವು 128 KiB ಆಗಿದೆ. ಇದು ಒಂದು ರೀತಿಯ ಕಠಿಣ ವಹಿವಾಟು, ಅಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆ ಪರಿಪೂರ್ಣವಾಗುವುದಿಲ್ಲ, ಆದರೆ ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಭಯಾನಕವಾಗುವುದಿಲ್ಲ. Recordsize 4K ನಿಂದ 1M ವರೆಗೆ ಯಾವುದೇ ಮೌಲ್ಯಕ್ಕೆ ಹೊಂದಿಸಬಹುದು (ಹೆಚ್ಚುವರಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ recordsize ನೀವು ಇನ್ನೂ ಹೆಚ್ಚಿನದನ್ನು ಸ್ಥಾಪಿಸಬಹುದು, ಆದರೆ ಇದು ಅಪರೂಪವಾಗಿ ಒಳ್ಳೆಯದು).

ಯಾವುದೇ ಬ್ಲಾಕ್ ಕೇವಲ ಒಂದು ಫೈಲ್‌ನ ಡೇಟಾವನ್ನು ಸೂಚಿಸುತ್ತದೆ - ನೀವು ಎರಡು ವಿಭಿನ್ನ ಫೈಲ್‌ಗಳನ್ನು ಒಂದು ಬ್ಲಾಕ್‌ಗೆ ಸ್ಕ್ವೀಜ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪ್ರತಿಯೊಂದು ಫೈಲ್ ಅದರ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಬ್ಲಾಕ್ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಫೈಲ್ ಗಾತ್ರವು ರೆಕಾರ್ಡ್ ಗಾತ್ರಕ್ಕಿಂತ ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ಅದನ್ನು ಚಿಕ್ಕ ಬ್ಲಾಕ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ-ಉದಾಹರಣೆಗೆ, 2KiB ಫೈಲ್ ಹೊಂದಿರುವ ಬ್ಲಾಕ್ ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಕೇವಲ ಒಂದು 4KiB ಸೆಕ್ಟರ್ ಅನ್ನು ಆಕ್ರಮಿಸುತ್ತದೆ.

ಫೈಲ್ ಹಲವಾರು ಬ್ಲಾಕ್‌ಗಳ ಅಗತ್ಯವಿರುವಷ್ಟು ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಆ ಫೈಲ್‌ಗೆ ಎಲ್ಲಾ ನಮೂದುಗಳು ಗಾತ್ರದಲ್ಲಿರುತ್ತವೆ recordsize - ಕೊನೆಯ ನಮೂದು ಸೇರಿದಂತೆ, ಅದರ ಮುಖ್ಯ ಭಾಗವಾಗಿರಬಹುದು ಬಳಕೆಯಾಗದ ಜಾಗ.

zvol ಸಂಪುಟಗಳು ಆಸ್ತಿಯನ್ನು ಹೊಂದಿಲ್ಲ recordsize - ಬದಲಿಗೆ ಅವರು ಸಮಾನ ಆಸ್ತಿಯನ್ನು ಹೊಂದಿದ್ದಾರೆ volblocksize.

ವಲಯಗಳು

ಕೊನೆಯ, ಅತ್ಯಂತ ಮೂಲಭೂತ ಬಿಲ್ಡಿಂಗ್ ಬ್ಲಾಕ್ ಸೆಕ್ಟರ್ ಆಗಿದೆ. ಇದು ಹೋಸ್ಟ್ ಸಾಧನದಿಂದ ಬರೆಯಬಹುದಾದ ಅಥವಾ ಓದಬಹುದಾದ ಚಿಕ್ಕ ಭೌತಿಕ ಘಟಕವಾಗಿದೆ. ಹಲವಾರು ದಶಕಗಳವರೆಗೆ, ಹೆಚ್ಚಿನ ಡಿಸ್ಕ್ಗಳು ​​512-ಬೈಟ್ ಕ್ಷೇತ್ರಗಳನ್ನು ಬಳಸಿದವು. ಈ ದಿನಗಳಲ್ಲಿ, ಹೆಚ್ಚಿನ ಡ್ರೈವ್‌ಗಳನ್ನು 4KiB ಸೆಕ್ಟರ್‌ಗಳಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ಮತ್ತು ಕೆಲವು-ವಿಶೇಷವಾಗಿ SSD ಗಳನ್ನು 8KiB ಸೆಕ್ಟರ್‌ಗಳಿಗೆ ಅಥವಾ ಅದಕ್ಕಿಂತಲೂ ದೊಡ್ಡದಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ.

ZFS ಒಂದು ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿದ್ದು ಅದು ಸೆಕ್ಟರ್ ಗಾತ್ರವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಹೊಂದಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ಆಸ್ತಿ ashift. ಸ್ವಲ್ಪ ಗೊಂದಲಮಯವಾಗಿ, ಆಶಿಫ್ಟ್ ಎರಡರ ಶಕ್ತಿಯಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ashift=9 ಸೆಕ್ಟರ್ ಗಾತ್ರ 2^9, ಅಥವಾ 512 ಬೈಟ್‌ಗಳು ಎಂದರ್ಥ.

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

ಇದರರ್ಥ ZFS ನಿರ್ವಾಹಕರು ತಮ್ಮ ಸಾಧನಗಳ ನಿಜವಾದ ಸೆಕ್ಟರ್ ಗಾತ್ರವನ್ನು ತಿಳಿದುಕೊಳ್ಳಲು ಮತ್ತು ಹಸ್ತಚಾಲಿತವಾಗಿ ಹೊಂದಿಸಲು ಹೆಚ್ಚು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ ashift. ಆಶಿಫ್ಟ್ ಅನ್ನು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿ ಹೊಂದಿಸಿದರೆ, ಓದುವ/ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಗಳ ಸಂಖ್ಯೆಯು ಖಗೋಳಶಾಸ್ತ್ರೀಯವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, 512-ಬೈಟ್ "ಸೆಕ್ಟರ್" ಅನ್ನು ನಿಜವಾದ 4KiB ಸೆಕ್ಟರ್‌ಗೆ ಬರೆಯುವುದು ಎಂದರೆ ಮೊದಲ "ಸೆಕ್ಟರ್" ಅನ್ನು ಬರೆಯಬೇಕು, ನಂತರ 4KiB ಸೆಕ್ಟರ್ ಅನ್ನು ಓದಿ, ಅದನ್ನು ಎರಡನೇ 512-ಬೈಟ್ "ಸೆಕ್ಟರ್" ನೊಂದಿಗೆ ಮಾರ್ಪಡಿಸಿ, ಅದನ್ನು ಹೊಸ 4KiB ಸೆಕ್ಟರ್‌ಗೆ ಬರೆಯಿರಿ , ಮತ್ತು ಹೀಗೆ. ಪ್ರತಿ ಪ್ರವೇಶಕ್ಕೆ.

ನೈಜ ಜಗತ್ತಿನಲ್ಲಿ, ಅಂತಹ ದಂಡವು Samsung EVO SSD ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ, ಇದಕ್ಕಾಗಿ ಅದು ಅನ್ವಯಿಸಬೇಕು ashift=13, ಆದರೆ ಈ SSD ಗಳು ಅವುಗಳ ಸೆಕ್ಟರ್ ಗಾತ್ರದ ಬಗ್ಗೆ ಸುಳ್ಳು, ಮತ್ತು ಆದ್ದರಿಂದ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ ashift=9. ಅನುಭವಿ ಸಿಸ್ಟಂ ನಿರ್ವಾಹಕರು ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಬದಲಾಯಿಸದ ಹೊರತು, ಈ SSD ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ನಿಧಾನವಾಗಿ ನಿಯಮಿತ ಮ್ಯಾಗ್ನೆಟಿಕ್ HDD.

ಹೋಲಿಕೆಗಾಗಿ, ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ ashift ವಾಸ್ತವಿಕವಾಗಿ ಯಾವುದೇ ದಂಡವಿಲ್ಲ. ಯಾವುದೇ ನೈಜ ಕಾರ್ಯಕ್ಷಮತೆ ಹಿಟ್ ಇಲ್ಲ, ಮತ್ತು ಬಳಕೆಯಾಗದ ಜಾಗದಲ್ಲಿನ ಹೆಚ್ಚಳವು ಅಪರಿಮಿತವಾಗಿದೆ (ಅಥವಾ ಸಂಕೋಚನವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ ಶೂನ್ಯ). ಆದ್ದರಿಂದ, 512-ಬೈಟ್ ಸೆಕ್ಟರ್‌ಗಳನ್ನು ಬಳಸುವ ಡ್ರೈವ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸಲು ನಾವು ಬಲವಾಗಿ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ashift=12 ಅಥವಾ ashift=13ಭವಿಷ್ಯದಲ್ಲಿ ವಿಶ್ವಾಸದಿಂದ ನೋಡಲು.

ಆಸ್ತಿ ashift ಪ್ರತಿ ವರ್ಚುವಲ್ ಸಾಧನ vdev ಗೆ ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಮತ್ತು ಪೂಲ್‌ಗಾಗಿ ಅಲ್ಲ, ಅನೇಕ ಜನರು ತಪ್ಪಾಗಿ ಯೋಚಿಸಿದಂತೆ, ಮತ್ತು ಅನುಸ್ಥಾಪನೆಯ ನಂತರ ಬದಲಾಗುವುದಿಲ್ಲ. ನೀವು ಆಕಸ್ಮಿಕವಾಗಿ ಹೊಡೆದರೆ ashift ನೀವು ಪೂಲ್‌ಗೆ ಹೊಸ vdev ಅನ್ನು ಸೇರಿಸಿದಾಗ, ನೀವು ಕಡಿಮೆ-ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಾಧನದೊಂದಿಗೆ ಆ ಪೂಲ್ ಅನ್ನು ಬದಲಾಯಿಸಲಾಗದಂತೆ ಕಲುಷಿತಗೊಳಿಸಿದ್ದೀರಿ ಮತ್ತು ನಿಯಮದಂತೆ, ಪೂಲ್ ಅನ್ನು ನಾಶಪಡಿಸುವುದನ್ನು ಬಿಟ್ಟು ಬೇರೆ ಯಾವುದೇ ಆಯ್ಕೆಗಳಿಲ್ಲ. vdev ಅನ್ನು ಅಳಿಸಿದರೂ ಸಹ ಮುರಿದ ಸೆಟ್ಟಿಂಗ್‌ನಿಂದ ನಿಮ್ಮನ್ನು ಉಳಿಸುವುದಿಲ್ಲ ashift!

ಕಾಪಿ-ಆನ್-ರೈಟ್ ಯಾಂತ್ರಿಕತೆ

ನಿಯಮಿತ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಡೇಟಾವನ್ನು ಪುನಃ ಬರೆಯಬೇಕಾದರೆ, ಅದು ಇರುವ ಪ್ರತಿಯೊಂದು ಬ್ಲಾಕ್ ಅನ್ನು ಮಾರ್ಪಡಿಸುತ್ತದೆ

ಕಾಪಿ-ಆನ್-ರೈಟ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಬ್ಲಾಕ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಬರೆಯುತ್ತದೆ ಮತ್ತು ನಂತರ ಹಳೆಯ ಆವೃತ್ತಿಯನ್ನು ಅನ್‌ಲಾಕ್ ಮಾಡುತ್ತದೆ

ಅಮೂರ್ತವಾಗಿ, ನಾವು ಬ್ಲಾಕ್‌ಗಳ ನಿಜವಾದ ಭೌತಿಕ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದರೆ, ನಮ್ಮ "ಡೇಟಾ ಕಾಮೆಟ್" ಲಭ್ಯವಿರುವ ಜಾಗದ ನಕ್ಷೆಯಲ್ಲಿ ಎಡದಿಂದ ಬಲಕ್ಕೆ ಚಲಿಸುವ "ಡೇಟಾ ವರ್ಮ್" ಗೆ ಸರಳಗೊಳಿಸುತ್ತದೆ.

ಕಾಪಿ-ಆನ್-ರೈಟ್ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದರ ಕುರಿತು ಈಗ ನಾವು ಉತ್ತಮ ಕಲ್ಪನೆಯನ್ನು ಪಡೆಯಬಹುದು - ಪ್ರತಿ ಬ್ಲಾಕ್ ಬಹು ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳಿಗೆ ಸೇರಿರಬಹುದು ಮತ್ತು ಎಲ್ಲಾ ಸಂಬಂಧಿತ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ನಾಶವಾಗುವವರೆಗೆ ಮುಂದುವರಿಯುತ್ತದೆ

ಕಾಪಿ ಆನ್ ರೈಟ್ (CoW) ಕಾರ್ಯವಿಧಾನವು ZFS ಅನ್ನು ಅಂತಹ ಅದ್ಭುತ ವ್ಯವಸ್ಥೆಯನ್ನು ಮಾಡುವ ಮೂಲಭೂತ ಆಧಾರವಾಗಿದೆ. ಮೂಲ ಪರಿಕಲ್ಪನೆಯು ಸರಳವಾಗಿದೆ - ಫೈಲ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ನೀವು ಸಾಂಪ್ರದಾಯಿಕ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಕೇಳಿದರೆ, ಅದು ನೀವು ಕೇಳಿದ್ದನ್ನು ನಿಖರವಾಗಿ ಮಾಡುತ್ತದೆ. ಅದೇ ಕೆಲಸವನ್ನು ಮಾಡಲು ಕಾಪಿ-ಆನ್-ರೈಟ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ನೀವು ಕೇಳಿದರೆ, ಅದು "ಸರಿ" ಎಂದು ಹೇಳುತ್ತದೆ - ಆದರೆ ಅದು ನಿಮಗೆ ಸುಳ್ಳು ಹೇಳುತ್ತದೆ.

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

ಹಳೆಯ ಬ್ಲಾಕ್ ಅನ್ನು ಅನ್ಬೈಂಡ್ ಮಾಡುವುದು ಮತ್ತು ಹೊಸದನ್ನು ಲಿಂಕ್ ಮಾಡುವುದು ಒಂದು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಅಡ್ಡಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ - ಇದು ಸಂಭವಿಸಿದ ನಂತರ ನೀವು ಶಕ್ತಿಯನ್ನು ಮರುಹೊಂದಿಸಿದರೆ, ನೀವು ಫೈಲ್ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಹೊಂದಿದ್ದೀರಿ ಮತ್ತು ನೀವು ಮೊದಲು ಶಕ್ತಿಯನ್ನು ಮರುಹೊಂದಿಸಿದರೆ, ನಂತರ ನೀವು ಹೊಂದಿರುತ್ತೀರಿ ಹಳೆಯ ಆವೃತ್ತಿ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಫೈಲ್ ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಯಾವುದೇ ಘರ್ಷಣೆಗಳು ಇರುವುದಿಲ್ಲ.

ZFS ನಲ್ಲಿ ಕಾಪಿ-ಆನ್-ರೈಟ್ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಮಟ್ಟದಲ್ಲಿ ಮಾತ್ರವಲ್ಲದೆ ಡಿಸ್ಕ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಮಟ್ಟದಲ್ಲಿಯೂ ಸಂಭವಿಸುತ್ತದೆ. ಇದರರ್ಥ ZFS ದಾಖಲೆಯಲ್ಲಿನ ವೈಟ್‌ಸ್ಪೇಸ್‌ಗೆ ಒಳಗಾಗುವುದಿಲ್ಲ (RAID ನಲ್ಲಿ ರಂಧ್ರ) - ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್ ಆಗುವ ಮೊದಲು ಸ್ಟ್ರಿಪ್ ಅನ್ನು ಭಾಗಶಃ ರೆಕಾರ್ಡ್ ಮಾಡಿದಾಗ, ರೀಬೂಟ್ ಮಾಡಿದ ನಂತರ ರಚನೆಗೆ ಹಾನಿಯಾಗುವ ವಿದ್ಯಮಾನ. ಇಲ್ಲಿ ಸ್ಟ್ರೈಪ್ ಅನ್ನು ಪರಮಾಣುವಾಗಿ ಬರೆಯಲಾಗಿದೆ, vdev ಯಾವಾಗಲೂ ಅನುಕ್ರಮವಾಗಿದೆ, ಮತ್ತು ಬಾಬ್ ನಿಮ್ಮ ಚಿಕ್ಕಪ್ಪ..

ZIL: ZFS ಇಂಟೆಂಟ್ ಲಾಗ್

ZFS ವಿಶೇಷ ರೀತಿಯಲ್ಲಿ ಸಿಂಕ್ರೊನಸ್ ಬರಹಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ - ಇದು ಅವುಗಳನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಆದರೆ ತಕ್ಷಣವೇ ZIL ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ, ನಂತರ ಅವುಗಳನ್ನು ಅಸಮಕಾಲಿಕ ಬರಹಗಳೊಂದಿಗೆ ಶಾಶ್ವತವಾಗಿ ಬರೆಯುತ್ತದೆ.

ವಿಶಿಷ್ಟವಾಗಿ, ZIL ಗೆ ಬರೆದ ಡೇಟಾವನ್ನು ಮತ್ತೆ ಓದಲಾಗುವುದಿಲ್ಲ. ಆದರೆ ಸಿಸ್ಟಮ್ ವೈಫಲ್ಯದ ನಂತರ ಇದು ಸಾಧ್ಯ

SLOG, ಅಥವಾ ಸೆಕೆಂಡರಿ ಲಾಗ್ ಸಾಧನವು ಕೇವಲ ಒಂದು ವಿಶೇಷ - ಮತ್ತು ಮೇಲಾಗಿ ಅತ್ಯಂತ ವೇಗದ - vdev ಆಗಿದ್ದು, ZIL ಅನ್ನು ಮುಖ್ಯ ಸಂಗ್ರಹಣೆಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಗ್ರಹಿಸಬಹುದು

ಕ್ರ್ಯಾಶ್‌ನ ನಂತರ, ZIL ನಲ್ಲಿನ ಎಲ್ಲಾ ಕೊಳಕು ಡೇಟಾವನ್ನು ಮರುಪಂದ್ಯ ಮಾಡಲಾಗುತ್ತದೆ - ಈ ಸಂದರ್ಭದಲ್ಲಿ, ZIL SLOG ನಲ್ಲಿದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಮರುಪಂದ್ಯ ಮಾಡಲಾಗುತ್ತದೆ

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

ಸಿಂಕ್ರೊನಸ್ ರೆಕಾರ್ಡಿಂಗ್ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ವಿಷಯವಾಗಿದೆ. ಅಪ್ಲಿಕೇಶನ್ ಸಿಂಕ್ರೊನಸ್ ರೈಟ್ ಅನ್ನು ವಿನಂತಿಸಿದಾಗ, ಅದು ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗೆ ಹೇಳುತ್ತದೆ: "ನೀವು ಇದನ್ನು ಬಾಷ್ಪಶೀಲವಲ್ಲದ ಮೆಮೊರಿಗೆ ಒಪ್ಪಿಸಬೇಕಾಗಿದೆ ಇದೀಗ, ಮತ್ತು ಅಲ್ಲಿಯವರೆಗೆ ನಾನು ಏನೂ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆದ್ದರಿಂದ, ಸಿಂಕ್ರೊನಸ್ ಬರಹಗಳು ತಕ್ಷಣವೇ ಡಿಸ್ಕ್‌ಗೆ ಬದ್ಧವಾಗಿರಬೇಕು-ಮತ್ತು ಅದು ವಿಘಟನೆಯನ್ನು ಹೆಚ್ಚಿಸಿದರೆ ಅಥವಾ ಥ್ರೋಪುಟ್ ಅನ್ನು ಕಡಿಮೆಗೊಳಿಸಿದರೆ, ಅದು ಆಗಿರಲಿ.

ZFS ಸಾಮಾನ್ಯ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗಿಂತ ವಿಭಿನ್ನವಾಗಿ ಸಿಂಕ್ರೊನಸ್ ಬರಹಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ-ಅವುಗಳನ್ನು ತಕ್ಷಣವೇ ಸಾಮಾನ್ಯ ಸಂಗ್ರಹಣೆಗೆ ಫ್ಲಶ್ ಮಾಡುವ ಬದಲು, ZFS ಅವುಗಳನ್ನು ZFS ಇಂಟೆಂಟ್ ಲಾಗ್ ಅಥವಾ ZIL ಎಂಬ ವಿಶೇಷ ಶೇಖರಣಾ ಪ್ರದೇಶಕ್ಕೆ ಒಪ್ಪಿಸುತ್ತದೆ. ಟ್ರಿಕ್ ಈ ದಾಖಲೆಗಳು ಸಹ ಸ್ಮೃತಿಯಲ್ಲಿ ಉಳಿಯುತ್ತದೆ, ಸಾಮಾನ್ಯ ಅಸಮಕಾಲಿಕ ಬರವಣಿಗೆ ವಿನಂತಿಗಳೊಂದಿಗೆ ಒಟ್ಟುಗೂಡಿಸಿ, ನಂತರ ಸಂಪೂರ್ಣ ಸಾಮಾನ್ಯ TXG ಗಳಾಗಿ (ವಹಿವಾಟು ಗುಂಪುಗಳು) ಸಂಗ್ರಹಣೆಗೆ ಫ್ಲಶ್ ಮಾಡಲಾಗುತ್ತದೆ.

ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ, ZIL ಅನ್ನು ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಮತ್ತೆ ಓದುವುದಿಲ್ಲ. ಕೆಲವು ಕ್ಷಣಗಳ ನಂತರ, ZIL ನಿಂದ ದಾಖಲೆಗಳು RAM ನಿಂದ ಸಾಮಾನ್ಯ TXG ಗಳಲ್ಲಿ ಮುಖ್ಯ ಸಂಗ್ರಹಣೆಗೆ ಬದ್ಧವಾದಾಗ, ಅವುಗಳನ್ನು ZIL ನಿಂದ ಬೇರ್ಪಡಿಸಲಾಗುತ್ತದೆ. ಪೂಲ್ ಅನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳುವಾಗ ಮಾತ್ರ ZIL ನಿಂದ ಏನನ್ನಾದರೂ ಓದಲಾಗುತ್ತದೆ.

ZIL ನಲ್ಲಿ ಡೇಟಾ ಇರುವಾಗ ZFS ಕ್ರ್ಯಾಶ್ ಸಂಭವಿಸಿದಲ್ಲಿ - ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್ ಅಥವಾ ವಿದ್ಯುತ್ ನಿಲುಗಡೆ - ಮುಂದಿನ ಪೂಲ್ ಆಮದು ಸಮಯದಲ್ಲಿ ಆ ಡೇಟಾವನ್ನು ಓದಲಾಗುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಕ್ರ್ಯಾಶ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದಾಗ). ZIL ನಲ್ಲಿ ಏನಿದೆಯೋ ಅದನ್ನು ಓದಲಾಗುತ್ತದೆ, TXG ಗಳಾಗಿ ಗುಂಪು ಮಾಡಲಾಗುತ್ತದೆ, ಮುಖ್ಯ ಅಂಗಡಿಗೆ ಬದ್ಧವಾಗಿರುತ್ತದೆ ಮತ್ತು ಆಮದು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ZIL ನಿಂದ ಬೇರ್ಪಡುತ್ತದೆ.

vdev ಸಹಾಯಕ ವರ್ಗಗಳಲ್ಲಿ ಒಂದನ್ನು LOG ಅಥವಾ SLOG ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಇದು ದ್ವಿತೀಯ ಲಾಗ್ ಸಾಧನವಾಗಿದೆ. ಇದು ಒಂದು ಉದ್ದೇಶವನ್ನು ಹೊಂದಿದೆ - ZIL ಅನ್ನು ಮುಖ್ಯ vdev ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ZIL ಅನ್ನು ಸಂಗ್ರಹಿಸುವ ಬದಲು ಪ್ರತ್ಯೇಕವಾದ ಮತ್ತು ಮೇಲಾಗಿ ಹೆಚ್ಚು ವೇಗವಾದ, ಬರೆಯಲು ನಿರೋಧಕವಾದ vdev ಸಾಧನದೊಂದಿಗೆ ಪೂಲ್ ಅನ್ನು ಒದಗಿಸುವುದು. ಶೇಖರಣಾ ಸ್ಥಳವನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ ZIL ಸ್ವತಃ ಅದೇ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ, ಆದರೆ LOG ನೊಂದಿಗೆ vdev ಅತಿ ಹೆಚ್ಚು ಬರೆಯುವ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೊಂದಿದ್ದರೆ, ಸಿಂಕ್ರೊನಸ್ ಬರಹಗಳು ವೇಗವಾಗಿರುತ್ತದೆ.

ಪೂಲ್‌ಗೆ LOG ಜೊತೆಗೆ vdev ಅನ್ನು ಸೇರಿಸುವುದು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಸಾಧ್ಯವಿಲ್ಲ ಅಸಮಕಾಲಿಕ ಬರವಣಿಗೆ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಿ - ನೀವು ಎಲ್ಲಾ ಬರಹಗಳನ್ನು ZIL ಗೆ ಒತ್ತಾಯಿಸಿದರೂ ಸಹ zfs set sync=always, ಅವರು ಇನ್ನೂ ಅದೇ ರೀತಿಯಲ್ಲಿ ಮತ್ತು ಲಾಗ್ ಇಲ್ಲದೆ ಅದೇ ವೇಗದಲ್ಲಿ TXG ನಲ್ಲಿ ಮುಖ್ಯ ಸಂಗ್ರಹಣೆಗೆ ಲಿಂಕ್ ಮಾಡಲಾಗುವುದು. ಸಿಂಕ್ರೊನಸ್ ರೈಟ್ ಲೇಟೆನ್ಸಿ ಮಾತ್ರ ನೇರ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸುಧಾರಣೆಯಾಗಿದೆ (ಹೆಚ್ಚಿನ ಲಾಗ್ ವೇಗವು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ವೇಗವಾಗಿ ಮಾಡುತ್ತದೆ sync).

ಆದಾಗ್ಯೂ, ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಸಿಂಕ್ರೊನಸ್ ಬರಹಗಳ ಅಗತ್ಯವಿರುವ ಪರಿಸರದಲ್ಲಿ, vdev LOG ಪರೋಕ್ಷವಾಗಿ ಅಸಮಕಾಲಿಕ ಬರಹಗಳು ಮತ್ತು ಕ್ಯಾಶ್ ಮಾಡದ ಓದುವಿಕೆಯನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ. ZIL ದಾಖಲೆಗಳನ್ನು ಪ್ರತ್ಯೇಕ vdev LOG ಗೆ ಆಫ್‌ಲೋಡ್ ಮಾಡುವುದು ಎಂದರೆ ಪ್ರಾಥಮಿಕ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ IOPS ಗಾಗಿ ಕಡಿಮೆ ವಿವಾದ, ಇದು ಎಲ್ಲಾ ಓದುವ ಮತ್ತು ಬರೆಯುವ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸ್ವಲ್ಪ ಮಟ್ಟಿಗೆ ಸುಧಾರಿಸುತ್ತದೆ.

ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು

ನಕಲು-ಆನ್-ಬರೆ ಕಾರ್ಯವಿಧಾನವು ZFS ಪರಮಾಣು ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಮತ್ತು ಹೆಚ್ಚುತ್ತಿರುವ ಅಸಮಕಾಲಿಕ ಪ್ರತಿಕೃತಿಗೆ ಅಗತ್ಯವಾದ ಅಡಿಪಾಯವಾಗಿದೆ. ಸಕ್ರಿಯ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಪ್ರಸ್ತುತ ಡೇಟಾದೊಂದಿಗೆ ಎಲ್ಲಾ ನಮೂದುಗಳನ್ನು ಗುರುತಿಸುವ ಪಾಯಿಂಟರ್ ಟ್ರೀ ಅನ್ನು ಹೊಂದಿದೆ - ನೀವು ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡಾಗ, ನೀವು ಆ ಪಾಯಿಂಟರ್ ಟ್ರೀನ ನಕಲನ್ನು ಸರಳವಾಗಿ ಮಾಡಿ.

ಸಕ್ರಿಯ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ದಾಖಲೆಯನ್ನು ತಿದ್ದಿ ಬರೆಯುವಾಗ, ZFS ಮೊದಲು ಬ್ಲಾಕ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಬಳಕೆಯಾಗದ ಜಾಗಕ್ಕೆ ಬರೆಯುತ್ತದೆ. ನಂತರ ಬ್ಲಾಕ್ನ ಹಳೆಯ ಆವೃತ್ತಿಯನ್ನು ಪ್ರಸ್ತುತ ಫೈಲ್ ಸಿಸ್ಟಮ್ನಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಆದರೆ ಕೆಲವು ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಹಳೆಯ ಬ್ಲಾಕ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಿದರೆ, ಅದು ಇನ್ನೂ ಬದಲಾಗದೆ ಉಳಿಯುತ್ತದೆ. ಆ ಬ್ಲಾಕ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುವ ಎಲ್ಲಾ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ನಾಶವಾಗುವವರೆಗೆ ಹಳೆಯ ಬ್ಲಾಕ್ ಅನ್ನು ಮುಕ್ತ ಸ್ಥಳವಾಗಿ ಮರುಸ್ಥಾಪಿಸಲಾಗುವುದಿಲ್ಲ!

ಪ್ರತಿಕೃತಿ

2015 ರಲ್ಲಿ ನನ್ನ ಸ್ಟೀಮ್ ಲೈಬ್ರರಿ 158 GiB ಆಗಿತ್ತು ಮತ್ತು 126 ಫೈಲ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಇದು rsync ಗಾಗಿ ಸೂಕ್ತ ಪರಿಸ್ಥಿತಿಗೆ ಬಹಳ ಹತ್ತಿರದಲ್ಲಿದೆ - ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ZFS ನಕಲು "ಕೇವಲ" 927% ವೇಗವಾಗಿದೆ.

ಅದೇ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ, ಒಂದೇ 40GB ವಿಂಡೋಸ್ 7 ವರ್ಚುವಲ್ ಮೆಷಿನ್ ಇಮೇಜ್ ಫೈಲ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸುವುದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಕಥೆಯಾಗಿದೆ. ZFS ಪುನರಾವರ್ತನೆಯು rsync ಗಿಂತ 289 ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ ಅಥವಾ --inplace ಸ್ವಿಚ್‌ನೊಂದಿಗೆ rsync ಅನ್ನು ಕರೆಯಲು ನೀವು ಸಾಕಷ್ಟು ಬುದ್ಧಿವಂತರಾಗಿದ್ದರೆ "ಮಾತ್ರ" 161 ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ.

VM ಇಮೇಜ್ ಸ್ಕೇಲ್ ಮಾಡಿದಾಗ, ಅದರೊಂದಿಗೆ rsync ಸಮಸ್ಯೆಗಳು ಸ್ಕೇಲ್ ಆಗುತ್ತವೆ. ಆಧುನಿಕ VM ಇಮೇಜ್‌ಗೆ 1,9 TiB ಗಾತ್ರವು ಅಷ್ಟು ದೊಡ್ಡದಲ್ಲ - ಆದರೆ Rsync --inplace ವಾದದೊಂದಿಗೆ ಸಹ ZFS ನಕಲು rsync ಗಿಂತ 1148 ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ.

ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಒಮ್ಮೆ ನೀವು ಅರ್ಥಮಾಡಿಕೊಂಡರೆ, ಪ್ರತಿಕೃತಿಯ ಸಾರವನ್ನು ಗ್ರಹಿಸಲು ಸುಲಭವಾಗುತ್ತದೆ. ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಸರಳವಾಗಿ ರೆಕಾರ್ಡ್ ಪಾಯಿಂಟರ್‌ಗಳ ಮರವಾಗಿರುವುದರಿಂದ, ನಾವು ಮಾಡಿದರೆ ಅದು ಅನುಸರಿಸುತ್ತದೆ zfs send ಸ್ನ್ಯಾಪ್‌ಶಾಟ್, ನಂತರ ನಾವು ಈ ಮರವನ್ನು ಮತ್ತು ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲಾ ದಾಖಲೆಗಳನ್ನು ಕಳುಹಿಸುತ್ತೇವೆ. ನಾವು ಇದನ್ನು ಹಾದುಹೋದಾಗ zfs send в zfs receive ಗುರಿ ವಸ್ತುವಿನ ಮೇಲೆ, ಇದು ಬ್ಲಾಕ್‌ನ ನೈಜ ವಿಷಯಗಳನ್ನು ಮತ್ತು ಗುರಿ ಡೇಟಾ ಸೆಟ್‌ಗೆ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವ ಪಾಯಿಂಟರ್‌ಗಳ ಮರ ಎರಡನ್ನೂ ಬರೆಯುತ್ತದೆ.

ಎರಡನೆಯದರಲ್ಲಿ ವಿಷಯಗಳು ಇನ್ನಷ್ಟು ಆಸಕ್ತಿದಾಯಕವಾಗುತ್ತವೆ zfs send. ನಾವು ಈಗ ಎರಡು ವ್ಯವಸ್ಥೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಪ್ರತಿಯೊಂದೂ ಒಳಗೊಂಡಿದೆ poolname/datasetname@1, ಮತ್ತು ನೀವು ಹೊಸ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೀರಿ poolname/datasetname@2. ಆದ್ದರಿಂದ, ನೀವು ಹೊಂದಿರುವ ಮೂಲ ಪೂಲ್ನಲ್ಲಿ datasetname@1 и datasetname@2, ಮತ್ತು ಗುರಿ ಪೂಲ್‌ನಲ್ಲಿ ಮೊದಲ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಮಾತ್ರ ಇರುತ್ತದೆ datasetname@1.

ಏಕೆಂದರೆ ಮೂಲ ಮತ್ತು ಗುರಿಯ ನಡುವೆ ನಾವು ಸಾಮಾನ್ಯ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ datasetname@1, ನಾವು ಇದನ್ನು ಮಾಡಬಹುದು ಹೆಚ್ಚುತ್ತಿರುವ zfs send ಅದರ ಮೇಲೆ. ನಾವು ವ್ಯವಸ್ಥೆಯನ್ನು ಹೇಳಿದಾಗ zfs send -i poolname/datasetname@1 poolname/datasetname@2, ಇದು ಎರಡು ಪಾಯಿಂಟರ್ ಮರಗಳನ್ನು ಹೋಲಿಸುತ್ತದೆ. ಮಾತ್ರ ಇರುವ ಯಾವುದೇ ಪಾಯಿಂಟರ್ಸ್ @2, ನಿಸ್ಸಂಶಯವಾಗಿ ಹೊಸ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಉಲ್ಲೇಖಿಸಿ - ಆದ್ದರಿಂದ ನಮಗೆ ಆ ಬ್ಲಾಕ್‌ಗಳ ವಿಷಯಗಳು ಬೇಕಾಗುತ್ತವೆ.

ರಿಮೋಟ್ ಸಿಸ್ಟಂನಲ್ಲಿ, ಪ್ರೊಸೆಸಿಂಗ್ ಇನ್ಕ್ರಿಮೆಂಟಲ್ send ಕೇವಲ ಸರಳ. ಮೊದಲು ನಾವು ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಸೇರಿಸಲಾದ ಎಲ್ಲಾ ಹೊಸ ನಮೂದುಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ send, ತದನಂತರ ಈ ಬ್ಲಾಕ್‌ಗಳಿಗೆ ಪಾಯಿಂಟರ್‌ಗಳನ್ನು ಸೇರಿಸಿ. Voila, ನಾವು ಹೊಂದಿದ್ದೇವೆ @2 ಹೊಸ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ!

ZFS ಅಸಮಕಾಲಿಕ ಹೆಚ್ಚುತ್ತಿರುವ ಪುನರಾವರ್ತನೆಯು ಹಿಂದಿನ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್-ಆಧಾರಿತ ವಿಧಾನಗಳಾದ rsync ಗಿಂತ ಹೆಚ್ಚಿನ ಸುಧಾರಣೆಯಾಗಿದೆ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಬದಲಾದ ಡೇಟಾವನ್ನು ಮಾತ್ರ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ - ಆದರೆ rsync ಮೊದಲು ಮಾಡಬೇಕು ಓದಿ ಡಿಸ್ಕ್‌ನಿಂದ ಮೊತ್ತವನ್ನು ಪರಿಶೀಲಿಸಲು ಮತ್ತು ಅದನ್ನು ಹೋಲಿಸಲು ಎರಡೂ ಬದಿಗಳಲ್ಲಿನ ಎಲ್ಲಾ ಡೇಟಾ. ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, ZFS ನಕಲು ಪಾಯಿಂಟರ್ ಮರಗಳನ್ನು ಹೊರತುಪಡಿಸಿ ಏನನ್ನೂ ಓದುವುದಿಲ್ಲ - ಮತ್ತು ಒಟ್ಟಾರೆ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ನಲ್ಲಿ ಪ್ರತಿನಿಧಿಸದ ಯಾವುದೇ ಬ್ಲಾಕ್‌ಗಳು.

ಅಂತರ್ನಿರ್ಮಿತ ಸಂಕೋಚನ

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

0x00000000 ರಿಂದ ಸೊನ್ನೆಗಳ ಮೆಗಾಬೈಟ್‌ನಂತೆ ತನ್ನ ಜೀವನವನ್ನು ಪ್ರಾರಂಭಿಸುವ ಫೈಲ್‌ನ ಮಧ್ಯದಲ್ಲಿ ಡೇಟಾದ ತುಣುಕನ್ನು ನೀವು ಪರಿಗಣಿಸಿದರೆ, ಅದನ್ನು ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಒಂದೇ ವಲಯಕ್ಕೆ ಸಂಕುಚಿತಗೊಳಿಸುವುದು ತುಂಬಾ ಸುಲಭ. ಆದರೆ ನಾವು ಈ ಮೆಗಾಬೈಟ್ ಸೊನ್ನೆಗಳನ್ನು ಬದಲಾಯಿಸಿದರೆ ಏನಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ JPEG ಅಥವಾ ಹುಸಿ-ಯಾದೃಚ್ಛಿಕ ಶಬ್ದದಂತಹ ಮೆಗಾಬೈಟ್ ಸಂಕುಚಿತ ಡೇಟಾ? ಇದ್ದಕ್ಕಿದ್ದಂತೆ, ಆ ಮೆಗಾಬೈಟ್ ಡೇಟಾಗೆ ಒಂದಲ್ಲ, 256 4KiB ಸೆಕ್ಟರ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ ಮತ್ತು ಆ ಡಿಸ್ಕ್ ಜಾಗದಲ್ಲಿ ಕೇವಲ ಒಂದು ವಲಯವನ್ನು ಮಾತ್ರ ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ.

ZFS ಈ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿಲ್ಲ ಏಕೆಂದರೆ ಮಾರ್ಪಡಿಸಿದ ಬರಹಗಳನ್ನು ಯಾವಾಗಲೂ ಬಳಕೆಯಾಗದ ಜಾಗಕ್ಕೆ ಬರೆಯಲಾಗುತ್ತದೆ - ಮೂಲ ಬ್ಲಾಕ್ ಕೇವಲ ಒಂದು 4 KiB ಸೆಕ್ಟರ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಹೊಸ ಬರಹವು 256 ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಅದು ಸಮಸ್ಯೆ ಅಲ್ಲ - "ಇತ್ತೀಚಿಗೆ ಮಾರ್ಪಡಿಸಿದ ಭಾಗವಾಗಿದೆ ಫೈಲ್‌ನ ಮಧ್ಯಮ" ಅದರ ಗಾತ್ರ ಬದಲಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆ ಬಳಕೆಯಾಗದ ಜಾಗಕ್ಕೆ ಬರೆಯಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದು ZFS ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿಯಾಗಿದೆ.

ZFS ನ ಅಂತರ್ನಿರ್ಮಿತ ಸಂಕೋಚನವನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಸಿಸ್ಟಮ್ ಪ್ಲಗ್ ಮಾಡಬಹುದಾದ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ-ಪ್ರಸ್ತುತ LZ4, gzip (1-9), LZJB ಮತ್ತು ZLE ಸೇರಿದಂತೆ.

• LZ4 ಇದು ಸ್ಟ್ರೀಮಿಂಗ್ ಅಲ್ಗಾರಿದಮ್ ಆಗಿದ್ದು ಅದು ಅತ್ಯಂತ ವೇಗದ ಸಂಕೋಚನ ಮತ್ತು ಡಿಕಂಪ್ರೆಷನ್ ಮತ್ತು ಹೆಚ್ಚಿನ ಬಳಕೆಯ ಸಂದರ್ಭಗಳಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಪ್ರಯೋಜನಗಳನ್ನು ನೀಡುತ್ತದೆ-ಸಾಕಷ್ಟು ನಿಧಾನವಾದ CPU ಗಳಲ್ಲಿಯೂ ಸಹ.
• GZIP ಎಲ್ಲಾ Unix ಬಳಕೆದಾರರಿಗೆ ತಿಳಿದಿರುವ ಮತ್ತು ಪ್ರೀತಿಸುವ ಗೌರವಾನ್ವಿತ ಅಲ್ಗಾರಿದಮ್ ಆಗಿದೆ. ನೀವು ಹಂತ 1 ಕ್ಕೆ ಸಮೀಪಿಸುತ್ತಿರುವಂತೆ ಸಂಕೋಚನ ಅನುಪಾತ ಮತ್ತು CPU ಬಳಕೆಯೊಂದಿಗೆ ಸಂಕೋಚನ ಮಟ್ಟಗಳು 9-9 ರೊಂದಿಗೆ ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಅಲ್ಗಾರಿದಮ್ ಎಲ್ಲಾ ಪಠ್ಯ (ಅಥವಾ ಇತರ ಹೆಚ್ಚು ಸಂಕುಚಿತ) ಬಳಕೆಯ ಸಂದರ್ಭಗಳಿಗೆ ಸೂಕ್ತವಾಗಿರುತ್ತದೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ CPU ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಎಚ್ಚರಿಕೆಯಿಂದ, ವಿಶೇಷವಾಗಿ ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ.
• LZJB - ZFS ನಲ್ಲಿ ಮೂಲ ಅಲ್ಗಾರಿದಮ್. ಇದು ಬಳಕೆಯಲ್ಲಿಲ್ಲ ಮತ್ತು ಇನ್ನು ಮುಂದೆ ಬಳಸಬಾರದು, LZ4 ಎಲ್ಲ ರೀತಿಯಲ್ಲೂ ಉತ್ತಮವಾಗಿದೆ.
• ಕೆಟ್ಟದಾಗಿ - ಶೂನ್ಯ ಮಟ್ಟದ ಎನ್ಕೋಡಿಂಗ್, ಶೂನ್ಯ ಮಟ್ಟದ ಎನ್ಕೋಡಿಂಗ್. ಇದು ಸಾಮಾನ್ಯ ಡೇಟಾವನ್ನು ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ, ಆದರೆ ಇದು ಸೊನ್ನೆಗಳ ದೊಡ್ಡ ಅನುಕ್ರಮಗಳನ್ನು ಸಂಕುಚಿತಗೊಳಿಸುತ್ತದೆ. ಸಂಪೂರ್ಣ ಸಂಕುಚಿತಗೊಳಿಸಲಾಗದ ಡೇಟಾ ಸೆಟ್‌ಗಳಿಗೆ (ಉದಾಹರಣೆಗೆ JPEG, MP4 ಅಥವಾ ಇತರ ಈಗಾಗಲೇ ಸಂಕುಚಿತ ಸ್ವರೂಪಗಳು) ಉಪಯುಕ್ತವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಸಂಕುಚಿತಗೊಳಿಸಲಾಗದ ಡೇಟಾವನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ ಆದರೆ ಪರಿಣಾಮವಾಗಿ ದಾಖಲೆಗಳಲ್ಲಿ ಬಳಕೆಯಾಗದ ಜಾಗವನ್ನು ಸಂಕುಚಿತಗೊಳಿಸುತ್ತದೆ.

ಬಹುತೇಕ ಎಲ್ಲಾ ಬಳಕೆಯ ಸಂದರ್ಭಗಳಿಗಾಗಿ ನಾವು LZ4 ಕಂಪ್ರೆಷನ್ ಅನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ; ಸಂಕುಚಿತಗೊಳಿಸಲಾಗದ ಡೇಟಾದೊಂದಿಗೆ ವ್ಯವಹರಿಸುವಾಗ ಕಾರ್ಯಕ್ಷಮತೆಯ ದಂಡವು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ, ಮತ್ತು ಬೆಳವಣಿಗೆ ವಿಶಿಷ್ಟ ಡೇಟಾದ ಕಾರ್ಯಕ್ಷಮತೆ ಗಮನಾರ್ಹವಾಗಿದೆ. ವಿಂಡೋಸ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಹೊಸ ಸ್ಥಾಪನೆಗಾಗಿ ವರ್ಚುವಲ್ ಮೆಷಿನ್ ಇಮೇಜ್ ಅನ್ನು ನಕಲಿಸಲಾಗುತ್ತಿದೆ (ಹೊಸದಾಗಿ ಸ್ಥಾಪಿಸಲಾದ OS, ಒಳಗೆ ಯಾವುದೇ ಡೇಟಾ ಇಲ್ಲ) compression=lz4 ಗಿಂತ 27% ವೇಗವಾಗಿ ಉತ್ತೀರ್ಣರಾದರು compression=none, ಇನ್ 2015 ರಿಂದ ಈ ಪರೀಕ್ಷೆ.

ARC - ಅಡಾಪ್ಟಿವ್ ರಿಪ್ಲೇಸ್‌ಮೆಂಟ್ ಸಂಗ್ರಹ

ZFS ಎಂಬುದು ನಮಗೆ ತಿಳಿದಿರುವ ಏಕೈಕ ಆಧುನಿಕ ಫೈಲ್ ಸಿಸ್ಟಮ್ ಆಗಿದ್ದು, RAM ನಲ್ಲಿ ಇತ್ತೀಚೆಗೆ ಓದಿದ ಬ್ಲಾಕ್‌ಗಳ ನಕಲುಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನ ಪುಟ ಸಂಗ್ರಹವನ್ನು ಅವಲಂಬಿಸುವ ಬದಲು ತನ್ನದೇ ಆದ ಓದುವ ಕ್ಯಾಶಿಂಗ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸುತ್ತದೆ.

ಸ್ಥಳೀಯ ಸಂಗ್ರಹವು ಸಮಸ್ಯೆಗಳಿಲ್ಲದಿದ್ದರೂ - ZFS ಹೊಸ ಮೆಮೊರಿ ಹಂಚಿಕೆ ವಿನಂತಿಗಳಿಗೆ ಕರ್ನಲ್‌ನಂತೆ ತ್ವರಿತವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಹೊಸ ಕರೆ malloc() ಪ್ರಸ್ತುತ ARC ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ RAM ಅಗತ್ಯವಿದ್ದರೆ ಮೆಮೊರಿ ಹಂಚಿಕೆ ವಿಫಲವಾಗಬಹುದು. ಆದರೆ ನಿಮ್ಮ ಸ್ವಂತ ಸಂಗ್ರಹವನ್ನು ಬಳಸಲು ಉತ್ತಮ ಕಾರಣಗಳಿವೆ, ಕನಿಷ್ಠ ಇದೀಗ.

MacOS, Windows, Linux ಮತ್ತು BSD ಸೇರಿದಂತೆ ಎಲ್ಲಾ ತಿಳಿದಿರುವ ಆಧುನಿಕ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳು, ಪುಟ ಸಂಗ್ರಹವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು LRU (ಕನಿಷ್ಠ ಇತ್ತೀಚೆಗೆ ಬಳಸಲಾಗಿದೆ) ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಬಳಸುತ್ತವೆ. ಇದು ಒಂದು ಪ್ರಾಚೀನ ಅಲ್ಗಾರಿದಮ್ ಆಗಿದ್ದು, ಪ್ರತಿ ಓದಿದ ನಂತರ ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಬ್ಲಾಕ್ ಅನ್ನು "ಸರದಿಯ ಮೇಲ್ಭಾಗಕ್ಕೆ" ತಳ್ಳುತ್ತದೆ ಮತ್ತು ಹೊಸ ಕ್ಯಾಶ್ ಮಿಸ್‌ಗಳನ್ನು ಸೇರಿಸಲು ಅಗತ್ಯವಿರುವಂತೆ ಬ್ಲಾಕ್‌ಗಳನ್ನು "ಸರದಿಯ ಕೆಳಭಾಗಕ್ಕೆ" ತಳ್ಳುತ್ತದೆ (ಬ್ಲಾಕ್‌ಗಳನ್ನು ಡಿಸ್ಕ್‌ನಿಂದ ಓದುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಓದಬೇಕು. ಸಂಗ್ರಹದಿಂದ) ಮೇಲಕ್ಕೆ.

ಸಾಮಾನ್ಯವಾಗಿ ಅಲ್ಗಾರಿದಮ್ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ದೊಡ್ಡ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಡೇಟಾ ಸೆಟ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಸಿಸ್ಟಮ್‌ಗಳಲ್ಲಿ, LRU ಸುಲಭವಾಗಿ ಥ್ರಾಶಿಂಗ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ-ಸಂಗ್ರಹದಿಂದ ಎಂದಿಗೂ ಓದದ ಬ್ಲಾಕ್‌ಗಳಿಗೆ ಸ್ಥಳಾವಕಾಶವನ್ನು ಮಾಡಲು ಆಗಾಗ್ಗೆ ಅಗತ್ಯವಿರುವ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಹೊರಹಾಕುತ್ತದೆ.

ARC "ತೂಕದ" ಸಂಗ್ರಹವೆಂದು ಪರಿಗಣಿಸಬಹುದಾದ ಕಡಿಮೆ ನಿಷ್ಕಪಟ ಅಲ್ಗಾರಿದಮ್ ಆಗಿದೆ. ಪ್ರತಿ ಬಾರಿ ಕ್ಯಾಶ್ ಮಾಡಿದ ಬ್ಲಾಕ್ ಅನ್ನು ಓದಿದಾಗ, ಅದು ಸ್ವಲ್ಪ "ಭಾರವಾಗಿರುತ್ತದೆ" ಮತ್ತು ಹೊರಹಾಕಲು ಕಷ್ಟವಾಗುತ್ತದೆ - ಮತ್ತು ಬ್ಲಾಕ್ ಅನ್ನು ಹೊರಹಾಕಿದ ನಂತರವೂ ಟ್ರ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಅವಧಿಯಲ್ಲಿ. ಹೊರಹಾಕಲ್ಪಟ್ಟ ಆದರೆ ನಂತರ ಸಂಗ್ರಹಕ್ಕೆ ಮತ್ತೆ ಓದಬೇಕಾದ ಬ್ಲಾಕ್ ಕೂಡ ಭಾರವಾಗಿರುತ್ತದೆ.

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

ತೀರ್ಮಾನಕ್ಕೆ

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

ಮುಂದಿನ ಭಾಗದಲ್ಲಿ, ನಾವು ಪ್ರತಿಬಿಂಬಿತ vdev ಮತ್ತು RAIDz ಪೂಲ್‌ಗಳ ನೈಜ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೋಡುತ್ತೇವೆ, ಪರಸ್ಪರ ಹೋಲಿಸಿದರೆ, ಮತ್ತು ನಾವು ಪರಿಶೀಲಿಸಿದ ಸಾಂಪ್ರದಾಯಿಕ Linux ಕರ್ನಲ್ RAID ಟೋಪೋಲಾಜಿಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಮೊದಲು.

ಮೊದಲಿಗೆ ನಾವು ಕೇವಲ ಮೂಲಭೂತ ಅಂಶಗಳನ್ನು-ZFS ಟೋಪೋಲಾಜಿಗಳನ್ನು ಕವರ್ ಮಾಡಲು ಬಯಸಿದ್ದೇವೆ-ಆದರೆ ನಂತರ ಅಂತಹ L2ARC, SLOG ಮತ್ತು ವಿಶೇಷ ಹಂಚಿಕೆಯಂತಹ ಸಹಾಯಕ vdev ಪ್ರಕಾರಗಳ ಬಳಕೆ ಸೇರಿದಂತೆ ZFS ನ ಹೆಚ್ಚು ಸುಧಾರಿತ ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಟ್ಯೂನಿಂಗ್ ಕುರಿತು ಮಾತನಾಡಲು ನಾವು ಸಿದ್ಧರಾಗಿದ್ದೇವೆ.

ಮೂಲ: www.habr.com