ਇਸ ਬਸੰਤ ਵਿੱਚ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਸ਼ੁਰੂਆਤੀ ਵਿਸ਼ਿਆਂ 'ਤੇ ਚਰਚਾ ਕੀਤੀ ਹੈ, ਜਿਵੇਂ ਕਿ. ਤੁਹਾਡੀਆਂ ਡਰਾਈਵਾਂ ਦੀ ਗਤੀ ਦੀ ਜਾਂਚ ਕਿਵੇਂ ਕਰੀਏ и RAID ਕੀ ਹੈ. ਇਹਨਾਂ ਵਿੱਚੋਂ ਦੂਜੇ ਵਿੱਚ, ਅਸੀਂ ZFS ਵਿੱਚ ਵੱਖ-ਵੱਖ ਮਲਟੀ-ਡਿਸਕ ਟੋਪੋਲੋਜੀਜ਼ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦਾ ਅਧਿਐਨ ਕਰਨਾ ਜਾਰੀ ਰੱਖਣ ਦਾ ਵਾਅਦਾ ਵੀ ਕੀਤਾ ਹੈ। ਇਹ ਅਗਲੀ ਪੀੜ੍ਹੀ ਦਾ ਫਾਈਲ ਸਿਸਟਮ ਹੈ ਜੋ ਹੁਣ ਹਰ ਥਾਂ ਤੈਨਾਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਸੇਬ ਨੂੰ Ubuntu.

ਖੈਰ, ਅੱਜ ZFS, ਉਤਸੁਕ ਪਾਠਕਾਂ ਨਾਲ ਜਾਣੂ ਹੋਣ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਦਿਨ ਹੈ। ਬਸ ਇਹ ਜਾਣੋ ਕਿ OpenZFS ਡਿਵੈਲਪਰ ਮੈਟ ਅਹਰੰਸ ਦੇ ਨਿਮਰ ਮੁਲਾਂਕਣ ਵਿੱਚ, "ਇਹ ਅਸਲ ਵਿੱਚ ਔਖਾ ਹੈ।"

ਪਰ ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਅਸੀਂ ਨੰਬਰਾਂ 'ਤੇ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ-ਅਤੇ ਉੱਥੇ ਹੋਵੇਗਾ, ਮੈਂ ਵਾਅਦਾ ਕਰਦਾ ਹਾਂ-ਸਾਰੇ ਅੱਠ-ਡਿਸਕ ZFS ਸੰਰਚਨਾ ਵਿਕਲਪਾਂ ਲਈ, ਸਾਨੂੰ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ, ZFS ਡਿਸਕ 'ਤੇ ਡਾਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ।

Zpool, vdev ਅਤੇ ਡਿਵਾਈਸ

ਇਸ ਪੂਰੇ ਪੂਲ ਚਿੱਤਰ ਵਿੱਚ ਤਿੰਨ ਸਹਾਇਕ vdevs, ਹਰੇਕ ਕਲਾਸ ਵਿੱਚੋਂ ਇੱਕ, ਅਤੇ RAIDz2 ਲਈ ਚਾਰ ਸ਼ਾਮਲ ਹਨ।

ਆਮ ਤੌਰ 'ਤੇ ਮੇਲ ਖਾਂਦੀਆਂ vdev ਕਿਸਮਾਂ ਅਤੇ ਆਕਾਰਾਂ ਦਾ ਪੂਲ ਬਣਾਉਣ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਹੁੰਦਾ - ਪਰ ਜੇਕਰ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਕਰਨ ਤੋਂ ਕੁਝ ਵੀ ਨਹੀਂ ਰੋਕ ਸਕਦਾ।

ZFS ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਅਸਲ ਵਿੱਚ ਸਮਝਣ ਲਈ, ਤੁਹਾਨੂੰ ਇਸਦੇ ਅਸਲ ਢਾਂਚੇ 'ਤੇ ਇੱਕ ਡੂੰਘੀ ਵਿਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਪਹਿਲਾਂ, ZFS ਪਰੰਪਰਾਗਤ ਵਾਲੀਅਮ ਅਤੇ ਫਾਈਲ ਸਿਸਟਮ ਪ੍ਰਬੰਧਨ ਲੇਅਰਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ। ਦੂਜਾ, ਇਹ ਇੱਕ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਕਾਪੀ-ਆਨ-ਰਾਈਟ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਿਸਟਮ ਢਾਂਚਾਗਤ ਤੌਰ 'ਤੇ ਰਵਾਇਤੀ ਫਾਈਲ ਸਿਸਟਮਾਂ ਅਤੇ RAID ਐਰੇ ਤੋਂ ਬਹੁਤ ਵੱਖਰਾ ਹੈ। ਸਮਝਣ ਲਈ ਬੁਨਿਆਦੀ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਦਾ ਪਹਿਲਾ ਸੈੱਟ ਸਟੋਰੇਜ ਪੂਲ (zpool), ਵਰਚੁਅਲ ਡਿਵਾਈਸ (vdev) ਅਤੇ ਅਸਲੀ ਡਿਵਾਈਸ (ਡਿਵਾਈਸ) ਹਨ।

zpool

zpool ਸਟੋਰੇਜ ਪੂਲ ਸਭ ਤੋਂ ਉੱਚਾ ZFS ਢਾਂਚਾ ਹੈ। ਹਰੇਕ ਪੂਲ ਵਿੱਚ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਵਰਚੁਅਲ ਯੰਤਰ ਹੁੰਦੇ ਹਨ। ਬਦਲੇ ਵਿੱਚ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਅਸਲ ਯੰਤਰ (ਡਿਵਾਈਸ) ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਵਰਚੁਅਲ ਪੂਲ ਸਵੈ-ਨਿਰਭਰ ਇਕਾਈਆਂ ਹਨ। ਇੱਕ ਭੌਤਿਕ ਕੰਪਿਊਟਰ ਵਿੱਚ ਦੋ ਜਾਂ ਵੱਧ ਵੱਖਰੇ ਪੂਲ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਹਰ ਇੱਕ ਦੂਜੇ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਤੰਤਰ ਹੈ। ਪੂਲ ਵਰਚੁਅਲ ਡਿਵਾਈਸਾਂ ਨੂੰ ਸਾਂਝਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਨ।

ZFS ਰਿਡੰਡੈਂਸੀ ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਪੱਧਰ 'ਤੇ ਹੈ, ਪੂਲ ਪੱਧਰ 'ਤੇ ਨਹੀਂ। ਪੂਲ ਪੱਧਰ 'ਤੇ ਬਿਲਕੁਲ ਕੋਈ ਵੀ ਰਿਡੰਡੈਂਸੀ ਨਹੀਂ ਹੈ-ਜੇਕਰ ਕੋਈ ਵੀਦੇਵ ਜਾਂ ਸਮਰਪਿਤ ਵੀਦੇਵ ਗੁਆਚ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪੂਰਾ ਪੂਲ ਇਸਦੇ ਨਾਲ ਗੁਆਚ ਜਾਂਦਾ ਹੈ।

ਆਧੁਨਿਕ ਸਟੋਰੇਜ ਪੂਲ ਇੱਕ ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਦੇ ਕੈਸ਼ ਜਾਂ ਲੌਗ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਚ ਸਕਦੇ ਹਨ - ਹਾਲਾਂਕਿ ਉਹ ਥੋੜ੍ਹੇ ਜਿਹੇ ਗੰਦੇ ਡੇਟਾ ਨੂੰ ਗੁਆ ਸਕਦੇ ਹਨ ਜੇਕਰ ਉਹ ਪਾਵਰ ਆਊਟੇਜ ਜਾਂ ਸਿਸਟਮ ਕਰੈਸ਼ ਦੌਰਾਨ vdev ਲੌਗ ਗੁਆ ਦਿੰਦੇ ਹਨ।

ਇੱਕ ਆਮ ਗਲਤ ਧਾਰਨਾ ਹੈ ਕਿ ZFS "ਡੇਟਾ ਸਟ੍ਰਾਈਪ" ਪੂਰੇ ਪੂਲ ਵਿੱਚ ਲਿਖੇ ਗਏ ਹਨ। ਇਹ ਸੱਚ ਨਹੀਂ ਹੈ। Zpool ਇੱਕ ਮਜ਼ਾਕੀਆ RAID0 ਨਹੀਂ ਹੈ, ਇਹ ਇੱਕ ਹੋਰ ਮਜ਼ਾਕੀਆ ਹੈ ਜੇਬੀਓਡੀ ਇੱਕ ਗੁੰਝਲਦਾਰ ਪਰਿਵਰਤਨਸ਼ੀਲ ਵੰਡ ਵਿਧੀ ਦੇ ਨਾਲ।

