ਟਿਕਾਊ ਡੇਟਾ ਸਟੋਰੇਜ ਅਤੇ ਲੀਨਕਸ ਫਾਈਲ APIs

ਮੈਂ, ਕਲਾਉਡ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਡੇਟਾ ਸਟੋਰੇਜ ਦੀ ਸਥਿਰਤਾ ਦੀ ਖੋਜ ਕਰਦੇ ਹੋਏ, ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਮੈਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਨੂੰ ਸਮਝਦਾ ਹਾਂ, ਆਪਣੇ ਆਪ ਨੂੰ ਪਰਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ। ਆਈ NVMe ਸਪੈਕ ਨੂੰ ਪੜ੍ਹ ਕੇ ਸ਼ੁਰੂ ਕੀਤਾ ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਡੇਟਾ ਸਥਿਰਤਾ ਬਾਰੇ ਕੀ ਗਰੰਟੀ ਹੈ (ਅਰਥਾਤ, ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਅਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਡੇਟਾ ਉਪਲਬਧ ਹੋਵੇਗਾ) ਸਾਨੂੰ NMVe ਡਿਸਕਾਂ ਦਿੰਦੇ ਹਨ। ਮੈਂ ਹੇਠਾਂ ਦਿੱਤੇ ਮੁੱਖ ਸਿੱਟੇ ਕੱਢੇ ਹਨ: ਤੁਹਾਨੂੰ ਡੇਟਾ ਲਿਖਣ ਦੀ ਕਮਾਂਡ ਦਿੱਤੇ ਜਾਣ ਤੋਂ ਲੈ ਕੇ ਖਰਾਬ ਹੋਏ ਡੇਟਾ ਤੇ ਵਿਚਾਰ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੱਕ ਉਹ ਸਟੋਰੇਜ ਮਾਧਿਅਮ ਵਿੱਚ ਨਹੀਂ ਲਿਖੇ ਜਾਂਦੇ ਹਨ. ਹਾਲਾਂਕਿ, ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿੱਚ, ਸਿਸਟਮ ਕਾਲਾਂ ਨੂੰ ਡਾਟਾ ਲਿਖਣ ਲਈ ਕਾਫ਼ੀ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਇਸ ਲੇਖ ਵਿੱਚ, ਮੈਂ ਲੀਨਕਸ ਫਾਈਲ APIs ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਨਿਰੰਤਰਤਾ ਵਿਧੀ ਦੀ ਪੜਚੋਲ ਕਰਦਾ ਹਾਂ। ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇੱਥੇ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ: ਪ੍ਰੋਗਰਾਮ ਕਮਾਂਡ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ write(), ਅਤੇ ਇਸ ਕਮਾਂਡ ਦੇ ਸੰਚਾਲਨ ਦੇ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਡਾਟਾ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਡਿਸਕ 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇਗਾ। ਪਰ write() ਸਿਰਫ਼ RAM ਵਿੱਚ ਸਥਿਤ ਕਰਨਲ ਕੈਸ਼ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ। ਸਿਸਟਮ ਨੂੰ ਡਿਸਕ ਤੇ ਡਾਟਾ ਲਿਖਣ ਲਈ ਮਜਬੂਰ ਕਰਨ ਲਈ, ਕੁਝ ਵਾਧੂ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

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

ਰਾਈਟ() ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

ਸਿਸਟਮ ਕਾਲ write() ਮਿਆਰ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਆਈਈਈਈ ਪੋਸਿਕਸ ਇੱਕ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਨੂੰ ਡੇਟਾ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਜੋਂ. ਕੰਮ ਦੇ ਸਫਲਤਾਪੂਰਵਕ ਮੁਕੰਮਲ ਹੋਣ ਤੋਂ ਬਾਅਦ write() ਡਾਟਾ ਰੀਡ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਬਿਲਕੁਲ ਉਹੀ ਬਾਈਟਾਂ ਵਾਪਸ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਜੋ ਪਹਿਲਾਂ ਲਿਖੀਆਂ ਗਈਆਂ ਸਨ, ਅਜਿਹਾ ਕਰਦੇ ਹੋਏ ਭਾਵੇਂ ਡੇਟਾ ਨੂੰ ਹੋਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਜਾਂ ਥਰਿੱਡਾਂ ਤੋਂ ਐਕਸੈਸ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੋਵੇ (ਦੇਖ! POSIX ਸਟੈਂਡਰਡ ਦੇ ਅਨੁਸਾਰੀ ਭਾਗ)। ਇਹ ਇਸ ਲਈ ਹੈ, ਸਧਾਰਣ ਫਾਈਲ ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਨਾਲ ਥ੍ਰੈਡਾਂ ਦੇ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਦੇ ਭਾਗ ਵਿੱਚ, ਇੱਕ ਨੋਟ ਹੈ ਜੋ ਕਹਿੰਦਾ ਹੈ ਕਿ ਜੇਕਰ ਦੋ ਥ੍ਰੈਡ ਹਰ ਇੱਕ ਇਹਨਾਂ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ, ਤਾਂ ਹਰੇਕ ਕਾਲ ਨੂੰ ਜਾਂ ਤਾਂ ਉਹ ਸਾਰੇ ਸੰਕੇਤ ਨਤੀਜੇ ਦੇਖਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਦੂਜੀ ਕਾਲ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ, ਜਾਂ ਕੋਈ ਵੀ ਨਤੀਜਾ ਨਹੀਂ ਦੇਖਦਾ। ਇਹ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚਦਾ ਹੈ ਕਿ ਸਾਰੀਆਂ ਫਾਈਲਾਂ I/O ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਕੰਮ ਕੀਤੇ ਜਾ ਰਹੇ ਸਰੋਤ 'ਤੇ ਲਾਕ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।

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

