ਐਕਟਿਵ ਰੀਸਟੋਰ: ਕੀ ਆਫ਼ਤ ਰਿਕਵਰੀ ਤੇਜ਼ੀ ਨਾਲ ਹੋ ਸਕਦੀ ਹੈ? ਬਹੁਤ ਤੇਜ਼?

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

ਸਤ ਸ੍ਰੀ ਅਕਾਲ! ਮੇਰਾ ਨਾਮ ਦੌਲਤ ਤੁਮਬਾਯੇਵ ਹੈ, ਅਤੇ ਅੱਜ ਮੈਂ ਤੁਹਾਡੇ ਨਾਲ ਇੱਕ ਅਜਿਹੀ ਪ੍ਰਣਾਲੀ ਵਿਕਸਿਤ ਕਰਨ ਵਿੱਚ ਆਪਣਾ ਅਨੁਭਵ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹਾਂਗਾ ਜੋ ਤਬਾਹੀ ਦੀ ਰਿਕਵਰੀ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ। ਪ੍ਰੋਜੈਕਟ ਦੇ ਸਮੁੱਚੇ ਵਿਕਾਸ ਮਾਰਗ ਬਾਰੇ ਗੱਲ ਕਰਨ ਲਈ, ਆਓ ਥੋੜਾ ਦੂਰੋਂ ਸ਼ੁਰੂ ਕਰੀਏ. ਮੈਂ ਵਰਤਮਾਨ ਵਿੱਚ Acronis ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹਾਂ, ਪਰ ਮੈਂ ਇਨੋਪੋਲਿਸ ਯੂਨੀਵਰਸਿਟੀ ਦਾ ਗ੍ਰੈਜੂਏਟ ਵੀ ਹਾਂ, ਜਿੱਥੇ ਮੈਂ ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਮੈਂਟ ਮੈਨੇਜਮੈਂਟ (MSIT-SE ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ) ਵਿੱਚ ਮਾਸਟਰ ਪ੍ਰੋਗਰਾਮ ਪੂਰਾ ਕੀਤਾ ਹੈ। ਇਨੋਪੋਲਿਸ ਇੱਕ ਨੌਜਵਾਨ ਯੂਨੀਵਰਸਿਟੀ ਹੈ, ਅਤੇ ਪਾਠਕ੍ਰਮ ਹੋਰ ਵੀ ਛੋਟਾ ਹੈ। ਪਰ ਇਹ ਕਾਰਨੇਗੀ ਮੇਲਨ ਯੂਨੀਵਰਸਿਟੀ ਦੇ ਪਾਠਕ੍ਰਮ 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਜਿਸ ਦੇ ਕੰਮ ਵਿੱਚ ਉਦਯੋਗਿਕ ਪ੍ਰੋਜੈਕਟਾਂ ਵਰਗੇ ਵਿਸ਼ੇ ਸ਼ਾਮਲ ਹਨ।

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

ਐਕਟਿਵ ਰੀਸਟੋਰ - ਇਸਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ, ਆਫ਼ਤ ਰਿਕਵਰੀ ਇੱਕ ਮਿਆਰੀ ਸਕੀਮ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦੀ ਹੈ। ਤੁਹਾਡੇ ਕੰਪਿਊਟਰ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਕੁਝ ਬੈਕਅੱਪ ਸਿਸਟਮ ਦੇ ਵੈੱਬ ਇੰਟਰਫੇਸ 'ਤੇ ਜਾਂਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਐਕ੍ਰੋਨਿਸ ਟਰੂ ਇਮੇਜ, ਅਤੇ ਵੱਡੇ "ਰੀਸਟੋਰ" ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰੋ। ਅੱਗੇ ਤੁਹਾਨੂੰ N ਮਿੰਟ ਉਡੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਤੁਸੀਂ ਕੰਮ ਕਰਨਾ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹੋ।

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

ਡਰਾਈਵਰ ਦੀ ਲੋੜ ਹੈ...

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

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

ਇਹ ਉਹੀ ਹੈ ਜੋ ਇੱਕ ਆਦਰਸ਼ ਤਸਵੀਰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਹਾਲਾਂਕਿ, ਅਸਲ ਸੰਸਾਰ ਵਿੱਚ, ਬਹੁਤ ਸਾਰੀਆਂ ਮੁਸ਼ਕਲਾਂ ਅਤੇ ਸੰਭਾਵਿਤ ਰੁਕਾਵਟਾਂ ਹਨ. Innopolis ਮਾਸਟਰ ਦੇ ਵਿਦਿਆਰਥੀਆਂ ਦੇ ਨਾਲ, ਅਸੀਂ ਇਸ ਰਿਕਵਰੀ ਦ੍ਰਿਸ਼ ਦੀ ਪੜਚੋਲ ਕਰਨ, RTO ਵਿੱਚ ਲਾਭਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ, ਅਤੇ ਇਹ ਸਮਝਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਕੀ ਅਜਿਹੀ ਪਹੁੰਚ ਸੰਭਵ ਹੈ? ਆਖ਼ਰਕਾਰ, ਉਸ ਸਮੇਂ ਮਾਰਕੀਟ ਵਿਚ ਅਜਿਹੇ ਕੋਈ ਹੱਲ ਨਹੀਂ ਸਨ.