ਜ਼ਿਆਦਾਤਰ ਹਿੱਸੇ ਲਈ, ਰਿਕਾਰਡ ਉਪਲਬਧ ਖਾਲੀ ਥਾਂ ਦੇ ਅਨੁਸਾਰ ਉਪਲਬਧ ਵਰਚੁਅਲ ਡਿਵਾਈਸਾਂ ਵਿੱਚ ਵੰਡੇ ਜਾਂਦੇ ਹਨ, ਇਸਲਈ ਸਿਧਾਂਤ ਵਿੱਚ ਉਹ ਸਾਰੇ ਇੱਕੋ ਸਮੇਂ ਭਰੇ ਜਾਣਗੇ। ZFS ਦੇ ਹੋਰ ਤਾਜ਼ਾ ਸੰਸਕਰਣ ਮੌਜੂਦਾ vdev ਵਰਤੋਂ (ਉਪਯੋਗਤਾ) ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹਨ - ਜੇਕਰ ਇੱਕ ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਦੂਜੇ ਨਾਲੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਵਿਅਸਤ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਰੀਡ ਲੋਡ ਦੇ ਕਾਰਨ), ਸਭ ਤੋਂ ਵੱਧ ਖਾਲੀ ਸਪੇਸ ਅਨੁਪਾਤ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਇਸਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਲਿਖਣ ਲਈ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇਗਾ।

ਆਧੁਨਿਕ ZFS ਰਾਈਟ ਐਲੋਕੇਸ਼ਨ ਵਿਧੀਆਂ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਰੀਸਾਈਕਲਿੰਗ ਖੋਜ ਵਿਧੀ ਲੇਟੈਂਸੀ ਨੂੰ ਘਟਾ ਸਕਦੀ ਹੈ ਅਤੇ ਅਸਧਾਰਨ ਤੌਰ 'ਤੇ ਉੱਚ ਲੋਡ ਦੇ ਸਮੇਂ ਦੌਰਾਨ ਥ੍ਰੁਪੁੱਟ ਨੂੰ ਵਧਾ ਸਕਦੀ ਹੈ - ਪਰ ਅਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ। ਕਾਰਟੇ ਬਲੈਂਚ ਇੱਕ ਪੂਲ ਵਿੱਚ ਹੌਲੀ HDDs ਅਤੇ ਤੇਜ਼ SSDs ਦੇ ਅਣਇੱਛਤ ਮਿਸ਼ਰਣ ਲਈ। ਅਜਿਹਾ ਅਸਮਾਨ ਪੂਲ ਅਜੇ ਵੀ ਸਭ ਤੋਂ ਧੀਮੀ ਡਿਵਾਈਸ ਦੀ ਗਤੀ 'ਤੇ ਕੰਮ ਕਰੇਗਾ, ਯਾਨੀ ਜਿਵੇਂ ਕਿ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਜਿਹੇ ਯੰਤਰਾਂ ਨਾਲ ਬਣਿਆ ਹੋਵੇ।

vdev

ਹਰੇਕ ਸਟੋਰੇਜ਼ ਪੂਲ ਵਿੱਚ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਵਰਚੁਅਲ ਯੰਤਰ (vdev) ਹੁੰਦੇ ਹਨ। ਬਦਲੇ ਵਿੱਚ, ਹਰੇਕ vdev ਵਿੱਚ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਅਸਲੀ ਯੰਤਰ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਵਰਚੁਅਲ ਯੰਤਰਾਂ ਦੀ ਵਰਤੋਂ ਸਧਾਰਨ ਡਾਟਾ ਸਟੋਰੇਜ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਕਈ vdev ਸਹਾਇਕ ਕਲਾਸਾਂ ਹਨ, ਜਿਸ ਵਿੱਚ CACHE, LOG, ਅਤੇ SPECIAL ਸ਼ਾਮਲ ਹਨ। ਇਹਨਾਂ vdev ਕਿਸਮਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ ਪੰਜ ਟੋਪੋਲੋਜੀ ਵਿੱਚੋਂ ਇੱਕ ਹੋ ਸਕਦੀ ਹੈ: ਸਿੰਗਲ-ਡਿਵਾਈਸ, RAIDz1, RAIDz2, RAIDz3 ਜਾਂ ਮਿਰਰ।

RAIDz1, RAIDz2 ਅਤੇ RAIDz3 ਖਾਸ ਕਿਸਮਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਪੁਰਾਣੇ ਲੋਕ ਡਬਲ (ਡਾਇਗੋਨਲ) ਪੈਰਿਟੀ RAID ਕਹਿੰਦੇ ਹਨ। 1, 2 ਅਤੇ 3 ਦਾ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ ਕਿ ਹਰੇਕ ਡੇਟਾ ਲੇਨ ਲਈ ਕਿੰਨੇ ਪੈਰੀਟੀ ਬਲਾਕ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਹਨ। ਸਮਾਨਤਾ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਵੱਖਰੀ ਡਿਸਕ ਰੱਖਣ ਦੀ ਬਜਾਏ, ਵਰਚੁਅਲ RAIDz ਜੰਤਰ ਡਿਸਕਾਂ ਵਿੱਚ ਅਰਧ-ਸਮਾਨ ਵੰਡਦੇ ਹਨ। ਇੱਕ RAIDz ਐਰੇ ਬਹੁਤ ਸਾਰੀਆਂ ਡਿਸਕਾਂ ਨੂੰ ਗੁਆ ਸਕਦਾ ਹੈ ਜਿੰਨਾ ਕਿ ਇਸ ਵਿੱਚ ਪੈਰਿਟੀ ਬਲਾਕ ਹਨ; ਜੇਕਰ ਇਹ ਇੱਕ ਹੋਰ ਗੁਆ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਅਸਫਲ ਹੋ ਜਾਵੇਗਾ ਅਤੇ ਸਟੋਰੇਜ ਪੂਲ ਨੂੰ ਆਪਣੇ ਨਾਲ ਲੈ ਜਾਵੇਗਾ।

ਮਿਰਰ ਵਰਚੁਅਲ ਡਿਵਾਈਸਾਂ (ਮਿਰਰ vdev) ਵਿੱਚ, ਹਰੇਕ ਬਲਾਕ ਨੂੰ vdev ਵਿੱਚ ਹਰੇਕ ਡਿਵਾਈਸ ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਹਾਲਾਂਕਿ ਦੋ-ਚੌੜੇ ਸ਼ੀਸ਼ੇ ਸਭ ਤੋਂ ਆਮ ਹੁੰਦੇ ਹਨ, ਇੱਕ ਸ਼ੀਸ਼ੇ ਵਿੱਚ ਕਿਸੇ ਵੀ ਆਪਹੁਦਰੇ ਯੰਤਰ ਹੋ ਸਕਦੇ ਹਨ-ਵੱਡੀਆਂ ਸਥਾਪਨਾਵਾਂ ਵਿੱਚ, ਟ੍ਰਿਪਲ ਦੀ ਵਰਤੋਂ ਅਕਸਰ ਪੜ੍ਹਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇੱਕ vdev ਮਿਰਰ ਕਿਸੇ ਵੀ ਅਸਫਲਤਾ ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੱਕ vdev ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਯੰਤਰ ਚਾਲੂ ਰਹਿੰਦਾ ਹੈ।

ਸਿੰਗਲ vdevs ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਖਤਰਨਾਕ ਹੁੰਦੇ ਹਨ। ਅਜਿਹਾ ਇੱਕ ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਇੱਕ ਵੀ ਅਸਫਲਤਾ ਤੋਂ ਬਚ ਨਹੀਂ ਸਕੇਗਾ - ਅਤੇ ਜੇਕਰ ਸਟੋਰੇਜ ਜਾਂ ਇੱਕ ਵਿਸ਼ੇਸ਼ vdev ਦੇ ਤੌਰ ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦੀ ਅਸਫਲਤਾ ਪੂਰੇ ਪੂਲ ਦੇ ਵਿਨਾਸ਼ ਵੱਲ ਅਗਵਾਈ ਕਰੇਗੀ. ਇੱਥੇ ਬਹੁਤ, ਬਹੁਤ ਸਾਵਧਾਨ ਰਹੋ.