fsync() ਅਤੇ fdatasync() ਫੰਕਸ਼ਨ

ਡਾਟਾ ਨੂੰ ਡਿਸਕ 'ਤੇ ਫਲੱਸ਼ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਨਾ ਹੈ fsync(). ਇਹ ਫੰਕਸ਼ਨ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਸਾਰੇ ਸੋਧੇ ਹੋਏ ਬਲਾਕਾਂ ਨੂੰ ਕੈਸ਼ ਤੋਂ ਡਿਸਕ 'ਤੇ ਭੇਜਣ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਫਾਈਲ ਦਾ ਸਾਰਾ ਮੈਟਾਡੇਟਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ (ਪਹੁੰਚ ਸਮਾਂ, ਫਾਈਲ ਸੋਧ ਸਮਾਂ, ਅਤੇ ਹੋਰ)। ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਇਸ ਮੈਟਾਡੇਟਾ ਦੀ ਬਹੁਤ ਘੱਟ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਜੇਕਰ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਇਹ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ fdatasync(). The ਮਦਦ ਕਰੋ 'ਤੇ fdatasync() ਇਹ ਕਹਿੰਦਾ ਹੈ ਕਿ ਇਸ ਫੰਕਸ਼ਨ ਦੇ ਸੰਚਾਲਨ ਦੌਰਾਨ, ਇੰਨੀ ਮਾਤਰਾ ਵਿੱਚ ਮੈਟਾਡੇਟਾ ਡਿਸਕ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ "ਹੇਠ ਦਿੱਤੇ ਡੇਟਾ ਰੀਡਿੰਗ ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਸਹੀ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।" ਅਤੇ ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜਿਸਦੀ ਜ਼ਿਆਦਾਤਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਪਰਵਾਹ ਹੁੰਦੀ ਹੈ।

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

ਇਸ ਵਿਧੀ ਨੂੰ ਵੱਖ-ਵੱਖ ਫਾਈਲ ਸਿਸਟਮਾਂ ਵਿੱਚ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਮੈਂ ਵਰਤਿਆ blktrace ext4 ਅਤੇ XFS ਫਾਈਲ ਸਿਸਟਮਾਂ ਵਿੱਚ ਡਿਸਕ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਬਾਰੇ ਜਾਣਨ ਲਈ। ਦੋਵੇਂ ਫਾਈਲਾਂ ਦੀਆਂ ਸਮੱਗਰੀਆਂ ਅਤੇ ਫਾਈਲ ਸਿਸਟਮ ਜਰਨਲ ਦੋਵਾਂ ਲਈ ਡਿਸਕ 'ਤੇ ਆਮ ਲਿਖਣ ਦੀਆਂ ਕਮਾਂਡਾਂ ਜਾਰੀ ਕਰਦੇ ਹਨ, ਕੈਸ਼ ਨੂੰ ਫਲੱਸ਼ ਕਰਦੇ ਹਨ ਅਤੇ FUA (ਫੋਰਸ ਯੂਨਿਟ ਐਕਸੈਸ, ਡਿਸਕ 'ਤੇ ਸਿੱਧਾ ਡਾਟਾ ਲਿਖਣਾ, ਕੈਸ਼ ਨੂੰ ਬਾਈਪਾਸ ਕਰਕੇ) ਜਰਨਲ ਨੂੰ ਲਿਖ ਕੇ ਬਾਹਰ ਨਿਕਲਦੇ ਹਨ। ਉਹ ਸ਼ਾਇਦ ਲੈਣ-ਦੇਣ ਦੇ ਤੱਥ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਅਜਿਹਾ ਹੀ ਕਰਦੇ ਹਨ। FUA ਦਾ ਸਮਰਥਨ ਨਾ ਕਰਨ ਵਾਲੀਆਂ ਡਰਾਈਵਾਂ 'ਤੇ, ਇਸ ਨਾਲ ਦੋ ਕੈਸ਼ ਫਲੱਸ਼ ਹੁੰਦੇ ਹਨ। ਮੇਰੇ ਪ੍ਰਯੋਗਾਂ ਨੇ ਦਿਖਾਇਆ ਹੈ ਕਿ fdatasync() ਥੋੜਾ ਤੇਜ਼ fsync(). ਉਪਯੋਗਤਾ blktrace ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ fdatasync() ਆਮ ਤੌਰ 'ਤੇ ਡਿਸਕ 'ਤੇ ਘੱਟ ਡਾਟਾ ਲਿਖਦਾ ਹੈ (ext4 ਵਿੱਚ fsync() 20 KiB ਲਿਖਦਾ ਹੈ, ਅਤੇ fdatasync() - 16 KiB)। ਨਾਲ ਹੀ, ਮੈਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ XFS ext4 ਨਾਲੋਂ ਥੋੜ੍ਹਾ ਤੇਜ਼ ਹੈ। ਅਤੇ ਇੱਥੇ ਮਦਦ ਨਾਲ blktrace ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੇ ਯੋਗ ਸੀ fdatasync() ਡਿਸਕ 'ਤੇ ਘੱਟ ਡਾਟਾ ਫਲੱਸ਼ ਕਰਦਾ ਹੈ (XFS ਵਿੱਚ 4 KiB)।

