ਲੀਨਕਸ ਵਿੱਚ ਵਰਚੁਅਲ ਫਾਈਲ ਸਿਸਟਮ: ਉਹਨਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ ਅਤੇ ਉਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ? ਭਾਗ 2

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

eBPF ਅਤੇ bcc ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ VFS ਦੀ ਨਿਗਰਾਨੀ ਕਿਵੇਂ ਕਰੀਏ

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

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਔਜ਼ਾਰਾਂ ਦੀ ਮਦਦ ਨਾਲ eBPF ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਕਾਫ਼ੀ ਆਸਾਨ ਹੈ BCC, ਜੋ ਕਿ ਆਮ ਵੰਡ ਤੋਂ ਪੈਕੇਜਾਂ ਵਜੋਂ ਉਪਲਬਧ ਹਨ ਲੀਨਕਸ ਅਤੇ ਵਿਸਥਾਰ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ੀ ਬਰਨਾਰਡ ਗ੍ਰੇਗ. ਸੰਦ bcc C ਕੋਡ ਦੀਆਂ ਛੋਟੀਆਂ ਸੰਮਿਲਨਾਂ ਵਾਲੀਆਂ ਪਾਈਥਨ ਸਕ੍ਰਿਪਟਾਂ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਦੋਵਾਂ ਭਾਸ਼ਾਵਾਂ ਤੋਂ ਜਾਣੂ ਕੋਈ ਵੀ ਵਿਅਕਤੀ ਆਸਾਨੀ ਨਾਲ ਇਹਨਾਂ ਨੂੰ ਸੋਧ ਸਕਦਾ ਹੈ। IN bcc/tools ਇੱਥੇ 80 ਪਾਈਥਨ ਸਕ੍ਰਿਪਟਾਂ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਇੱਕ ਡਿਵੈਲਪਰ ਜਾਂ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਕੁਝ ਢੁਕਵਾਂ ਚੁਣਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ।
VFS ਚੱਲ ਰਹੇ ਸਿਸਟਮ 'ਤੇ ਕੀ ਕੰਮ ਕਰਦੇ ਹਨ ਇਸ ਬਾਰੇ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਸਤਹੀ ਵਿਚਾਰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਕੋਸ਼ਿਸ਼ ਕਰੋ vfscount ਜ vfsstat. ਇਹ ਦਿਖਾਏਗਾ, ਮੰਨ ਲਓ, ਦਰਜਨਾਂ ਕਾਲਾਂ vfs_open() ਅਤੇ "ਉਸਦੇ ਦੋਸਤ" ਹਰ ਸਕਿੰਟ ਦਾ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਵਾਪਰਦੇ ਹਨ।

vfsstat.py C ਕੋਡ ਸੰਮਿਲਿਤ ਕਰਨ ਵਾਲੀ ਪਾਈਥਨ ਸਕ੍ਰਿਪਟ ਹੈ ਜੋ ਬਸ VFS ਫੰਕਸ਼ਨ ਕਾਲਾਂ ਦੀ ਗਿਣਤੀ ਕਰਦੀ ਹੈ।

ਆਉ ਇੱਕ ਹੋਰ ਮਾਮੂਲੀ ਉਦਾਹਰਣ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਦੇਖਦੇ ਹਾਂ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਕੰਪਿਊਟਰ ਵਿੱਚ ਇੱਕ USB ਫਲੈਸ਼ ਡਰਾਈਵ ਪਾਉਂਦੇ ਹਾਂ ਅਤੇ ਸਿਸਟਮ ਇਸਨੂੰ ਖੋਜਦਾ ਹੈ।

eBPF ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇਸ ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ /sysਜਦੋਂ ਇੱਕ USB ਫਲੈਸ਼ ਡਰਾਈਵ ਪਾਈ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਅਤੇ ਗੁੰਝਲਦਾਰ ਉਦਾਹਰਣ ਇੱਥੇ ਦਿਖਾਈ ਗਈ ਹੈ।