CACHE, LOG, ਅਤੇ SPECIAL ਵਰਚੁਅਲ ਡਿਵਾਈਸਾਂ ਨੂੰ ਉਪਰੋਕਤ ਟੋਪੋਲੋਜੀ ਵਿੱਚੋਂ ਕਿਸੇ ਵਿੱਚ ਵੀ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ - ਪਰ ਯਾਦ ਰੱਖੋ ਕਿ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਨੂੰ ਗੁਆਉਣ ਦਾ ਮਤਲਬ ਪੂਲ ਨੂੰ ਗੁਆਉਣਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਬੇਲੋੜੀ ਟੋਪੋਲੋਜੀ ਦੀ ਜ਼ੋਰਦਾਰ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਜੰਤਰ

ZFS ਵਿੱਚ ਸਮਝਣ ਲਈ ਇਹ ਸ਼ਾਇਦ ਸਭ ਤੋਂ ਆਸਾਨ ਸ਼ਬਦ ਹੈ - ਇਹ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਇੱਕ ਬਲਾਕ ਰੈਂਡਮ ਐਕਸੈਸ ਡਿਵਾਈਸ ਹੈ। ਯਾਦ ਰੱਖੋ ਕਿ ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਵਿਅਕਤੀਗਤ ਡਿਵਾਈਸਾਂ ਦੇ ਬਣੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਪੂਲ ਵਰਚੁਅਲ ਡਿਵਾਈਸਾਂ ਦਾ ਬਣਿਆ ਹੁੰਦਾ ਹੈ।

ਡਿਸਕਾਂ, ਜਾਂ ਤਾਂ ਚੁੰਬਕੀ ਜਾਂ ਠੋਸ ਅਵਸਥਾ, ਸਭ ਤੋਂ ਆਮ ਬਲਾਕ ਯੰਤਰ ਹਨ ਜੋ vdev ਦੇ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਵਜੋਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਹਾਲਾਂਕਿ, /dev ਵਿੱਚ ਡਿਸਕ੍ਰਿਪਟਰ ਵਾਲਾ ਕੋਈ ਵੀ ਜੰਤਰ ਕਰੇਗਾ - ਇਸਲਈ ਪੂਰੇ ਹਾਰਡਵੇਅਰ RAID ਐਰੇ ਨੂੰ ਵਿਅਕਤੀਗਤ ਜੰਤਰ ਵਜੋਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਕ ਸਧਾਰਨ ਕੱਚੀ ਫਾਈਲ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਵਿਕਲਪਕ ਬਲਾਕ ਡਿਵਾਈਸਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜਿਸ ਤੋਂ ਇੱਕ vdev ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਤੋਂ ਟੈਸਟ ਪੂਲ ਸਪਾਰਸ ਫਾਈਲਾਂ ਪੂਲ ਕਮਾਂਡਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਇਹ ਦੇਖਣ ਦਾ ਇੱਕ ਬਹੁਤ ਹੀ ਸੁਵਿਧਾਜਨਕ ਤਰੀਕਾ ਹੈ ਕਿ ਇੱਕ ਪੂਲ ਜਾਂ ਦਿੱਤੇ ਗਏ ਟੋਪੋਲੋਜੀ ਦੇ ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਵਿੱਚ ਕਿੰਨੀ ਥਾਂ ਉਪਲਬਧ ਹੈ।

ਤੁਸੀਂ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਸਪਾਰਸ ਫਾਈਲਾਂ ਤੋਂ ਇੱਕ ਟੈਸਟ ਪੂਲ ਬਣਾ ਸਕਦੇ ਹੋ - ਪਰ ਬਾਅਦ ਵਿੱਚ ਪੂਰੇ ਪੂਲ ਅਤੇ ਇਸਦੇ ਭਾਗਾਂ ਨੂੰ ਮਿਟਾਉਣਾ ਨਾ ਭੁੱਲੋ

ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ ਅੱਠ-ਡਿਸਕ ਸਰਵਰ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ 10TB (~ 9300 GiB) ਡਿਸਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹੋ, ਪਰ ਤੁਸੀਂ ਨਿਸ਼ਚਤ ਨਹੀਂ ਹੋ ਕਿ ਕਿਹੜੀ ਟੋਪੋਲੋਜੀ ਤੁਹਾਡੀਆਂ ਜ਼ਰੂਰਤਾਂ ਦੇ ਅਨੁਕੂਲ ਹੈ। ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਵਿੱਚ, ਅਸੀਂ ਸਕਿੰਟਾਂ ਵਿੱਚ ਸਪਾਰਸ ਫਾਈਲਾਂ ਦਾ ਇੱਕ ਟੈਸਟ ਪੂਲ ਬਣਾਉਂਦੇ ਹਾਂ-ਅਤੇ ਹੁਣ ਜਾਣਦੇ ਹਾਂ ਕਿ ਅੱਠ 2TB ਡਰਾਈਵਾਂ ਦਾ ਇੱਕ RAIDz10 vdev ਉਪਯੋਗਯੋਗ ਸਮਰੱਥਾ ਦੀ 50TiB ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਡਿਵਾਈਸਾਂ ਦੀ ਇੱਕ ਹੋਰ ਵਿਸ਼ੇਸ਼ ਸ਼੍ਰੇਣੀ ਸਪੇਅਰ ਹੈ। ਹਾਟ-ਸਵੈਪ ਡਿਵਾਈਸਾਂ, ਰੈਗੂਲਰ ਡਿਵਾਈਸਾਂ ਦੇ ਉਲਟ, ਇੱਕ ਸਿੰਗਲ ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਦੀ ਬਜਾਏ ਪੂਰੇ ਪੂਲ ਨਾਲ ਸਬੰਧਤ ਹਨ। ਜੇਕਰ ਪੂਲ ਵਿੱਚ ਕੋਈ ਵੀ ਡੀਵੀਵ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਵਾਧੂ ਯੰਤਰ ਪੂਲ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਉਪਲਬਧ ਹੈ, ਤਾਂ ਇਹ ਆਪਣੇ ਆਪ ਪ੍ਰਭਾਵਿਤ vdev ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਜਾਵੇਗਾ।

ਇੱਕ ਵਾਰ ਪ੍ਰਭਾਵਿਤ vdev ਨਾਲ ਕਨੈਕਟ ਹੋ ਜਾਣ 'ਤੇ, ਬਦਲਣ ਵਾਲੀ ਡਿਵਾਈਸ ਡਾਟਾ ਦੀਆਂ ਕਾਪੀਆਂ ਜਾਂ ਪੁਨਰਗਠਨ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੀ ਹੈ ਜੋ ਗੁੰਮ ਹੋਏ ਡਿਵਾਈਸ 'ਤੇ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਪਰੰਪਰਾਗਤ RAID ਵਿੱਚ ਇਸਨੂੰ "ਰੀਬਿਲਡਿੰਗ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ZFS ਵਿੱਚ ਇਸਨੂੰ "ਰਿਸਿਲਵਰਿੰਗ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਇਹ ਨੋਟ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਬਦਲਣ ਵਾਲੀਆਂ ਡਿਵਾਈਸਾਂ ਅਸਫ਼ਲ ਡਿਵਾਈਸਾਂ ਨੂੰ ਸਥਾਈ ਤੌਰ 'ਤੇ ਨਹੀਂ ਬਦਲਦੀਆਂ ਹਨ। ਇਹ vdev ਨੂੰ ਡੀਗਰੇਡ ਹੋਣ ਵਿੱਚ ਲੱਗਣ ਵਾਲੇ ਸਮੇਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਅਸਥਾਈ ਤਬਦੀਲੀ ਹੈ। ਪਰਬੰਧਕ ਦੁਆਰਾ ਅਸਫਲ vdev ਡਿਵਾਈਸ ਨੂੰ ਬਦਲਣ ਤੋਂ ਬਾਅਦ, ਰਿਡੰਡੈਂਸੀ ਨੂੰ ਉਸ ਸਥਾਈ ਡਿਵਾਈਸ ਤੇ ਰੀਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸਪੇਅਰ ਨੂੰ 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.