fsync() ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਅਸਪਸ਼ਟ ਸਥਿਤੀਆਂ

ਮੈਂ ਤਿੰਨ ਅਸਪਸ਼ਟ ਸਥਿਤੀਆਂ ਬਾਰੇ ਸੋਚ ਸਕਦਾ ਹਾਂ fsync()ਜੋ ਮੈਂ ਅਭਿਆਸ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ।

ਅਜਿਹੀ ਪਹਿਲੀ ਘਟਨਾ 2008 ਵਿੱਚ ਵਾਪਰੀ ਸੀ। ਉਸ ਸਮੇਂ, ਫਾਇਰਫਾਕਸ 3 ਇੰਟਰਫੇਸ "ਫ੍ਰੀਜ਼" ਜੇ ਡਿਸਕ 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਲਿਖੀਆਂ ਜਾ ਰਹੀਆਂ ਸਨ। ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਇੰਟਰਫੇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਨੇ ਇਸਦੇ ਰਾਜ ਬਾਰੇ ਜਾਣਕਾਰੀ ਸਟੋਰ ਕਰਨ ਲਈ ਇੱਕ SQLite ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ। ਇੰਟਰਫੇਸ ਵਿੱਚ ਆਈ ਹਰੇਕ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ, ਫੰਕਸ਼ਨ ਨੂੰ ਬੁਲਾਇਆ ਗਿਆ ਸੀ fsync(), ਜਿਸ ਨੇ ਸਥਿਰ ਡਾਟਾ ਸਟੋਰੇਜ ਦੀ ਚੰਗੀ ਗਾਰੰਟੀ ਦਿੱਤੀ ਹੈ। ਉਸ ਸਮੇਂ ਵਰਤੇ ਗਏ ext3 ਫਾਈਲ ਸਿਸਟਮ ਵਿੱਚ, ਫੰਕਸ਼ਨ fsync() ਸਿਸਟਮ ਦੇ ਸਾਰੇ "ਗੰਦੇ" ਪੰਨਿਆਂ ਨੂੰ ਡਿਸਕ 'ਤੇ ਫਲੱਸ਼ ਕੀਤਾ ਗਿਆ, ਨਾ ਕਿ ਸਿਰਫ਼ ਉਹੀ ਜੋ ਸੰਬੰਧਿਤ ਫਾਈਲ ਨਾਲ ਸਬੰਧਤ ਸਨ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਫਾਇਰਫਾਕਸ ਵਿੱਚ ਇੱਕ ਬਟਨ ਨੂੰ ਦਬਾਉਣ ਨਾਲ ਮੈਗਾਬਾਈਟ ਡੇਟਾ ਇੱਕ ਚੁੰਬਕੀ ਡਿਸਕ ਵਿੱਚ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਕਈ ਸਕਿੰਟ ਲੱਗ ਸਕਦੇ ਹਨ। ਸਮੱਸਿਆ ਦਾ ਹੱਲ, ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਸਮਝਿਆ ਇਸ ਨੂੰ ਸਮੱਗਰੀ, ਡੇਟਾਬੇਸ ਦੇ ਨਾਲ ਕੰਮ ਨੂੰ ਅਸਿੰਕਰੋਨਸ ਬੈਕਗ੍ਰਾਉਂਡ ਕਾਰਜਾਂ ਵਿੱਚ ਲਿਜਾਣਾ ਸੀ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਫਾਇਰਫਾਕਸ ਅਸਲ ਵਿੱਚ ਲੋੜ ਨਾਲੋਂ ਵਧੇਰੇ ਸਖ਼ਤ ਸਟੋਰੇਜ਼ ਸਥਿਰਤਾ ਲੋੜਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ext3 ਫਾਈਲ ਸਿਸਟਮ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੇ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੋਰ ਵਧਾ ਦਿੱਤਾ ਹੈ।