ਉੱਪਰ ਦਿਖਾਈ ਗਈ ਉਦਾਹਰਨ ਵਿੱਚ, bcc ਸੰਦ ਹੈ trace.py ਜਦੋਂ ਕਮਾਂਡ ਚਲਾਈ ਜਾਂਦੀ ਹੈ ਤਾਂ ਇੱਕ ਸੁਨੇਹਾ ਪ੍ਰਿੰਟ ਕਰਦਾ ਹੈ sysfs_create_files(). ਅਸੀਂ ਇਹ ਦੇਖਦੇ ਹਾਂ sysfs_create_files() ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਸੀ kworker ਇਸ ਤੱਥ ਦੇ ਜਵਾਬ ਵਿੱਚ ਸਟ੍ਰੀਮ ਕਰੋ ਕਿ ਫਲੈਸ਼ ਡਰਾਈਵ ਪਾਈ ਗਈ ਸੀ, ਪਰ ਕਿਹੜੀ ਫਾਈਲ ਬਣਾਈ ਗਈ ਸੀ? ਦੂਜੀ ਉਦਾਹਰਣ eBPF ਦੀ ਸ਼ਕਤੀ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ। ਇਥੇ trace.py ਇੱਕ ਕਰਨਲ ਬੈਕਟਰੇਸ (-K ਵਿਕਲਪ) ਅਤੇ ਬਣਾਈ ਗਈ ਫਾਈਲ ਦਾ ਨਾਮ ਪ੍ਰਿੰਟ ਕਰਦਾ ਹੈ sysfs_create_files(). ਸਿੰਗਲ ਸਟੇਟਮੈਂਟ ਸੰਮਿਲਨ C ਕੋਡ ਹੈ ਜਿਸ ਵਿੱਚ ਪਾਈਥਨ ਸਕ੍ਰਿਪਟ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਗਈ ਇੱਕ ਆਸਾਨੀ ਨਾਲ ਪਛਾਣਨਯੋਗ ਫਾਰਮੈਟ ਸਤਰ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ ਜੋ LLVM ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ। ਬਸ-ਇਨ-ਟਾਈਮ ਕੰਪਾਈਲਰ. ਇਹ ਇਸ ਲਾਈਨ ਨੂੰ ਕੰਪਾਇਲ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਰਨਲ ਦੇ ਅੰਦਰ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਵਿੱਚ ਚਲਾਉਂਦਾ ਹੈ। ਪੂਰਾ ਫੰਕਸ਼ਨ ਦਸਤਖਤ sysfs_create_files () ਦੂਜੀ ਕਮਾਂਡ ਵਿੱਚ ਦੁਬਾਰਾ ਤਿਆਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਕਿ ਫਾਰਮੈਟ ਸਤਰ ਇੱਕ ਪੈਰਾਮੀਟਰ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕੇ। C ਕੋਡ ਦੇ ਇਸ ਟੁਕੜੇ ਵਿੱਚ ਗਲਤੀਆਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ C ਕੰਪਾਈਲਰ ਤੋਂ ਪਛਾਣਨਯੋਗ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ -l ਪੈਰਾਮੀਟਰ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ "BPF ਟੈਕਸਟ ਨੂੰ ਕੰਪਾਇਲ ਕਰਨ ਵਿੱਚ ਅਸਫਲ" ਵੇਖੋਗੇ। ਡਿਵੈਲਪਰ ਜੋ C ਅਤੇ Python ਤੋਂ ਜਾਣੂ ਹਨ ਉਹ ਟੂਲ ਲੱਭ ਲੈਣਗੇ bcc ਫੈਲਾਉਣ ਅਤੇ ਬਦਲਣ ਲਈ ਆਸਾਨ.