ਡੇਟਾਸੈਟਾਂ ਤੋਂ ਇਲਾਵਾ, ਸਾਨੂੰ ਵਾਲੀਅਮ (ਜ਼ਵੋਲਜ਼) ਦਾ ਜ਼ਿਕਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਵਾਲੀਅਮ ਮੋਟੇ ਤੌਰ 'ਤੇ ਡੇਟਾ ਸੈੱਟ ਦੇ ਸਮਾਨ ਹੁੰਦਾ ਹੈ, ਸਿਵਾਏ ਇਸਦੇ ਕਿ ਅਸਲ ਵਿੱਚ ਕੋਈ ਫਾਈਲ ਸਿਸਟਮ ਨਹੀਂ ਹੈ - ਇਹ ਸਿਰਫ ਇੱਕ ਬਲਾਕ ਡਿਵਾਈਸ ਹੈ। ਤੁਸੀਂ ਉਦਾਹਰਨ ਲਈ ਬਣਾ ਸਕਦੇ ਹੋ zvol ਨਾਮ ਨਾਲ mypool/myzvol, ਫਿਰ ਇਸਨੂੰ ਇੱਕ ext4 ਫਾਈਲ ਸਿਸਟਮ ਨਾਲ ਫਾਰਮੈਟ ਕਰੋ, ਅਤੇ ਫਿਰ ਉਸ ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਮਾਊਂਟ ਕਰੋ - ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ext4 ਫਾਈਲ ਸਿਸਟਮ ਹੈ, ਪਰ ZFS ਦੀਆਂ ਸਾਰੀਆਂ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ! ਇਹ ਇੱਕ ਕੰਪਿਊਟਰ 'ਤੇ ਮੂਰਖ ਜਾਪਦਾ ਹੈ, ਪਰ ਇੱਕ iSCSI ਜੰਤਰ ਨੂੰ ਨਿਰਯਾਤ ਕਰਨ ਵੇਲੇ ਇੱਕ ਬੈਕਐਂਡ ਦੇ ਤੌਰ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਅਰਥ ਰੱਖਦਾ ਹੈ।

ਬਲਾਕ

ਇੱਕ ਫਾਈਲ ਨੂੰ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਬਲਾਕਾਂ ਦੁਆਰਾ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ। ਹਰੇਕ ਬਲਾਕ ਨੂੰ ਇੱਕ ਵਰਚੁਅਲ ਡਿਵਾਈਸ ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬਲਾਕ ਦਾ ਆਕਾਰ ਆਮ ਤੌਰ 'ਤੇ ਪੈਰਾਮੀਟਰ ਦੇ ਬਰਾਬਰ ਹੁੰਦਾ ਹੈ ਰਿਕਾਰਡ ਦਾ ਆਕਾਰ, ਪਰ ਤੱਕ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ 2^ ਸ਼ਿਫਟ, ਜੇਕਰ ਇਸ ਵਿੱਚ ਮੈਟਾਡੇਟਾ ਜਾਂ ਇੱਕ ਛੋਟੀ ਫ਼ਾਈਲ ਹੈ।

ਅਸੀਂ ਸੱਚਮੁੱਚ ਅਸਲ ਵਿੱਚ ਜੇਕਰ ਤੁਸੀਂ ਸ਼ਿਫਟ ਬਹੁਤ ਘੱਟ ਸੈਟ ਕਰਦੇ ਹੋ ਤਾਂ ਅਸੀਂ ਵੱਡੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਸਜ਼ਾ ਬਾਰੇ ਮਜ਼ਾਕ ਨਹੀਂ ਕਰ ਰਹੇ ਹਾਂ

ਇੱਕ ZFS ਪੂਲ ਵਿੱਚ, ਮੈਟਾਡੇਟਾ ਸਮੇਤ ਸਾਰਾ ਡਾਟਾ ਬਲਾਕਾਂ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਹਰੇਕ ਡੇਟਾ ਸੈੱਟ ਲਈ ਅਧਿਕਤਮ ਬਲਾਕ ਆਕਾਰ ਨੂੰ ਵਿਸ਼ੇਸ਼ਤਾ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ recordsize (ਰਿਕਾਰਡ ਦਾ ਆਕਾਰ). ਰਿਕਾਰਡ ਦਾ ਆਕਾਰ ਬਦਲ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਕਿਸੇ ਵੀ ਬਲਾਕ ਦਾ ਆਕਾਰ ਜਾਂ ਸਥਾਨ ਨਹੀਂ ਬਦਲੇਗਾ ਜੋ ਪਹਿਲਾਂ ਹੀ ਡੇਟਾ ਸੈੱਟ 'ਤੇ ਲਿਖੇ ਗਏ ਹਨ - ਇਹ ਸਿਰਫ ਨਵੇਂ ਬਲਾਕਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਉਹ ਲਿਖੇ ਗਏ ਹਨ।

ਜਦੋਂ ਤੱਕ ਹੋਰ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ, ਮੌਜੂਦਾ ਡਿਫੌਲਟ ਐਂਟਰੀ ਦਾ ਆਕਾਰ 128 KiB ਹੈ। ਇਹ ਇੱਕ ਸਖ਼ਤ ਵਪਾਰ-ਬੰਦ ਹੈ ਜਿੱਥੇ ਪ੍ਰਦਰਸ਼ਨ ਸੰਪੂਰਨ ਨਹੀਂ ਹੋਵੇਗਾ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਹ ਭਿਆਨਕ ਨਹੀਂ ਹੋਵੇਗਾ। Recordsize 4K ਤੋਂ 1M ਤੱਕ ਕਿਸੇ ਵੀ ਮੁੱਲ 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਵਾਧੂ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ recordsize ਤੁਸੀਂ ਹੋਰ ਵੀ ਇੰਸਟਾਲ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਸ਼ਾਇਦ ਹੀ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਹੈ).

ਕੋਈ ਵੀ ਬਲਾਕ ਸਿਰਫ ਇੱਕ ਫਾਈਲ ਦੇ ਡੇਟਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ - ਤੁਸੀਂ ਇੱਕ ਬਲਾਕ ਵਿੱਚ ਦੋ ਵੱਖਰੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਸਕਿਊਜ਼ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ। ਹਰੇਕ ਫਾਈਲ ਦੇ ਆਕਾਰ ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਬਲਾਕ ਹੁੰਦੇ ਹਨ। ਜੇਕਰ ਫਾਈਲ ਦਾ ਆਕਾਰ ਰਿਕਾਰਡ ਦੇ ਆਕਾਰ ਤੋਂ ਛੋਟਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਛੋਟੇ ਬਲਾਕ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇਗਾ — ਉਦਾਹਰਨ ਲਈ, ਇੱਕ 2KiB ਫਾਈਲ ਵਾਲਾ ਇੱਕ ਬਲਾਕ ਡਿਸਕ ਉੱਤੇ ਸਿਰਫ਼ ਇੱਕ 4KiB ਸੈਕਟਰ ਨੂੰ ਰੱਖੇਗਾ।

ਜੇਕਰ ਫਾਈਲ ਇੰਨੀ ਵੱਡੀ ਹੈ ਕਿ ਕਈ ਬਲਾਕਾਂ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਸ ਫਾਈਲ ਦੀਆਂ ਸਾਰੀਆਂ ਐਂਟਰੀਆਂ ਆਕਾਰ ਦੀਆਂ ਹੋਣਗੀਆਂ recordsize - ਆਖਰੀ ਐਂਟਰੀ ਸਮੇਤ, ਜਿਸ ਦਾ ਮੁੱਖ ਹਿੱਸਾ ਹੋ ਸਕਦਾ ਹੈ ਅਣਵਰਤੀ ਜਗ੍ਹਾ.

zvol ਵਾਲੀਅਮ ਦੀ ਜਾਇਦਾਦ ਨਹੀਂ ਹੈ recordsize - ਇਸਦੀ ਬਜਾਏ ਉਹਨਾਂ ਕੋਲ ਬਰਾਬਰ ਦੀ ਜਾਇਦਾਦ ਹੈ volblocksize.

ਸੈਕਟਰ

ਆਖਰੀ, ਸਭ ਤੋਂ ਬੁਨਿਆਦੀ ਬਿਲਡਿੰਗ ਬਲਾਕ ਸੈਕਟਰ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਛੋਟੀ ਭੌਤਿਕ ਇਕਾਈ ਹੈ ਜਿਸ ਨੂੰ ਹੋਸਟ ਡਿਵਾਈਸ ਤੋਂ ਲਿਖਿਆ ਜਾਂ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਕਈ ਦਹਾਕਿਆਂ ਤੋਂ, ਜ਼ਿਆਦਾਤਰ ਡਿਸਕਾਂ 512-ਬਾਈਟ ਸੈਕਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ। ਅੱਜਕੱਲ੍ਹ, ਜ਼ਿਆਦਾਤਰ ਡਰਾਈਵਾਂ 4KiB ਸੈਕਟਰਾਂ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਅਤੇ ਕੁਝ-ਖਾਸ ਕਰਕੇ SSDs-8KiB ਸੈਕਟਰਾਂ ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਵੱਡੇ ਲਈ ਸੰਰਚਿਤ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।