ਦੂਜੀ ਸਮੱਸਿਆ 2009 ਵਿੱਚ ਹੋਈ ਸੀ। ਫਿਰ, ਸਿਸਟਮ ਕਰੈਸ਼ ਤੋਂ ਬਾਅਦ, ਨਵੇਂ ext4 ਫਾਈਲ ਸਿਸਟਮ ਦੇ ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਪਾਇਆ ਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਨਵੀਆਂ ਬਣਾਈਆਂ ਫਾਈਲਾਂ ਜ਼ੀਰੋ-ਲੰਬਾਈ ਦੀਆਂ ਸਨ, ਪਰ ਪੁਰਾਣੇ ext3 ਫਾਈਲ ਸਿਸਟਮ ਨਾਲ ਅਜਿਹਾ ਨਹੀਂ ਹੋਇਆ। ਪਿਛਲੇ ਪੈਰੇ ਵਿੱਚ, ਮੈਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਸੀ ਕਿ ਕਿਵੇਂ ext3 ਨੇ ਡਿਸਕ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਡੇਟਾ ਡੰਪ ਕੀਤਾ, ਜਿਸ ਨਾਲ ਚੀਜ਼ਾਂ ਬਹੁਤ ਹੌਲੀ ਹੋ ਗਈਆਂ। fsync(). ਸਥਿਤੀ ਨੂੰ ਸੁਧਾਰਨ ਲਈ, ext4 ਸਿਰਫ ਉਹਨਾਂ "ਗੰਦੇ" ਪੰਨਿਆਂ ਨੂੰ ਫਲੱਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਕਿਸੇ ਖਾਸ ਫਾਈਲ ਨਾਲ ਸੰਬੰਧਿਤ ਹਨ। ਅਤੇ ਹੋਰ ਫਾਈਲਾਂ ਦਾ ਡੇਟਾ ext3 ਦੇ ਮੁਕਾਬਲੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮੇਂ ਲਈ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ. ਇਹ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਕੀਤਾ ਗਿਆ ਸੀ (ਮੂਲ ਰੂਪ ਵਿੱਚ, ਡੇਟਾ ਇਸ ਸਥਿਤੀ ਵਿੱਚ 30 ਸਕਿੰਟਾਂ ਲਈ ਰਹਿੰਦਾ ਹੈ, ਤੁਸੀਂ ਇਸਨੂੰ ਵਰਤ ਕੇ ਸੰਰਚਿਤ ਕਰ ਸਕਦੇ ਹੋ dirty_expire_centisecs; ਇੱਥੇ ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ)। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਕਰੈਸ਼ ਤੋਂ ਬਾਅਦ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਵਰਤਣਾ ਹੈ fsync() ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਜਿਹਨਾਂ ਨੂੰ ਸਥਿਰ ਡਾਟਾ ਸਟੋਰੇਜ ਪ੍ਰਦਾਨ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਅਸਫਲਤਾਵਾਂ ਦੇ ਨਤੀਜਿਆਂ ਤੋਂ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਫੰਕਸ਼ਨ fsync() ext4 ਦੇ ਮੁਕਾਬਲੇ ext3 ਨਾਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੁਸ਼ਲਤਾ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਸ ਪਹੁੰਚ ਦਾ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਇਸਦੀ ਵਰਤੋਂ, ਪਹਿਲਾਂ ਵਾਂਗ, ਕੁਝ ਕਾਰਜਾਂ ਨੂੰ ਹੌਲੀ ਕਰ ਦਿੰਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ। ਇਸ ਬਾਰੇ ਵੇਰਵੇ ਵੇਖੋ ਇੱਥੇ и ਇੱਥੇ.

ਬਾਰੇ ਤੀਜੀ ਸਮੱਸਿਆ fsync(), 2018 ਵਿੱਚ ਸ਼ੁਰੂ ਹੋਇਆ। ਫਿਰ, PostgreSQL ਪ੍ਰੋਜੈਕਟ ਦੇ ਫਰੇਮਵਰਕ ਦੇ ਅੰਦਰ, ਇਹ ਪਤਾ ਲੱਗਾ ਕਿ ਜੇਕਰ ਫੰਕਸ਼ਨ fsync() ਇੱਕ ਗਲਤੀ ਆਉਂਦੀ ਹੈ, ਇਹ "ਗੰਦੇ" ਪੰਨਿਆਂ ਨੂੰ "ਸਾਫ਼" ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਹੇਠ ਲਿਖੀਆਂ ਕਾਲਾਂ fsync() ਅਜਿਹੇ ਪੰਨਿਆਂ ਨਾਲ ਕੁਝ ਨਾ ਕਰੋ। ਇਸਦੇ ਕਾਰਨ, ਸੋਧੇ ਹੋਏ ਪੰਨੇ ਮੈਮੋਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕਦੇ ਵੀ ਡਿਸਕ ਤੇ ਨਹੀਂ ਲਿਖੇ ਜਾਂਦੇ ਹਨ। ਇਹ ਇੱਕ ਅਸਲ ਆਫ਼ਤ ਹੈ, ਕਿਉਂਕਿ ਐਪਲੀਕੇਸ਼ਨ ਸੋਚੇਗੀ ਕਿ ਕੁਝ ਡੇਟਾ ਡਿਸਕ ਤੇ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ ਅਜਿਹਾ ਨਹੀਂ ਹੋਵੇਗਾ. ਅਜਿਹੀਆਂ ਅਸਫਲਤਾਵਾਂ fsync() ਬਹੁਤ ਘੱਟ ਹੁੰਦੇ ਹਨ, ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਸਮੱਸਿਆ ਦਾ ਮੁਕਾਬਲਾ ਕਰਨ ਲਈ ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਅੱਜਕੱਲ੍ਹ, ਜਦੋਂ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ, PostgreSQL ਅਤੇ ਹੋਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਕਰੈਸ਼ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਇਹ ਇਸ ਲਈ ਹੈ, ਲੇਖ "ਕੀ ਐਪਲੀਕੇਸ਼ਨਾਂ fsync ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀਆਂ ਹਨ?" ਵਿੱਚ, ਇਸ ਸਮੱਸਿਆ ਦੀ ਵਿਸਥਾਰ ਵਿੱਚ ਖੋਜ ਕੀਤੀ ਗਈ ਹੈ। ਵਰਤਮਾਨ ਵਿੱਚ ਇਸ ਸਮੱਸਿਆ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੱਲ ਫਲੈਗ ਦੇ ਨਾਲ ਡਾਇਰੈਕਟ I/O ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ O_SYNC ਜਾਂ ਝੰਡੇ ਨਾਲ O_DSYNC. ਇਸ ਪਹੁੰਚ ਨਾਲ, ਸਿਸਟਮ ਉਹਨਾਂ ਗਲਤੀਆਂ ਦੀ ਰਿਪੋਰਟ ਕਰੇਗਾ ਜੋ ਖਾਸ ਡੇਟਾ ਲਿਖਣ ਦੇ ਕਾਰਜਾਂ ਨੂੰ ਕਰਨ ਵੇਲੇ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਇਸ ਪਹੁੰਚ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਖੁਦ ਬਫਰਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹੋ ਇੱਥੇ и ਇੱਥੇ.