ਅਤੇ ਜੇਕਰ ਮੈਂ ਇਨੋਪੋਲਿਸ ਦੇ ਮੁੰਡਿਆਂ ਲਈ ਸਰਵਿਸ ਕੰਪੋਨੈਂਟ ਤਿਆਰ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਤਾਂ ਐਕ੍ਰੋਨਿਸ ਦੇ ਅੰਦਰ ਕੰਮ ਸ਼ੁਰੂ ਹੋਇਆ ਫਾਇਲ ਸਿਸਟਮ ਡਰਾਈਵਰ ਦੁਆਰਾ ਮਿੰਨੀ-ਫਿਲਟਰਟੀਮ ਨੇ ਇਸਦਾ ਧਿਆਨ ਰੱਖਿਆ। Windows ਕਰਨਲ। ਯੋਜਨਾ ਇਹ ਸੀ:

• OS ਸਟਾਰਟਅਪ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਡਰਾਈਵਰ ਨੂੰ ਲਾਂਚ ਕਰੋ,
• ਕੰਮ ਦੇ ਦੌਰਾਨ, ਜਦੋਂ ਯੂਜ਼ਰ ਸਪੇਸ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਹੋ ਜਾਵੇਗਾ, ਸੇਵਾ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰੋ
• ਸੇਵਾ ਡਰਾਈਵਰ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸਦੇ ਅਗਲੇ ਕੰਮ ਦਾ ਤਾਲਮੇਲ ਕਰਦੀ ਹੈ।

ਡਰਾਈਵਰ ਇੰਜੀਨੀਅਰਿੰਗ ਦੀਆਂ ਸੂਖਮਤਾਵਾਂ

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

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

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

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

ਜੇਕਰ ਰਿਕਵਰੀ ਅਸੰਭਵ ਹੈ, ਤਾਂ ਸੇਵਾ ਡਰਾਈਵਰ ਨੂੰ ਸੂਚਿਤ ਕਰਦੀ ਹੈ ਕਿ ਫਾਈਲ ਬੈਕਅੱਪ ਵਿੱਚ ਨਹੀਂ ਹੈ। ਸਾਡਾ ਮਿੰਨੀ-ਫਿਲਟਰ ਡ੍ਰਾਈਵਰ ਸਿਸਟਮ ਬੇਨਤੀ ਨੂੰ ਅੱਗੇ ਪਾਸ ਕਰਦਾ ਹੈ ਅਤੇ ਅਸਲ ਬੇਨਤੀਕਰਤਾ (ਓਐਸ ਖੁਦ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ) ਨੂੰ "ਫਾਇਲ ਨਹੀਂ ਲੱਭੀ" ਗਲਤੀ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਇਹ ਬਹੁਤ ਆਮ ਹੈ ਜੇਕਰ ਫਾਈਲ ਅਸਲ ਵਿੱਚ ਡਿਸਕ ਅਤੇ ਬੈਕਅੱਪ ਵਿੱਚ ਨਹੀਂ ਸੀ.

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

ਨੀਵਾਂ ਚਾਹੀਦਾ, ਨੀਵਾਂ ਵੀ...

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

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

ਅਗਲਾ ਕਦਮ ਜੋ ਮੈਂ ਚੁੱਕਿਆ ਉਹ ਸੀ ਡਰਾਈਵਰ ਨੂੰ ਡੂੰਘਾ ਅਤੇ ਪਹਿਲਾਂ ਚਲਾਉਣਾ, UEFI ਡਰਾਈਵਰ ਅਤੇ ਨੇਟਿਵ ਪੱਧਰ ਤੱਕ ਹੇਠਾਂ ਜਾਣਾ। Windows ਸੇਵਾ ਦੀ ਬਜਾਏ ਐਪਲੀਕੇਸ਼ਨਾਂ। ਇਸ ਉਦੇਸ਼ ਲਈ, ਇਸਨੂੰ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਸੀ UEFI ਬੂਟ ਡਰਾਈਵਰ (ਜਾਂ DXE ਡਰਾਈਵਰ), ਜੋ OS ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਪਰ UEFI ਡਰਾਈਵਰਾਂ ਦਾ "ਇਤਿਹਾਸ", ਅਸੈਂਬਲੀ ਅਤੇ ਇੰਸਟਾਲੇਸ਼ਨ ਬਾਰੇ ਵੇਰਵੇ, ਅਤੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ Windows ਅਸੀਂ ਅਗਲੀ ਪੋਸਟ ਵਿੱਚ ਨੇਟਿਵ ਐਪਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ। ਇਸ ਲਈ ਸਾਡੇ ਬਲੌਗ ਨੂੰ ਸਬਸਕ੍ਰਾਈਬ ਕਰੋ ਜਦੋਂ ਤੱਕ ਮੈਂ ਆਪਣੇ ਕੰਮ ਦੇ ਅਗਲੇ ਪੜਾਅ ਬਾਰੇ ਇੱਕ ਕਹਾਣੀ ਤਿਆਰ ਨਹੀਂ ਕਰ ਰਿਹਾ। ਮੈਨੂੰ ਤੁਹਾਡੀਆਂ ਟਿੱਪਣੀਆਂ ਅਤੇ ਸੁਝਾਅ ਸੁਣਨਾ ਪਸੰਦ ਆਵੇਗਾ।

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਕਦੇ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਆਈਆਂ ਹਨ ਜਿੱਥੇ ਰਿਕਵਰੀ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ:

• 65.1%ਹਾਂ28

• 23.2%ਨੰ 10

• 11.6%ਇਸ ਬਾਰੇ ਨਹੀਂ ਸੋਚਿਆ 5

43 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਕੀਤਾ। 3 ਉਪਭੋਗਤਾ ਬਚੇ।

ਸਰੋਤ: www.habr.com