ZFS ਵਿੱਚ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸੈਕਟਰ ਦਾ ਆਕਾਰ ਹੱਥੀਂ ਸੈੱਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ। ਇਹ ਸੰਪਤੀ ashift. ਕੁਝ ਭੰਬਲਭੂਸੇ ਵਿੱਚ, ਸ਼ਿਫਟ ਦੋ ਦੀ ਸ਼ਕਤੀ ਹੈ। ਉਦਾਹਰਣ ਲਈ, ashift=9 ਮਤਲਬ ਸੈਕਟਰ ਦਾ ਆਕਾਰ 2^9, ਜਾਂ 512 ਬਾਈਟ।

ZFS ਹਰੇਕ ਬਲਾਕ ਡਿਵਾਈਸ ਬਾਰੇ ਵਿਸਤ੍ਰਿਤ ਜਾਣਕਾਰੀ ਲਈ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਤੋਂ ਪੁੱਛਗਿੱਛ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਸਨੂੰ ਇੱਕ ਨਵੇਂ vdev ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ, ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਇਸ ਜਾਣਕਾਰੀ ਦੇ ਅਧਾਰ ਤੇ ਆਪਣੇ ਆਪ ਹੀ ਢੁਕਵੇਂ ਢੰਗ ਨਾਲ ਸ਼ਿਫਟ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਬਹੁਤ ਸਾਰੀਆਂ ਡਰਾਈਵਾਂ ਅਨੁਕੂਲਤਾ ਬਣਾਈ ਰੱਖਣ ਲਈ ਆਪਣੇ ਸੈਕਟਰ ਆਕਾਰ ਬਾਰੇ ਝੂਠ ਬੋਲਦੀਆਂ ਹਨ। Windows XP (ਜੋ ਕਿ ਵੱਖ-ਵੱਖ ਸੈਕਟਰ ਆਕਾਰਾਂ ਵਾਲੀਆਂ ਡਰਾਈਵਾਂ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਅਸਮਰੱਥ ਸੀ)।

ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ZFS ਪ੍ਰਸ਼ਾਸਕ ਆਪਣੇ ਡਿਵਾਈਸਾਂ ਦੇ ਅਸਲ ਸੈਕਟਰ ਆਕਾਰ ਨੂੰ ਜਾਣਦਾ ਹੈ ਅਤੇ ਹੱਥੀਂ ਸੈੱਟ ਕਰਦਾ ਹੈ ashift. ਜੇਕਰ ਸ਼ਿਫਟ ਬਹੁਤ ਛੋਟਾ ਸੈੱਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਰੀਡ/ਰਾਈਟ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ ਖਗੋਲ-ਵਿਗਿਆਨਕ ਤੌਰ 'ਤੇ ਵਧ ਜਾਂਦੀ ਹੈ। ਇਸ ਲਈ, ਇੱਕ ਅਸਲੀ 512KiB ਸੈਕਟਰ ਵਿੱਚ 4-ਬਾਈਟ "ਸੈਕਟਰ" ਲਿਖਣ ਦਾ ਮਤਲਬ ਹੈ ਪਹਿਲਾ "ਸੈਕਟਰ" ਲਿਖਣਾ, ਫਿਰ 4KiB ਸੈਕਟਰ ਨੂੰ ਪੜ੍ਹਨਾ, ਇਸਨੂੰ ਦੂਜੇ 512-ਬਾਈਟ "ਸੈਕਟਰ" ਨਾਲ ਸੋਧਣਾ, ਇਸਨੂੰ ਨਵੇਂ 4KiB ਸੈਕਟਰ ਵਿੱਚ ਵਾਪਸ ਲਿਖੋ। , ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹਰ ਇੱਕ ਐਂਟਰੀ ਲਈ।

ਅਸਲ ਸੰਸਾਰ ਵਿੱਚ, ਅਜਿਹਾ ਜੁਰਮਾਨਾ Samsung EVO SSDs ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ, ਜਿਸ ਲਈ ਇਸਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ 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, ਜਾਂ ਸੈਕੰਡਰੀ LOG ਯੰਤਰ, ਸਿਰਫ਼ ਇੱਕ ਵਿਸ਼ੇਸ਼ - ਅਤੇ ਤਰਜੀਹੀ ਤੌਰ 'ਤੇ ਬਹੁਤ ਤੇਜ਼ - vdev ਹੈ ਜਿੱਥੇ ZIL ਨੂੰ ਮੁੱਖ ਸਟੋਰੇਜ ਤੋਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇੱਕ ਕਰੈਸ਼ ਤੋਂ ਬਾਅਦ, ZIL ਵਿੱਚ ਸਾਰਾ ਗੰਦਾ ਡੇਟਾ ਦੁਬਾਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ - ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ZIL SLOG 'ਤੇ ਹੈ, ਇਸਲਈ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਇਸਨੂੰ ਦੁਬਾਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ

ਰਾਈਟਸ ਦੀਆਂ ਦੋ ਮੁੱਖ ਸ਼੍ਰੇਣੀਆਂ ਹਨ - ਸਮਕਾਲੀ (ਸਿੰਕਰੋਨਸ) ਅਤੇ ਅਸਿੰਕ੍ਰੋਨਸ (ਅਸਿੰਕ)। ਜ਼ਿਆਦਾਤਰ ਵਰਕਲੋਡਾਂ ਲਈ, ਜ਼ਿਆਦਾਤਰ ਲਿਖਤਾਂ ਅਸਿੰਕ੍ਰੋਨਸ ਹੁੰਦੀਆਂ ਹਨ - ਫਾਈਲ ਸਿਸਟਮ ਉਹਨਾਂ ਨੂੰ ਇਕੱਠੇ ਕੀਤੇ ਜਾਣ ਅਤੇ ਬੈਚਾਂ ਵਿੱਚ ਜਾਰੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਥ੍ਰੁਪੁੱਟ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਵਧਾਉਂਦਾ ਹੈ।

ਸਮਕਾਲੀ ਰਿਕਾਰਡਿੰਗ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਮਾਮਲਾ ਹੈ। ਜਦੋਂ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਸਮਕਾਲੀ ਲਿਖਤ ਦੀ ਬੇਨਤੀ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਹ ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਦੱਸਦੀ ਹੈ: "ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਗੈਰ-ਅਸਥਿਰ ਮੈਮੋਰੀ ਵਿੱਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਹੁਣ ਸੱਜੇ, ਅਤੇ ਉਦੋਂ ਤੱਕ ਮੈਂ ਹੋਰ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇਸਲਈ, ਸਮਕਾਲੀ ਰਾਈਟਸ ਨੂੰ ਤੁਰੰਤ ਡਿਸਕ ਲਈ ਵਚਨਬੱਧ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ-ਅਤੇ ਜੇਕਰ ਇਹ ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ ਜਾਂ ਥ੍ਰੁਪੁੱਟ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਹੋਵੇ।

ZFS ਸਮਕਾਲੀ ਲਿਖਤਾਂ ਨੂੰ ਨਿਯਮਤ ਫਾਈਲ ਸਿਸਟਮਾਂ ਨਾਲੋਂ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕਰਦਾ ਹੈ - ਉਹਨਾਂ ਨੂੰ ਤੁਰੰਤ ਨਿਯਮਤ ਸਟੋਰੇਜ ਵਿੱਚ ਫਲੱਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ, ZFS ਉਹਨਾਂ ਨੂੰ ZFS ਇੰਟੈਂਟ ਲੌਗ, ਜਾਂ ZIL ਨਾਮਕ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਸਟੋਰੇਜ਼ ਖੇਤਰ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਚਾਲ ਇਹ ਹੈ ਕਿ ਇਹ ਰਿਕਾਰਡ ਵੀ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹੋ, ਆਮ ਅਸਿੰਕ੍ਰੋਨਸ ਰਾਈਟ ਬੇਨਤੀਆਂ ਦੇ ਨਾਲ ਇਕੱਠਾ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਬਾਅਦ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਮ TXGs (ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਗਰੁੱਪ) ਦੇ ਰੂਪ ਵਿੱਚ ਸਟੋਰੇਜ ਵਿੱਚ ਫਲੱਸ਼ ਕੀਤਾ ਜਾਵੇਗਾ।

ਆਮ ਕਾਰਵਾਈ ਦੌਰਾਨ, ZIL ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਕਦੇ ਨਹੀਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ, ਕੁਝ ਪਲਾਂ ਬਾਅਦ, ZIL ਤੋਂ ਰਿਕਾਰਡ ਰੈਮ ਤੋਂ ਨਿਯਮਤ TXGs ਵਿੱਚ ਮੁੱਖ ਸਟੋਰੇਜ ਲਈ ਵਚਨਬੱਧ ਹੁੰਦੇ ਹਨ, ਉਹ ZIL ਤੋਂ ਵੱਖ ਹੋ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਪੂਲ ਨੂੰ ਆਯਾਤ ਕਰਨ ਵੇਲੇ ZIL ਤੋਂ ਕੁਝ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ।