O_SYNC ਅਤੇ O_DSYNC ਫਲੈਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਫਾਈਲਾਂ ਨੂੰ ਖੋਲ੍ਹਣਾ

ਚਲੋ ਲੀਨਕਸ ਵਿਧੀਆਂ ਦੀ ਚਰਚਾ 'ਤੇ ਵਾਪਸ ਆਓ ਜੋ ਨਿਰੰਤਰ ਡੇਟਾ ਸਟੋਰੇਜ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਅਰਥਾਤ, ਅਸੀਂ ਝੰਡੇ ਦੀ ਵਰਤੋਂ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ O_SYNC ਜਾਂ ਝੰਡਾ O_DSYNC ਸਿਸਟਮ ਕਾਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਫਾਈਲਾਂ ਖੋਲ੍ਹਣ ਵੇਲੇ ਖੋਲ੍ਹੋ(). ਇਸ ਪਹੁੰਚ ਨਾਲ, ਹਰੇਕ ਡੇਟਾ ਲਿਖਣ ਦੀ ਕਾਰਵਾਈ ਨੂੰ ਹਰ ਕਮਾਂਡ ਤੋਂ ਬਾਅਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ write() ਸਿਸਟਮ ਨੂੰ ਕ੍ਰਮਵਾਰ ਕਮਾਂਡਾਂ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ fsync() и fdatasync(). The POSIX ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਇਸਨੂੰ "ਸਿੰਕਰੋਨਾਈਜ਼ਡ I/O ਫਾਈਲ ਇੰਟੈਗਰਿਟੀ ਕੰਪਲੀਸ਼ਨ" ਅਤੇ "ਡੇਟਾ ਇੰਟੀਗ੍ਰੇਟੀ ਕੰਪਲੀਸ਼ਨ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਪਹੁੰਚ ਦਾ ਮੁੱਖ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਸਿਰਫ ਇੱਕ ਸਿਸਟਮ ਕਾਲ ਨੂੰ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਨਾ ਕਿ ਦੋ (ਉਦਾਹਰਨ ਲਈ - write() и fdatasync()). ਇਸ ਪਹੁੰਚ ਦਾ ਮੁੱਖ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਅਨੁਸਾਰੀ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਾਰੇ ਲਿਖਣ ਕਾਰਜਾਂ ਨੂੰ ਸਮਕਾਲੀ ਕੀਤਾ ਜਾਵੇਗਾ, ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਨੂੰ ਢਾਂਚਾ ਬਣਾਉਣ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਸੀਮਤ ਕਰ ਸਕਦਾ ਹੈ।

O_DIRECT ਫਲੈਗ ਨਾਲ ਡਾਇਰੈਕਟ I/O ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਸਿਸਟਮ ਕਾਲ open() ਝੰਡੇ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ O_DIRECT, ਜੋ ਕਿ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕੈਸ਼ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਡਿਸਕ ਨਾਲ ਸਿੱਧਾ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹੋਏ, I/O ਓਪਰੇਸ਼ਨ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਦਾ, ਬਹੁਤ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਮਤਲਬ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮ ਦੁਆਰਾ ਜਾਰੀ ਕੀਤੀਆਂ ਗਈਆਂ ਲਿਖਤਾਂ ਕਮਾਂਡਾਂ ਨੂੰ ਡਿਸਕ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਉਦੇਸ਼ ਨਾਲ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਕਮਾਂਡਾਂ ਵਿੱਚ ਅਨੁਵਾਦ ਕੀਤਾ ਜਾਵੇਗਾ। ਪਰ, ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਵਿਧੀ ਫੰਕਸ਼ਨਾਂ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ fsync() ਜ fdatasync(). ਤੱਥ ਇਹ ਹੈ ਕਿ ਡਿਸਕ ਆਪਣੇ ਆਪ ਹੀ ਕਰ ਸਕਦੀ ਹੈ ਦੇਰੀ ਜਾਂ ਕੈਸ਼ ਡਾਟਾ ਲਿਖਣ ਲਈ ਉਚਿਤ ਹੁਕਮ. ਅਤੇ, ਇਸ ਤੋਂ ਵੀ ਬਦਤਰ, ਕੁਝ ਖਾਸ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਫਲੈਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਕੀਤੇ ਗਏ I / O ਓਪਰੇਸ਼ਨ O_DIRECT, ਪ੍ਰਸਾਰਣ ਰਵਾਇਤੀ ਬਫਰ ਓਪਰੇਸ਼ਨ ਵਿੱਚ. ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਹੈ ਫਾਈਲਾਂ ਨੂੰ ਖੋਲ੍ਹਣ ਲਈ ਫਲੈਗ ਦੀ ਵਰਤੋਂ ਕਰਨਾ O_DSYNC, ਜਿਸਦਾ ਮਤਲਬ ਹੋਵੇਗਾ ਕਿ ਹਰੇਕ ਲਿਖਣ ਦੀ ਕਾਰਵਾਈ ਇੱਕ ਕਾਲ ਦੁਆਰਾ ਕੀਤੀ ਜਾਵੇਗੀ fdatasync().

ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ XFS ਫਾਈਲ ਸਿਸਟਮ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਇਸ ਲਈ ਇੱਕ "ਤੇਜ਼ ​​ਮਾਰਗ" ਜੋੜਿਆ ਹੈ O_DIRECT|O_DSYNC- ਡਾਟਾ ਰਿਕਾਰਡ. ਜੇਕਰ ਬਲਾਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਓਵਰਰਾਈਟ ਕੀਤਾ ਗਿਆ ਹੈ O_DIRECT|O_DSYNC, ਫਿਰ XFS, ਕੈਸ਼ ਨੂੰ ਫਲੱਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ, FUA ਰਾਈਟ ਕਮਾਂਡ ਨੂੰ ਚਲਾਏਗਾ ਜੇਕਰ ਡਿਵਾਈਸ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ। ਮੈਂ ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਹੈ blktrace ਇੱਕ Linux 5.4/Ubuntu 20.04 ਸਿਸਟਮ ਉੱਤੇ। ਇਹ ਪਹੁੰਚ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਡਿਸਕ 'ਤੇ ਘੱਟੋ-ਘੱਟ ਡੇਟਾ ਲਿਖਦਾ ਹੈ ਅਤੇ ਇੱਕ ਓਪਰੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਦੋ ਨਹੀਂ (ਕੈਸ਼ ਨੂੰ ਲਿਖੋ ਅਤੇ ਫਲੱਸ਼ ਕਰੋ)। ਮੈਨੂੰ ਇੱਕ ਲਿੰਕ ਮਿਲਿਆ ਪੈਚ 2018 ਕਰਨਲ ਜੋ ਇਸ ਵਿਧੀ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਇਸ ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਨੂੰ ਹੋਰ ਫਾਈਲ ਸਿਸਟਮਾਂ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਬਾਰੇ ਕੁਝ ਚਰਚਾ ਹੈ, ਪਰ ਜਿੱਥੋਂ ਤੱਕ ਮੈਂ ਜਾਣਦਾ ਹਾਂ, XFS ਇੱਕਮਾਤਰ ਫਾਈਲ ਸਿਸਟਮ ਹੈ ਜੋ ਹੁਣ ਤੱਕ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