ਜਦੋਂ USB ਡਰਾਈਵ ਪਾਈ ਜਾਂਦੀ ਹੈ, ਕਰਨਲ ਬੈਕਟਰੇਸ ਦਿਖਾਏਗਾ ਕਿ PID 7711 ਇੱਕ ਥਰਿੱਡ ਹੈ kworkerਜਿਸ ਨੇ ਫਾਈਲ ਬਣਾਈ ਹੈ «events» в sysfs. ਇਸ ਅਨੁਸਾਰ, ਤੋਂ ਕਾਲ sysfs_remove_files() ਇਹ ਦਰਸਾਏਗਾ ਕਿ ਡਰਾਈਵ ਨੂੰ ਹਟਾਉਣ ਨਾਲ ਫਾਈਲ ਨੂੰ ਮਿਟਾਇਆ ਜਾ ਰਿਹਾ ਹੈ events, ਜੋ ਕਿ ਸੰਦਰਭ ਗਿਣਤੀ ਦੀ ਆਮ ਧਾਰਨਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਉਸੇ ਸਮੇਂ, ਦੇਖਣਾ sysfs_create_link () eBPF ਨਾਲ USB ਡਰਾਈਵ ਪਾਉਣ ਵੇਲੇ ਇਹ ਦਿਖਾਏਗਾ ਕਿ ਘੱਟੋ-ਘੱਟ 48 ਪ੍ਰਤੀਕ ਲਿੰਕ ਬਣਾਏ ਗਏ ਹਨ।

ਤਾਂ ਇਵੈਂਟ ਫਾਈਲ ਦਾ ਕੀ ਮਤਲਬ ਹੈ? ਵਰਤੋਂ cscope ਖੋਜ ਲਈ __device_add_disk(), ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇਸਦਾ ਕੀ ਕਾਰਨ ਹੈ disk_add_events (), ਅਤੇ ਜਾਂ ਤਾਂ "media_change", ਜਾਂ "eject_request" ਇੱਕ ਘਟਨਾ ਫਾਇਲ ਵਿੱਚ ਦਰਜ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਇੱਥੇ ਕਰਨਲ ਬਲਾਕ ਲੇਅਰ ਯੂਜ਼ਰਸਪੇਸ ਨੂੰ ਸੂਚਿਤ ਕਰਦੀ ਹੈ ਕਿ ਇੱਕ "ਡਿਸਕ" ਦਿਖਾਈ ਦਿੱਤੀ ਹੈ ਅਤੇ ਬਾਹਰ ਕੱਢੀ ਗਈ ਹੈ। ਨੋਟ ਕਰੋ ਕਿ ਇਹ ਖੋਜ ਵਿਧੀ ਇੱਕ USB ਡਰਾਈਵ ਪਾ ਕੇ ਕਿੰਨੀ ਜਾਣਕਾਰੀ ਭਰਪੂਰ ਹੈ, ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੇ ਮੁਕਾਬਲੇ ਕਿ ਚੀਜ਼ਾਂ ਸਰੋਤ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।

ਰੀਡ-ਓਨਲੀ ਰੂਟ ਫਾਈਲ ਸਿਸਟਮ ਏਮਬੈਡਡ ਡਿਵਾਈਸਾਂ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹਨ

ਬੇਸ਼ੱਕ, ਕੋਈ ਵੀ ਸਾਕਟ ਤੋਂ ਪਲੱਗ ਖਿੱਚ ਕੇ ਸਰਵਰ ਜਾਂ ਆਪਣੇ ਕੰਪਿਊਟਰ ਨੂੰ ਬੰਦ ਨਹੀਂ ਕਰਦਾ. ਲੇਕਿਨ ਕਿਉਂ? ਇਹ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਭੌਤਿਕ ਸਟੋਰੇਜ਼ ਜੰਤਰਾਂ ਉੱਤੇ ਮਾਊਂਟ ਕੀਤੇ ਫਾਈਲ ਸਿਸਟਮਾਂ ਵਿੱਚ ਰਾਈਟਸ ਪਛੜ ਗਏ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਡਾਟਾ ਬਣਤਰ ਜੋ ਉਹਨਾਂ ਦੀ ਸਥਿਤੀ ਨੂੰ ਰਿਕਾਰਡ ਕਰਦੇ ਹਨ ਸਟੋਰੇਜ਼ ਵਿੱਚ ਲਿਖਤਾਂ ਨਾਲ ਸਮਕਾਲੀ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ। ਜਦੋਂ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ, ਸਿਸਟਮ ਮਾਲਕਾਂ ਨੂੰ ਉਪਯੋਗਤਾ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਅਗਲੇ ਬੂਟ ਤੱਕ ਉਡੀਕ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। fsck filesystem-recovery ਅਤੇ, ਸਭ ਤੋਂ ਮਾੜੀ ਸਥਿਤੀ ਵਿੱਚ, ਡੇਟਾ ਗੁਆਉਣਾ।

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

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