ਜੇ ਇੱਕ ZFS ਕਰੈਸ਼ ਹੁੰਦਾ ਹੈ — ਇੱਕ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕਰੈਸ਼ ਜਾਂ ਪਾਵਰ ਆਊਟੇਜ — ਜਦੋਂ ਕਿ ZIL ਵਿੱਚ ਡੇਟਾ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਹ ਡੇਟਾ ਅਗਲੇ ਪੂਲ ਆਯਾਤ ਦੌਰਾਨ ਪੜ੍ਹਿਆ ਜਾਵੇਗਾ (ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਕਰੈਸ਼ ਸਿਸਟਮ ਮੁੜ ਚਾਲੂ ਹੁੰਦਾ ਹੈ)। ਜੋ ਵੀ ZIL ਵਿੱਚ ਹੈ ਉਸਨੂੰ ਪੜ੍ਹਿਆ ਜਾਵੇਗਾ, TXGs ਵਿੱਚ ਸਮੂਹ ਕੀਤਾ ਜਾਵੇਗਾ, ਮੁੱਖ ਸਟੋਰ ਲਈ ਵਚਨਬੱਧ ਕੀਤਾ ਜਾਵੇਗਾ, ਅਤੇ ਫਿਰ ਆਯਾਤ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ZIL ਤੋਂ ਵੱਖ ਕੀਤਾ ਜਾਵੇਗਾ।

vdev ਸਹਾਇਕ ਕਲਾਸਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ LOG ਜਾਂ SLOG ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਸੈਕੰਡਰੀ LOG ਯੰਤਰ। ਇਸਦਾ ਇੱਕ ਉਦੇਸ਼ ਹੈ - 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% ਤੇਜ਼ ਸੀ।

ਉਸੇ ਨੈੱਟਵਰਕ 'ਤੇ, ਇੱਕ ਸਿੰਗਲ 40-ਗੀਗਾਬਾਈਟ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਇਮੇਜ ਫਾਈਲ ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ Windows 7 ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰੀ ਕਹਾਣੀ ਹੈ। ZFS ਪ੍ਰਤੀਕ੍ਰਿਤੀ rsync ਨਾਲੋਂ 289 ਗੁਣਾ ਤੇਜ਼ ਹੈ—ਜਾਂ "ਸਿਰਫ਼" 161 ਗੁਣਾ ਤੇਜ਼ ਹੈ ਜੇਕਰ ਤੁਸੀਂ --inplace ਸਵਿੱਚ ਨਾਲ rsync ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਸਮਝਦਾਰ ਹੋ।

ਜਦੋਂ ਇੱਕ VM ਚਿੱਤਰ ਸਕੇਲ ਕਰਦਾ ਹੈ, ਤਾਂ rsync ਇਸ ਨਾਲ ਸਕੇਲ ਜਾਰੀ ਕਰਦਾ ਹੈ। ਆਧੁਨਿਕ VM ਚਿੱਤਰ ਲਈ 1,9 TiB ਆਕਾਰ ਇੰਨਾ ਵੱਡਾ ਨਹੀਂ ਹੈ - ਪਰ ਇਹ ਇੰਨਾ ਵੱਡਾ ਹੈ ਕਿ ZFS ਪ੍ਰਤੀਕ੍ਰਿਤੀ rsync ਨਾਲੋਂ 1148 ਗੁਣਾ ਤੇਜ਼ ਹੈ, ਭਾਵੇਂ ਕਿ rsync --inplace ਆਰਗੂਮੈਂਟ ਦੇ ਨਾਲ

ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਸਮਝ ਲੈਂਦੇ ਹੋ ਕਿ ਸਨੈਪਸ਼ਾਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਤਾਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਤੱਤ ਨੂੰ ਸਮਝਣਾ ਆਸਾਨ ਹੋ ਜਾਵੇਗਾ। ਕਿਉਂਕਿ ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਸਿਰਫ਼ ਰਿਕਾਰਡ ਪੁਆਇੰਟਰਾਂ ਦਾ ਇੱਕ ਰੁੱਖ ਹੈ, ਇਹ ਇਸ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਜੇਕਰ ਅਸੀਂ ਕਰਦੇ ਹਾਂ 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, ਅਤੇ ਫਿਰ ਇਹਨਾਂ ਬਲਾਕਾਂ ਵਿੱਚ ਪੁਆਇੰਟਰ ਜੋੜੋ। ਵੋਇਲਾ, ਸਾਡੇ ਕੋਲ ਹੈ @2 ਨਵੇਂ ਸਿਸਟਮ ਵਿੱਚ!

ZFS ਅਸਿੰਕ੍ਰੋਨਸ ਇਨਕਰੀਮੈਂਟਲ ਰੀਪਲੀਕੇਸ਼ਨ ਪੁਰਾਣੇ ਗੈਰ-ਸਨੈਪਸ਼ਾਟ-ਅਧਾਰਿਤ ਤਰੀਕਿਆਂ ਜਿਵੇਂ ਕਿ rsync ਨਾਲੋਂ ਬਹੁਤ ਵੱਡਾ ਸੁਧਾਰ ਹੈ। ਦੋਵਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਸਿਰਫ ਬਦਲਿਆ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਪਰ ਪਹਿਲਾਂ rsync ਲਾਜ਼ਮੀ ਹੈ ਪੜੋ ਜੋੜ ਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਇਸਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ ਡਿਸਕ ਤੋਂ ਦੋਵਾਂ ਪਾਸਿਆਂ ਦੇ ਸਾਰੇ ਡੇਟਾ. ਇਸਦੇ ਉਲਟ, ZFS ਰੀਪਲੀਕੇਸ਼ਨ ਪੁਆਇੰਟਰ ਟ੍ਰੀਸ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕੁਝ ਨਹੀਂ ਪੜ੍ਹਦੀ ਹੈ — ਅਤੇ ਕੋਈ ਵੀ ਬਲਾਕ ਜੋ ਸਮੁੱਚੇ ਸਨੈਪਸ਼ਾਟ ਵਿੱਚ ਨਹੀਂ ਦਰਸਾਏ ਗਏ ਹਨ।

ਬਿਲਟ-ਇਨ ਕੰਪਰੈਸ਼ਨ

ਕਾਪੀ-ਆਨ-ਰਾਈਟ ਵਿਧੀ ਬਿਲਟ-ਇਨ ਕੰਪਰੈਸ਼ਨ ਸਿਸਟਮ ਨੂੰ ਵੀ ਸਰਲ ਬਣਾਉਂਦੀ ਹੈ। ਇੱਕ ਪਰੰਪਰਾਗਤ ਫਾਈਲ ਸਿਸਟਮ ਵਿੱਚ, ਕੰਪਰੈਸ਼ਨ ਸਮੱਸਿਆ ਵਾਲਾ ਹੁੰਦਾ ਹੈ - ਦੋਵੇਂ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਅਤੇ ਬਦਲੇ ਗਏ ਡੇਟਾ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ ਇੱਕੋ ਥਾਂ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ।

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਫਾਈਲ ਦੇ ਮੱਧ ਵਿੱਚ ਡੇਟਾ ਦੇ ਇੱਕ ਟੁਕੜੇ 'ਤੇ ਵਿਚਾਰ ਕਰਦੇ ਹੋ ਜੋ 0x00000000 ਤੋਂ ਜ਼ੀਰੋ ਦੇ ਇੱਕ ਮੈਗਾਬਾਈਟ ਦੇ ਰੂਪ ਵਿੱਚ ਆਪਣੀ ਜ਼ਿੰਦਗੀ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ, ਤਾਂ ਇਸਨੂੰ ਡਿਸਕ 'ਤੇ ਇੱਕ ਸਿੰਗਲ ਸੈਕਟਰ ਵਿੱਚ ਸੰਕੁਚਿਤ ਕਰਨਾ ਬਹੁਤ ਆਸਾਨ ਹੈ। ਪਰ ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਅਸੀਂ ਜ਼ੀਰੋ ਦੇ ਇਸ ਮੈਗਾਬਾਈਟ ਨੂੰ ਅਸੰਕੁਚਿਤ ਡੇਟਾ ਦੇ ਇੱਕ ਮੈਗਾਬਾਈਟ ਨਾਲ ਬਦਲਦੇ ਹਾਂ, ਜਿਵੇਂ ਕਿ ਜੇਪੀਈਜੀ ਜਾਂ ਸੂਡੋ-ਰੈਂਡਮ ਸ਼ੋਰ? ਅਚਾਨਕ, ਉਸ ਮੈਗਾਬਾਈਟ ਡੇਟਾ ਲਈ ਇੱਕ ਨਹੀਂ, ਸਗੋਂ 256 4KiB ਸੈਕਟਰਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਅਤੇ ਉਸ ਡਿਸਕ ਸਪੇਸ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਸੈਕਟਰ ਰਾਖਵਾਂ ਸੀ।