sync_file_range() ਫੰਕਸ਼ਨ

Linux ਕੋਲ ਇੱਕ ਸਿਸਟਮ ਕਾਲ ਹੈ sync_file_range(), ਜੋ ਤੁਹਾਨੂੰ ਫਾਇਲ ਦੇ ਸਿਰਫ ਹਿੱਸੇ ਨੂੰ ਡਿਸਕ 'ਤੇ ਫਲੱਸ਼ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਨਾ ਕਿ ਪੂਰੀ ਫਾਈਲ ਨੂੰ। ਇਹ ਕਾਲ ਇੱਕ ਅਸਿੰਕ੍ਰੋਨਸ ਫਲੱਸ਼ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰਦੀ ਹੈ। ਪਰ ਦੇ ਹਵਾਲੇ ਵਿੱਚ sync_file_range() ਇਸ ਹੁਕਮ ਨੂੰ "ਬਹੁਤ ਖਤਰਨਾਕ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ. ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਖ਼ਤਰੇ sync_file_range() ਵਿੱਚ ਬਹੁਤ ਵਧੀਆ ਢੰਗ ਨਾਲ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ ਇਹ ਸਮੱਗਰੀ. ਖਾਸ ਤੌਰ 'ਤੇ, ਇਹ ਕਾਲ ਰੌਕਸਡੀਬੀ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਲਈ ਵਰਤਦੀ ਜਾਪਦੀ ਹੈ ਜਦੋਂ ਕਰਨਲ ਡਿਸਕ 'ਤੇ "ਗੰਦੇ" ਡੇਟਾ ਨੂੰ ਫਲੱਸ਼ ਕਰਦਾ ਹੈ। ਪਰ ਉਸੇ ਸਮੇਂ ਉੱਥੇ, ਸਥਿਰ ਡੇਟਾ ਸਟੋਰੇਜ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ, ਇਸਦੀ ਵਰਤੋਂ ਵੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ fdatasync(). The ਕੋਡ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਰੌਕਸਡੀਬੀ ਦੀਆਂ ਕੁਝ ਦਿਲਚਸਪ ਟਿੱਪਣੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਇਹ ਕਾਲ ਵਰਗਾ ਦਿਸਦਾ ਹੈ sync_file_range() ZFS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਡਾਟਾ ਡਿਸਕ 'ਤੇ ਫਲੱਸ਼ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਅਨੁਭਵ ਮੈਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਘੱਟ ਹੀ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਕੋਡ ਵਿੱਚ ਬੱਗ ਹੋ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ, ਮੈਂ ਇਸ ਸਿਸਟਮ ਕਾਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਵਿਰੁੱਧ ਸਲਾਹ ਦੇਵਾਂਗਾ ਜਦੋਂ ਤੱਕ ਕਿ ਬਿਲਕੁਲ ਜ਼ਰੂਰੀ ਨਾ ਹੋਵੇ।

ਡਾਟਾ ਸਥਿਰਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਸਿਸਟਮ ਕਾਲਾਂ

