লিনাক্সে ভার্চুয়াল ফাইল সিস্টেম: কেন তাদের প্রয়োজন এবং তারা কীভাবে কাজ করে? অংশ 2

সবাইকে হ্যালো, আমরা আপনাদের সাথে "লিনাক্সে ভার্চুয়াল ফাইল সিস্টেম: কেন প্রয়োজন এবং কিভাবে কাজ করে?" আপনি প্রথম অংশ পড়তে পারেন এখানে. আসুন আমরা আপনাকে মনে করিয়ে দিই যে প্রকাশনার এই সিরিজটি কোর্সে একটি নতুন স্ট্রিম চালু করার সাথে সামঞ্জস্যপূর্ণ। "লিনাক্স প্রশাসক", যা খুব শীঘ্রই শুরু হবে।

কীভাবে ইবিপিএফ এবং বিসিসি টুল ব্যবহার করে ভিএফএস নিরীক্ষণ করবেন

কার্নেল কিভাবে ফাইলে কাজ করে তা বোঝার সবচেয়ে সহজ উপায় sysfs এটি অনুশীলনে দেখা, এবং ARM64 দেখার সবচেয়ে সহজ উপায় হল eBPF ব্যবহার করা। eBPF (বার্কলে প্যাকেট ফিল্টার সংক্ষিপ্ত) একটি ভার্চুয়াল মেশিন নিয়ে গঠিত মূল, যা সুবিধাপ্রাপ্ত ব্যবহারকারীরা অনুরোধ করতে পারেন (query) কমান্ড লাইন থেকে। কার্নেল সূত্র পাঠককে বলে যে কার্নেল কী করতে পারে; একটি লোড করা সিস্টেমে eBPF সরঞ্জামগুলি চালানোর ফলে কার্নেল আসলে কী করছে তা দেখায়।

সৌভাগ্যবশত, eBPF ব্যবহার শুরু করা টুলের সাহায্যে বেশ সহজ BCC, যা সাধারণ বিতরণ থেকে প্যাকেজ হিসাবে উপলব্ধ লিনাক্স এবং বিস্তারিত নথিভুক্ত বার্নার্ড গ্রেগ. টুলস bcc সি কোডের ছোট সন্নিবেশ সহ পাইথন স্ক্রিপ্টগুলি, যার অর্থ উভয় ভাষার সাথে পরিচিত যে কেউ সহজেই তাদের পরিবর্তন করতে পারে। ভিতরে bcc/tools এখানে 80টি পাইথন স্ক্রিপ্ট রয়েছে, যার অর্থ সম্ভবত একজন বিকাশকারী বা সিস্টেম অ্যাডমিনিস্ট্রেটর সমস্যা সমাধানের জন্য উপযুক্ত কিছু বেছে নিতে সক্ষম হবেন।
চলমান সিস্টেমে VFSগুলি কী কাজ করে সে সম্পর্কে অন্তত একটি অতিমাত্রায় ধারণা পেতে চেষ্টা করুন vfscount বা vfsstat. এই দেখাবে, চলুন বলা যাক, যে কয়েক ডজন কল vfs_open() এবং "তার বন্ধুরা" আক্ষরিকভাবে প্রতি সেকেন্ডে ঘটে।

vfsstat.py সি কোড সন্নিবেশ সহ একটি পাইথন স্ক্রিপ্ট যা কেবলমাত্র 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 পাঠ্য সংকলন করতে ব্যর্থ হয়েছে।" বিকাশকারীরা যারা সি এবং পাইথনের সাথে পরিচিত তারা টুলগুলি খুঁজে পাবেন bcc প্রসারিত এবং পরিবর্তন করা সহজ।

যখন USB ড্রাইভ ঢোকানো হয়, কার্নেল ব্যাকট্রেস দেখাবে যে PID 7711 একটি থ্রেড kworkerযা ফাইল তৈরি করেছে «events» в sysfs. তদনুসারে, থেকে কল sysfs_remove_files() দেখাবে যে ড্রাইভটি সরানোর ফলে ফাইলটি মুছে ফেলা হয়েছে events, যা রেফারেন্স গণনার সাধারণ ধারণার সাথে মিলে যায়। একই সময়ে, দেখা sysfs_create_link () eBPF এর সাথে USB ড্রাইভ ঢোকানোর সময় দেখাবে যে কমপক্ষে 48টি প্রতীকী লিঙ্ক তৈরি করা হয়েছে।

তাই ঘটনা ফাইল বিন্দু কি? ব্যবহার cscope অনুসন্ধানের জন্য __ডিভাইস_অ্যাড_ডিস্ক(), এটা কি কারণ দেখায় 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) ফাইল সিস্টেম টাইপ, বাইন্ডেবল মাউন্ট প্রয়োগ করা হয় ভিএফএস নামস্থান.

ওভারলে এবং লিঙ্কযোগ্য মাউন্টের বর্ণনার উপর ভিত্তি করে, কেউ অবাক হয় না লিনাক্স পাত্রে তারা সক্রিয়ভাবে ব্যবহৃত হয়। দেখা যাক আমরা ব্যবহার করলে কি হয় 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