ZFS ਨੂੰ ਇਹ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਸੋਧੀਆਂ ਲਿਖਤਾਂ ਹਮੇਸ਼ਾ ਅਣਵਰਤੀ ਥਾਂ 'ਤੇ ਲਿਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ - ਅਸਲ ਬਲਾਕ ਸਿਰਫ ਇੱਕ 4 KiB ਸੈਕਟਰ ਲੈਂਦਾ ਹੈ, ਪਰ ਇੱਕ ਨਵੀਂ ਲਿਖਤ 256 ਲੈਂਦੀ ਹੈ, ਪਰ ਇਹ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ - ਇੱਕ ਹਾਲ ਹੀ ਵਿੱਚ ਸੋਧਿਆ ਹੋਇਆ ਹਿੱਸਾ " ਫਾਈਲ ਦੇ ਮੱਧ" ਨੂੰ ਅਣਵਰਤੀ ਸਪੇਸ ਵਿੱਚ ਲਿਖਿਆ ਜਾਵੇਗਾ ਭਾਵੇਂ ਇਸਦਾ ਆਕਾਰ ਬਦਲਿਆ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਸ ਲਈ ਇਹ ZFS ਲਈ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਮ ਸਥਿਤੀ ਹੈ।

ZFS ਦਾ ਬਿਲਟ-ਇਨ ਕੰਪਰੈਸ਼ਨ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਅਸਮਰੱਥ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਪਲੱਗੇਬਲ ਐਲਗੋਰਿਦਮ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ - ਵਰਤਮਾਨ ਵਿੱਚ LZ4, gzip (1-9), LZJB, ਅਤੇ ZLE ਸਮੇਤ।

• LZ4 ਇੱਕ ਸਟ੍ਰੀਮਿੰਗ ਐਲਗੋਰਿਦਮ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਲਈ ਬਹੁਤ ਤੇਜ਼ ਕੰਪਰੈਸ਼ਨ ਅਤੇ ਡੀਕੰਪ੍ਰੇਸ਼ਨ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਲਾਭ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ — ਇੱਥੋਂ ਤੱਕ ਕਿ ਕਾਫ਼ੀ ਹੌਲੀ CPUs 'ਤੇ ਵੀ।
• GZIP ਇੱਕ ਸਤਿਕਾਰਯੋਗ ਐਲਗੋਰਿਦਮ ਹੈ ਜਿਸਨੂੰ ਸਾਰੇ ਯੂਨਿਕਸ ਉਪਭੋਗਤਾ ਜਾਣਦੇ ਹਨ ਅਤੇ ਪਿਆਰ ਕਰਦੇ ਹਨ। ਇਹ ਕੰਪਰੈਸ਼ਨ ਪੱਧਰ 1-9 ਦੇ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਵਧਦੇ ਕੰਪਰੈਸ਼ਨ ਅਨੁਪਾਤ ਅਤੇ CPU ਵਰਤੋਂ ਦੇ ਨਾਲ ਜਦੋਂ ਤੁਸੀਂ ਪੱਧਰ 9 ਤੱਕ ਪਹੁੰਚਦੇ ਹੋ। ਐਲਗੋਰਿਦਮ ਸਾਰੇ ਟੈਕਸਟ (ਜਾਂ ਹੋਰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੰਕੁਚਿਤ) ਵਰਤੋਂ ਦੇ ਕੇਸਾਂ ਲਈ ਅਨੁਕੂਲ ਹੈ, ਪਰ ਅਕਸਰ CPU ਸਮੱਸਿਆਵਾਂ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ, ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ। ਸਾਵਧਾਨੀ ਨਾਲ, ਖਾਸ ਕਰਕੇ ਉੱਚ ਪੱਧਰਾਂ 'ਤੇ।
• LZJB - ZFS ਵਿੱਚ ਅਸਲੀ ਐਲਗੋਰਿਦਮ. ਇਹ ਪੁਰਾਣਾ ਹੈ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ, LZ4 ਹਰ ਤਰ੍ਹਾਂ ਨਾਲ ਉੱਤਮ ਹੈ।
• ZLE - ਜ਼ੀਰੋ ਲੈਵਲ ਏਨਕੋਡਿੰਗ, ਜ਼ੀਰੋ ਲੈਵਲ ਏਨਕੋਡਿੰਗ। ਇਹ ਆਮ ਡੇਟਾ ਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਛੂਹਦਾ, ਪਰ ਇਹ ਜ਼ੀਰੋ ਦੇ ਵੱਡੇ ਕ੍ਰਮ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਦਾ ਹੈ। ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੰਕੁਚਿਤ ਡੇਟਾ ਸੈੱਟਾਂ (ਜਿਵੇਂ ਕਿ JPEG, MP4 ਜਾਂ ਹੋਰ ਪਹਿਲਾਂ ਤੋਂ ਸੰਕੁਚਿਤ ਫਾਰਮੈਟ) ਲਈ ਉਪਯੋਗੀ ਕਿਉਂਕਿ ਇਹ ਅਸੰਕੁਚਿਤ ਡੇਟਾ ਨੂੰ ਅਣਡਿੱਠ ਕਰਦਾ ਹੈ ਪਰ ਨਤੀਜੇ ਵਜੋਂ ਰਿਕਾਰਡਾਂ ਵਿੱਚ ਅਣਵਰਤੀ ਥਾਂ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਦਾ ਹੈ।

ਅਸੀਂ ਲਗਭਗ ਸਾਰੇ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਲਈ LZ4 ਕੰਪਰੈਸ਼ਨ ਦੀ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ; ਸੰਕੁਚਿਤ ਡੇਟਾ ਨਾਲ ਨਜਿੱਠਣ ਵੇਲੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਸਜ਼ਾ ਬਹੁਤ ਘੱਟ ਹੈ, ਅਤੇ ਵਾਧਾ ਆਮ ਡੇਟਾ ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਭਾਵ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇੱਕ ਨਵੇਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਇੰਸਟਾਲੇਸ਼ਨ ਲਈ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਚਿੱਤਰ ਦੀ ਨਕਲ ਕਰਨਾ Windows (ਤਾਜ਼ਾ ਇੰਸਟਾਲ ਕੀਤਾ OS, ਅਜੇ ਤੱਕ ਕੋਈ ਡਾਟਾ ਨਹੀਂ ਹੈ) compression=lz4 ਦੇ ਮੁਕਾਬਲੇ 27% ਤੇਜ਼ੀ ਨਾਲ ਪਾਸ ਹੋਇਆ compression=none, ਵਿਚ ਇਹ ਟੈਸਟ 2015 ਤੋਂ.

ARC - ਅਡੈਪਟਿਵ ਰਿਪਲੇਸਮੈਂਟ ਕੈਸ਼

ZFS ਇਕਲੌਤਾ ਆਧੁਨਿਕ ਫਾਈਲ ਸਿਸਟਮ ਹੈ ਜਿਸ ਬਾਰੇ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਰੈਮ ਵਿੱਚ ਹਾਲ ਹੀ ਵਿੱਚ ਪੜ੍ਹੇ ਗਏ ਬਲਾਕਾਂ ਦੀਆਂ ਕਾਪੀਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਪੇਜ ਕੈਸ਼ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ, ਆਪਣੀ ਖੁਦ ਦੀ ਰੀਡ ਕੈਚਿੰਗ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਹਾਲਾਂਕਿ ਮੂਲ ਕੈਸ਼ ਇਸ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਹੈ - ZFS ਨਵੀਂ ਮੈਮੋਰੀ ਵੰਡ ਬੇਨਤੀਆਂ ਨੂੰ ਕਰਨਲ ਵਾਂਗ ਜਲਦੀ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ ਹੈ, ਇਸਲਈ ਇੱਕ ਨਵੀਂ ਕਾਲ malloc() ਮੈਮੋਰੀ ਵੰਡ ਫੇਲ੍ਹ ਹੋ ਸਕਦੀ ਹੈ ਜੇਕਰ ਇਸ ਨੂੰ RAM ਦੀ ਲੋੜ ਹੈ ਜੋ ਵਰਤਮਾਨ ਵਿੱਚ ARC ਦੁਆਰਾ ਕਬਜ਼ੇ ਵਿੱਚ ਹੈ। ਪਰ ਤੁਹਾਡੇ ਆਪਣੇ ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਚੰਗੇ ਕਾਰਨ ਹਨ, ਘੱਟੋ ਘੱਟ ਹੁਣ ਲਈ।