ਮੈਂ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚਿਆ ਹਾਂ ਕਿ ਇੱਥੇ ਤਿੰਨ ਤਰੀਕੇ ਹਨ ਜੋ ਲਗਾਤਾਰ I/O ਕਾਰਵਾਈਆਂ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਉਹਨਾਂ ਸਾਰਿਆਂ ਨੂੰ ਇੱਕ ਫੰਕਸ਼ਨ ਕਾਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ fsync() ਡਾਇਰੈਕਟਰੀ ਲਈ ਜਿੱਥੇ ਫਾਈਲ ਬਣਾਈ ਗਈ ਸੀ। ਇਹ ਪਹੁੰਚ ਹਨ:

1. ਫੰਕਸ਼ਨ ਕਾਲ fdatasync() ਜ fsync() ਫੰਕਸ਼ਨ ਦੇ ਬਾਅਦ write() (ਵਰਤਣ ਲਈ ਬਿਹਤਰ fdatasync()).
2. ਇੱਕ ਫਲੈਗ ਨਾਲ ਖੋਲ੍ਹਿਆ ਇੱਕ ਫਾਇਲ ਡਿਸਕ੍ਰਿਪਟਰ ਨਾਲ ਕੰਮ ਕਰਨਾ O_DSYNC ਜ O_SYNC (ਬਿਹਤਰ - ਇੱਕ ਝੰਡੇ ਨਾਲ O_DSYNC).
3. ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ pwritev2() ਝੰਡੇ ਦੇ ਨਾਲ RWF_DSYNC ਜ RWF_SYNC (ਤਰਜੀਹੀ ਤੌਰ 'ਤੇ ਝੰਡੇ ਨਾਲ RWF_DSYNC).

ਪ੍ਰਦਰਸ਼ਨ ਨੋਟਸ

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

1. ਫਾਈਲ ਡੇਟਾ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰਨਾ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਡੇਟਾ ਜੋੜਨ ਨਾਲੋਂ ਤੇਜ਼ ਹੈ (ਪ੍ਰਦਰਸ਼ਨ ਲਾਭ 2-100% ਹੋ ਸਕਦਾ ਹੈ)। ਇੱਕ ਫਾਈਲ ਨਾਲ ਡੇਟਾ ਨੱਥੀ ਕਰਨ ਲਈ ਫਾਈਲ ਦੇ ਮੈਟਾਡੇਟਾ ਵਿੱਚ ਵਾਧੂ ਤਬਦੀਲੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਸਿਸਟਮ ਕਾਲ ਤੋਂ ਬਾਅਦ ਵੀ fallocate(), ਪਰ ਇਸ ਪ੍ਰਭਾਵ ਦੀ ਤੀਬਰਤਾ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੀ ਹੈ। ਮੈਂ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ, ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਲਈ, ਕਾਲ ਕਰਨ ਲਈ fallocate() ਲੋੜੀਂਦੀ ਜਗ੍ਹਾ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ। ਫਿਰ ਇਸ ਸਪੇਸ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਜ਼ੀਰੋ ਨਾਲ ਭਰਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਬੁਲਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ fsync(). ਇਹ ਫਾਇਲ ਸਿਸਟਮ ਵਿੱਚ ਸੰਬੰਧਿਤ ਬਲਾਕਾਂ ਨੂੰ "ਅਲੋਕੇਟਿਡ" ਦੀ ਬਜਾਏ "ਅਲੋਕੇਟਡ" ਵਜੋਂ ਮਾਰਕ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣ ਜਾਵੇਗਾ। ਇਹ ਇੱਕ ਛੋਟਾ (ਲਗਭਗ 2%) ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰ ਦਿੰਦਾ ਹੈ। ਨਾਲ ਹੀ, ਕੁਝ ਡਿਸਕਾਂ ਦਾ ਪਹਿਲਾ ਬਲਾਕ ਐਕਸੈਸ ਓਪਰੇਸ਼ਨ ਦੂਜਿਆਂ ਨਾਲੋਂ ਹੌਲੀ ਹੋ ਸਕਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜ਼ੀਰੋ ਨਾਲ ਸਪੇਸ ਭਰਨ ਨਾਲ ਇੱਕ ਮਹੱਤਵਪੂਰਨ (ਲਗਭਗ 100%) ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰ ਹੋ ਸਕਦਾ ਹੈ। ਖਾਸ ਤੌਰ 'ਤੇ, ਇਹ ਡਿਸਕਾਂ ਨਾਲ ਹੋ ਸਕਦਾ ਹੈ। AWS EBS (ਇਹ ਅਣਅਧਿਕਾਰਤ ਡੇਟਾ ਹੈ, ਮੈਂ ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕਰ ਸਕਿਆ)। ਇਹੀ ਸਟੋਰੇਜ ਲਈ ਜਾਂਦਾ ਹੈ. GCP ਪਰਸਿਸਟੈਂਟ ਡਿਸਕ (ਅਤੇ ਇਹ ਪਹਿਲਾਂ ਹੀ ਅਧਿਕਾਰਤ ਜਾਣਕਾਰੀ ਹੈ, ਟੈਸਟਾਂ ਦੁਆਰਾ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਹੈ)। ਹੋਰ ਮਾਹਿਰਾਂ ਨੇ ਵੀ ਅਜਿਹਾ ਹੀ ਕੀਤਾ ਹੈ ਨਿਰੀਖਣਵੱਖ-ਵੱਖ ਡਿਸਕ ਨਾਲ ਸਬੰਧਤ.
2. ਜਿੰਨੀਆਂ ਘੱਟ ਸਿਸਟਮ ਕਾਲਾਂ, ਓਨਾ ਹੀ ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ (ਲਾਭ ਲਗਭਗ 5% ਹੋ ਸਕਦਾ ਹੈ)। ਇਹ ਇੱਕ ਕਾਲ ਵਰਗਾ ਲੱਗਦਾ ਹੈ open() ਝੰਡੇ ਦੇ ਨਾਲ O_DSYNC ਜਾਂ ਕਾਲ ਕਰੋ pwritev2() ਝੰਡੇ ਦੇ ਨਾਲ RWF_SYNC ਤੇਜ਼ ਕਾਲ fdatasync(). ਮੈਨੂੰ ਸ਼ੱਕ ਹੈ ਕਿ ਇੱਥੇ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਇਸ ਪਹੁੰਚ ਨਾਲ, ਇਹ ਤੱਥ ਕਿ ਇੱਕੋ ਕੰਮ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਘੱਟ ਸਿਸਟਮ ਕਾਲਾਂ ਕਰਨੀਆਂ ਪੈਂਦੀਆਂ ਹਨ (ਦੋ ਦੀ ਬਜਾਏ ਇੱਕ ਕਾਲ) ਇੱਕ ਭੂਮਿਕਾ ਨਿਭਾਉਂਦੀ ਹੈ. ਪਰ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਅੰਤਰ ਬਹੁਤ ਛੋਟਾ ਹੈ, ਇਸਲਈ ਤੁਸੀਂ ਇਸਨੂੰ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਕੁਝ ਅਜਿਹਾ ਵਰਤ ਸਕਦੇ ਹੋ ਜਿਸ ਨਾਲ ਇਸਦੇ ਤਰਕ ਦੀ ਪੇਚੀਦਗੀ ਨਹੀਂ ਹੁੰਦੀ।

ਜੇਕਰ ਤੁਸੀਂ ਟਿਕਾਊ ਡੇਟਾ ਸਟੋਰੇਜ ਦੇ ਵਿਸ਼ੇ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਇੱਥੇ ਕੁਝ ਉਪਯੋਗੀ ਸਮੱਗਰੀਆਂ ਹਨ:

• I/O ਪਹੁੰਚ ਵਿਧੀਆਂ - ਇੰਪੁੱਟ/ਆਊਟਪੁੱਟ ਮਕੈਨਿਜ਼ਮ ਦੀਆਂ ਮੂਲ ਗੱਲਾਂ ਦੀ ਇੱਕ ਸੰਖੇਪ ਜਾਣਕਾਰੀ।
• ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਕਿ ਡਾਟਾ ਡਿਸਕ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ - ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਡਿਸਕ ਦੇ ਰਸਤੇ 'ਤੇ ਡੇਟਾ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ ਇਸ ਬਾਰੇ ਇੱਕ ਕਹਾਣੀ।
• ਤੁਹਾਨੂੰ ਰੱਖਣ ਵਾਲੀ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਕਦੋਂ fsync ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ - ਕਦੋਂ ਅਰਜ਼ੀ ਦੇਣੀ ਹੈ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ fsync() ਡਾਇਰੈਕਟਰੀਆਂ ਲਈ. ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਇੱਕ ਨਵੀਂ ਫਾਈਲ ਬਣਾਉਣ ਵੇਲੇ ਅਜਿਹਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਅਤੇ ਇਸ ਸਿਫਾਰਸ਼ ਦਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਲੀਨਕਸ ਵਿੱਚ ਇੱਕੋ ਫਾਈਲ ਦੇ ਬਹੁਤ ਸਾਰੇ ਹਵਾਲੇ ਹੋ ਸਕਦੇ ਹਨ.
• ਲੀਨਕਸ ਉੱਤੇ SQL ਸਰਵਰ: FUA ਅੰਦਰੂਨੀ - ਇੱਥੇ ਇੱਕ ਵਰਣਨ ਹੈ ਕਿ ਕਿਵੇਂ ਲੀਨਕਸ ਪਲੇਟਫਾਰਮ 'ਤੇ SQL ਸਰਵਰ ਵਿੱਚ ਨਿਰੰਤਰ ਡੇਟਾ ਸਟੋਰੇਜ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇੱਥੇ ਵਿੰਡੋਜ਼ ਅਤੇ ਲੀਨਕਸ ਸਿਸਟਮ ਕਾਲਾਂ ਵਿਚਕਾਰ ਕੁਝ ਦਿਲਚਸਪ ਤੁਲਨਾਵਾਂ ਹਨ। ਮੈਨੂੰ ਲਗਭਗ ਯਕੀਨ ਹੈ ਕਿ ਇਹ ਇਸ ਸਮੱਗਰੀ ਦਾ ਧੰਨਵਾਦ ਸੀ ਜੋ ਮੈਂ XFS ਦੇ FUA ਓਪਟੀਮਾਈਜੇਸ਼ਨ ਬਾਰੇ ਸਿੱਖਿਆ ਹੈ।

ਕੀ ਤੁਸੀਂ ਕਦੇ ਉਹ ਡੇਟਾ ਗੁਆ ਦਿੱਤਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸੋਚਿਆ ਸੀ ਕਿ ਡਿਸਕ 'ਤੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਸੀ?

ਸਰੋਤ: www.habr.com