ਸ੍ਰਿਸ਼ਟੀ rootfs ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ ਏਮਬੈਡ ਕੀਤੇ ਡਿਵੈਲਪਰਾਂ ਲਈ ਕੁਝ ਵਾਧੂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ VFS ਤਸਵੀਰ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਲੀਨਕਸ ਨੂੰ ਫਾਈਲਾਂ ਅੰਦਰ ਹੋਣ ਦੀ ਲੋੜ ਹੈ /var ਲਿਖਣਯੋਗ ਸਨ, ਅਤੇ ਇਸ ਤੋਂ ਇਲਾਵਾ, ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰਸਿੱਧ ਐਪਲੀਕੇਸ਼ਨਾਂ ਜੋ ਏਮਬੈਡਡ ਸਿਸਟਮਾਂ ਨੂੰ ਚਲਾਉਂਦੀਆਂ ਹਨ, ਸੰਰਚਨਾ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਗੀਆਂ dot-files в $HOME. ਹੋਮ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਸੰਰਚਨਾ ਫਾਈਲਾਂ ਦਾ ਇੱਕ ਹੱਲ ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਕਰਨਾ ਅਤੇ ਬਣਾਉਣਾ ਹੁੰਦਾ ਹੈ rootfs. ਲਈ /var ਇੱਕ ਸੰਭਾਵੀ ਪਹੁੰਚ ਇਸ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਲਿਖਣਯੋਗ ਭਾਗ ਉੱਤੇ ਮਾਊਂਟ ਕਰਨਾ ਹੈ, ਜਦਕਿ / ਸਿਰਫ਼ ਪੜ੍ਹਨ ਲਈ ਮਾਊਂਟ ਕੀਤਾ ਗਿਆ। ਇੱਕ ਹੋਰ ਪ੍ਰਸਿੱਧ ਵਿਕਲਪ ਬਾਈਂਡ ਜਾਂ ਓਵਰਲੇ ਮਾਊਂਟ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ।

ਲਿੰਕੇਬਲ ਅਤੇ ਸਟੈਕੇਬਲ ਮਾਊਂਟ, ਕੰਟੇਨਰਾਂ ਦੁਆਰਾ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ

ਇੱਕ ਹੁਕਮ ਚਲਾਉਣਾ man mount ਬਾਈਂਡੇਬਲ ਅਤੇ ਓਵਰਲੇਏਬਲ ਮਾਊਂਟਸ ਬਾਰੇ ਸਿੱਖਣ ਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰੀਕਾ ਹੈ, ਜੋ ਕਿ ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਇੱਕ ਪਾਥ ਵਿੱਚ ਇੱਕ ਫਾਈਲ ਸਿਸਟਮ ਬਣਾਉਣ ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਦੂਜੇ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਐਕਸਪੋਜ਼ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਦਿੰਦੇ ਹਨ। ਏਮਬੈਡਡ ਸਿਸਟਮਾਂ ਲਈ, ਇਸਦਾ ਅਰਥ ਹੈ ਫਾਈਲਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੀ ਯੋਗਤਾ /var ਸਿਰਫ਼ ਪੜ੍ਹਨ ਲਈ ਫਲੈਸ਼ ਡਰਾਈਵ 'ਤੇ, ਪਰ ਇੱਕ ਓਵਰਲੇਅ ਜਾਂ ਲਿੰਕ ਹੋਣ ਯੋਗ ਮਾਊਂਟ ਮਾਰਗ ਤੋਂ tmpfs в /var ਲੋਡ ਕਰਨ ਵੇਲੇ, ਇਹ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਉੱਥੇ ਨੋਟ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ (ਸਕ੍ਰੌਲ)। ਅਗਲੀ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਚਾਲੂ ਕਰਦੇ ਹੋ /var ਖਤਮ ਹੋ ਜਾਵੇਗਾ. ਇੱਕ ਓਵਰਲੇ ਮਾਉਂਟ ਵਿਚਕਾਰ ਇੱਕ ਯੂਨੀਅਨ ਬਣਾਉਂਦਾ ਹੈ tmpfs ਅਤੇ ਅੰਡਰਲਾਈੰਗ ਫਾਈਲ ਸਿਸਟਮ ਅਤੇ ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ ਫਾਈਲਾਂ ਵਿੱਚ ਪ੍ਰਤੱਖ ਤਬਦੀਲੀਆਂ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ro-tootf ਜਦੋਂ ਕਿ ਇੱਕ ਬੰਨ੍ਹਣਯੋਗ ਮਾਊਂਟ ਨਵੇਂ ਨੂੰ ਖਾਲੀ ਕਰ ਸਕਦਾ ਹੈ tmpfs ਵਿੱਚ ਲਿਖਣਯੋਗ ਫੋਲਡਰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ro-rootfs ਤਰੀਕੇ. ਜਦਕਿ overlayfs ਇਹ ਸਹੀ ਹੈ (proper) ਫਾਈਲ ਸਿਸਟਮ ਕਿਸਮ, ਬਾਈਂਡੇਬਲ ਮਾਊਂਟ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ VFS ਨੇਮਸਪੇਸ.