ਸਾਰੇ ਜਾਣੇ-ਪਛਾਣੇ ਆਧੁਨਿਕ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ, ਮੈਕਓਐਸ ਸਮੇਤ, Windows, Linux ਅਤੇ BSD ਪੰਨਾ ਕੈਸ਼ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ LRU (ਘੱਟ ਤੋਂ ਘੱਟ ਹਾਲ ਹੀ ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ) ਐਲਗੋਰਿਦਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਇਹ ਇੱਕ ਮੁੱਢਲਾ ਐਲਗੋਰਿਦਮ ਹੈ ਜੋ ਹਰੇਕ ਪੜ੍ਹਨ ਤੋਂ ਬਾਅਦ ਇੱਕ ਕੈਸ਼ ਕੀਤੇ ਬਲਾਕ ਨੂੰ "ਕਤਾਰ ਦੇ ਸਿਖਰ 'ਤੇ" ਲੈ ਜਾਂਦਾ ਹੈ ਅਤੇ ਨਵੇਂ ਕੈਸ਼ ਮਿਸ (ਬਲਾਕ ਜੋ ਕੈਸ਼ ਤੋਂ ਨਹੀਂ ਬਲਕਿ ਡਿਸਕ ਤੋਂ ਪੜ੍ਹੇ ਜਾਣੇ ਚਾਹੀਦੇ ਸਨ) ਨੂੰ ਸਿਖਰ 'ਤੇ ਜੋੜਨ ਲਈ ਲੋੜ ਅਨੁਸਾਰ "ਕਤਾਰ ਦੇ ਹੇਠਾਂ" ਬਲਾਕਾਂ ਨੂੰ ਬਾਹਰ ਕੱਢਦਾ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ ਐਲਗੋਰਿਦਮ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਵੱਡੇ ਕਾਰਜਸ਼ੀਲ ਡੇਟਾ ਸੈੱਟਾਂ ਵਾਲੇ ਸਿਸਟਮਾਂ 'ਤੇ, LRU ਆਸਾਨੀ ਨਾਲ ਥ੍ਰੈਸ਼ਿੰਗ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ - ਉਹਨਾਂ ਬਲਾਕਾਂ ਲਈ ਜਗ੍ਹਾ ਬਣਾਉਣ ਲਈ ਅਕਸਰ ਲੋੜੀਂਦੇ ਬਲਾਕਾਂ ਨੂੰ ਕੱਢਣਾ ਜੋ ਕੈਸ਼ ਤੋਂ ਦੁਬਾਰਾ ਕਦੇ ਨਹੀਂ ਪੜ੍ਹਿਆ ਜਾਵੇਗਾ।

ਏਆਰਸੀ ਇੱਕ ਬਹੁਤ ਘੱਟ ਭੋਲਾ ਐਲਗੋਰਿਦਮ ਹੈ ਜਿਸਨੂੰ "ਵਜ਼ਨ" ਕੈਸ਼ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਹਰ ਵਾਰ ਜਦੋਂ ਇੱਕ ਕੈਸ਼ਡ ਬਲਾਕ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ, ਇਹ ਥੋੜਾ "ਭਾਰੀ" ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬਾਹਰ ਕੱਢਣਾ ਔਖਾ ਹੋ ਜਾਂਦਾ ਹੈ - ਅਤੇ ਬਲਾਕ ਨੂੰ ਬੇਦਖਲ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵੀ ਟਰੈਕ ਕੀਤਾ ਸਮੇਂ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਮਿਆਦ ਵਿੱਚ. ਇੱਕ ਬਲਾਕ ਜਿਸਨੂੰ ਬੇਦਖਲ ਕਰ ਦਿੱਤਾ ਗਿਆ ਹੈ ਪਰ ਫਿਰ ਕੈਸ਼ ਵਿੱਚ ਵਾਪਸ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਹੈ ਉਹ ਵੀ ਭਾਰੀ ਹੋ ਜਾਵੇਗਾ।

ਇਸ ਸਭ ਦਾ ਅੰਤਮ ਨਤੀਜਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਿੱਟ ਅਨੁਪਾਤ ਵਾਲਾ ਕੈਸ਼ ਹੈ-ਕੈਸ਼ ਹਿੱਟ (ਕੈਸ਼ ਤੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ) ਅਤੇ ਮਿਸ (ਡਿਸਕ ਤੋਂ ਪੜ੍ਹਦਾ ਹੈ) ਵਿਚਕਾਰ ਅਨੁਪਾਤ। ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਮਹੱਤਵਪੂਰਨ ਅੰਕੜਾ ਹੈ - ਨਾ ਸਿਰਫ ਕੈਸ਼ ਹਿੱਟ ਆਪਣੇ ਆਪ ਵਿੱਚ ਤੀਬਰਤਾ ਦੇ ਆਦੇਸ਼ਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸੇਵਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਕੈਸ਼ ਮਿਸ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਸੇਵਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਕੈਸ਼ ਹਿੱਟ ਹੁੰਦੇ ਹਨ, ਡਿਸਕ ਲਈ ਘੱਟ ਸਮਕਾਲੀ ਬੇਨਤੀਆਂ ਅਤੇ ਬਾਕੀ ਬਚੀਆਂ ਖੁੰਝੀਆਂ ਲਈ ਲੇਟੈਂਸੀ ਘੱਟ ਹੁੰਦੀ ਹੈ। ਜੋ ਕਿ ਡਿਸਕ ਨਾਲ ਸੇਵਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

ਸਿੱਟਾ

ਹੁਣ ਜਦੋਂ ਅਸੀਂ ZFS ਦੇ ਮੂਲ ਅਰਥ-ਵਿਗਿਆਨ ਨੂੰ ਕਵਰ ਕਰ ਲਿਆ ਹੈ — ਕਾਪੀ-ਆਨ-ਰਾਈਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਨਾਲ ਹੀ ਸਟੋਰੇਜ ਪੂਲ, ਵਰਚੁਅਲ ਡਿਵਾਈਸਾਂ, ਬਲਾਕਾਂ, ਸੈਕਟਰਾਂ, ਅਤੇ ਫਾਈਲਾਂ ਵਿਚਕਾਰ ਸਬੰਧ — ਅਸੀਂ ਅਸਲ-ਸੰਸਾਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਬਾਰੇ ਚਰਚਾ ਕਰਨ ਲਈ ਤਿਆਰ ਹਾਂ। ਅਸਲੀ ਨੰਬਰ.

ਅਗਲੇ ਭਾਗ ਵਿੱਚ, ਅਸੀਂ ਮਿਰਰਡ vdevs ਅਤੇ RAIDz ਵਾਲੇ ਪੂਲਾਂ ਦੇ ਅਸਲ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਇੱਕ ਦੂਜੇ ਦੇ ਮੁਕਾਬਲੇ, ਅਤੇ ਨਾਲ ਹੀ ਰਵਾਇਤੀ ਕਰਨਲ RAID ਟੋਪੋਲੋਜੀ ਦੇ ਮੁਕਾਬਲੇ ਦੇਖਾਂਗੇ। Linuxਜਿਸਦੀ ਅਸੀਂ ਖੋਜ ਕੀਤੀ ਪਹਿਲਾਂ.

ਪਹਿਲਾਂ ਅਸੀਂ ਸਿਰਫ਼ ਮੂਲ ਗੱਲਾਂ ਨੂੰ ਕਵਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ-ZFS ਟੋਪੋਲੋਜੀਜ਼ ਆਪਣੇ ਆਪ-ਪਰ ਬਾਅਦ ਵਿੱਚ ਅਜਿਹੇ ਇੱਕ ਅਸੀਂ ZFS ਦੀ ਵਧੇਰੇ ਉੱਨਤ ਸੰਰਚਨਾ ਅਤੇ ਟਿਊਨਿੰਗ ਬਾਰੇ ਗੱਲ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋਵਾਂਗੇ, ਜਿਸ ਵਿੱਚ ਸਹਾਇਕ ਵੀਦੇਵ ਕਿਸਮਾਂ ਜਿਵੇਂ ਕਿ L2ARC, SLOG ਅਤੇ ਵਿਸ਼ੇਸ਼ ਅਲੋਕੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਸ਼ਾਮਲ ਹੈ।

ਸਰੋਤ: www.habr.com