ਓਵਰਲੇਅ ਅਤੇ ਲਿੰਕੇਬਲ ਮਾਉਂਟ ਦੇ ਵਰਣਨ ਦੇ ਅਧਾਰ ਤੇ, ਕੋਈ ਵੀ ਹੈਰਾਨ ਨਹੀਂ ਹੁੰਦਾ ਲੀਨਕਸ ਕੰਟੇਨਰ ਉਹ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਆਓ ਦੇਖੀਏ ਕਿ ਜਦੋਂ ਅਸੀਂ ਵਰਤਦੇ ਹਾਂ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ systemd-nspawn ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੰਟੇਨਰ ਨੂੰ ਚਲਾਉਣ ਲਈ mountsnoop ਤੱਕ bcc.

ਚੁਣੌਤੀ system-nspawn ਚੱਲਦੇ ਸਮੇਂ ਕੰਟੇਨਰ ਚਾਲੂ ਕਰਦਾ ਹੈ mountsnoop.py.

ਆਓ ਦੇਖੀਏ ਕੀ ਹੋਇਆ:

ਚਲਾਓ mountsnoop ਜਦੋਂ ਕੰਟੇਨਰ "ਬੂਟਿੰਗ" ਹੁੰਦਾ ਹੈ ਤਾਂ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੰਟੇਨਰ ਦਾ ਰਨਟਾਈਮ ਲਿੰਕ ਕੀਤੇ ਜਾ ਰਹੇ ਮਾਊਂਟ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦਾ ਹੈ (ਸਿਰਫ਼ ਲੰਬੀ ਆਉਟਪੁੱਟ ਦੀ ਸ਼ੁਰੂਆਤ ਦਿਖਾਈ ਜਾਂਦੀ ਹੈ)।

ਇਹ ਇਸ ਲਈ ਹੈ systemd-nspawn ਵਿੱਚ ਚੁਣੀਆਂ ਗਈਆਂ ਫਾਈਲਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ procfs и sysfs ਇਸ ਦੇ ਮਾਰਗ ਵਜੋਂ ਕੰਟੇਨਰ ਨੂੰ ਹੋਸਟ ਕਰੋ rootfs. ਇਲਾਵਾ MS_BIND ਫਲੈਗ ਜੋ ਬਾਈਡਿੰਗ ਮਾਊਂਟ ਨੂੰ ਸੈਟ ਅਪ ਕਰਦਾ ਹੈ, ਮਾਊਂਟ 'ਤੇ ਕੁਝ ਹੋਰ ਫਲੈਗ ਹੋਸਟ ਅਤੇ ਕੰਟੇਨਰ ਨਾਮ-ਸਥਾਨਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਵਿਚਕਾਰ ਸਬੰਧ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਲਿੰਕ ਕੀਤਾ ਮਾਊਂਟ ਜਾਂ ਤਾਂ ਇਸ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ /proc и /sys ਕੰਟੇਨਰ ਵਿੱਚ, ਜਾਂ ਕਾਲ ਦੇ ਆਧਾਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਲੁਕਾਓ।

ਸਿੱਟਾ

ਲੀਨਕਸ ਦੇ ਅੰਦਰੂਨੀ ਕੰਮਕਾਜ ਨੂੰ ਸਮਝਣਾ ਇੱਕ ਅਸੰਭਵ ਕੰਮ ਵਾਂਗ ਜਾਪਦਾ ਹੈ, ਕਿਉਂਕਿ ਕਰਨਲ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕੋਡ ਦੀ ਇੱਕ ਵੱਡੀ ਮਾਤਰਾ ਰੱਖਦਾ ਹੈ, ਲੀਨਕਸ ਉਪਭੋਗਤਾ ਸਪੇਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਸੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਸਿਸਟਮ ਕਾਲ ਇੰਟਰਫੇਸ ਨੂੰ ਛੱਡ ਕੇ ਜਿਵੇਂ ਕਿ glibc. ਤਰੱਕੀ ਕਰਨ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ ਇੱਕ ਕਰਨਲ ਸਬ-ਸਿਸਟਮ ਦੇ ਸਰੋਤ ਕੋਡ ਨੂੰ ਪੜ੍ਹਨਾ, ਸਿਸਟਮ ਕਾਲਾਂ ਅਤੇ ਉਪਭੋਗਤਾ-ਸਪੇਸ ਸਿਰਲੇਖਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਮੁੱਖ ਅੰਦਰੂਨੀ ਕਰਨਲ ਇੰਟਰਫੇਸ, ਜਿਵੇਂ ਕਿ ਟੇਬਲ ਨੂੰ ਸਮਝਣ 'ਤੇ ਜ਼ੋਰ ਦੇ ਨਾਲ। file_operations. ਫਾਈਲ ਓਪਰੇਸ਼ਨ "ਹਰ ਚੀਜ਼ ਇੱਕ ਫਾਈਲ ਹੈ" ਸਿਧਾਂਤ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਮਜ਼ੇਦਾਰ ਬਣਾਉਂਦੇ ਹਨ। ਸਿਖਰ-ਪੱਧਰ ਦੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ C ਕਰਨਲ ਸਰੋਤ ਫਾਈਲਾਂ fs/ ਵਰਚੁਅਲ ਫਾਈਲ ਸਿਸਟਮਾਂ ਦਾ ਲਾਗੂਕਰਨ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਰੈਪਰ ਲੇਅਰ ਹੈ ਜੋ ਪ੍ਰਸਿੱਧ ਫਾਈਲ ਸਿਸਟਮਾਂ ਅਤੇ ਸਟੋਰੇਜ਼ ਡਿਵਾਈਸਾਂ ਵਿਚਕਾਰ ਵਿਆਪਕ ਅਤੇ ਮੁਕਾਬਲਤਨ ਸਧਾਰਨ ਅਨੁਕੂਲਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਲੀਨਕਸ ਨੇਮਸਪੇਸ ਰਾਹੀਂ ਲਿੰਕ ਕਰਨਾ ਅਤੇ ਓਵਰਲੇਅ ਮਾਊਂਟ ਕਰਨਾ VFS ਦਾ ਜਾਦੂ ਹੈ ਜੋ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੇ ਕੰਟੇਨਰਾਂ ਅਤੇ ਰੂਟ ਫਾਈਲ ਸਿਸਟਮ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ। ਸਰੋਤ ਕੋਡ, eBPF ਕੋਰ ਟੂਲ ਅਤੇ ਇਸਦੇ ਇੰਟਰਫੇਸ ਦੀ ਜਾਂਚ ਦੇ ਨਾਲ ਮਿਲਾ ਕੇ bcc
ਮੂਲ ਖੋਜ ਨੂੰ ਪਹਿਲਾਂ ਨਾਲੋਂ ਆਸਾਨ ਬਣਾਉਣਾ।

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

ਪਹਿਲਾ ਭਾਗ।

ਸਰੋਤ: www.habr.com