এডুয়ার্ড শিশকিনের সাথে দ্বিতীয় সাক্ষাৎকার, Reiser4 FS এর বিকাশকারী

Reiser4 ফাইল সিস্টেমের বিকাশকারী এডুয়ার্ড শিশকিনের সাথে দ্বিতীয় সাক্ষাৎকার প্রকাশিত হয়েছে।

শুরু করতে, অনুগ্রহ করে পাঠকদের মনে করিয়ে দিন আপনি কোথায় এবং কার জন্য কাজ করেন৷

আমি Huawei Technologies, German Research Center-এ একজন প্রধান স্টোরেজ আর্কিটেক্ট হিসেবে কাজ করি। ভার্চুয়ালাইজেশন বিভাগে আমি ডেটা স্টোরেজের বিভিন্ন দিক নিয়ে কাজ করি। আমার কার্যকলাপ একটি নির্দিষ্ট অপারেটিং সিস্টেমের সাথে সম্পর্কিত নয়.

আপনি কি বর্তমানে প্রধান কার্নেল শাখায় প্রতিশ্রুতিবদ্ধ?

খুব কমই, এবং শুধুমাত্র যদি আমার নিয়োগকর্তার প্রয়োজন হয়। শেষবার প্রায় তিন বছর আগে, আমি 9p প্রোটোকল ব্যবহার করে হোস্টে শেয়ার করা স্টোরেজের জন্য থ্রুপুট বাড়ানোর জন্য প্যাচ পাঠিয়েছিলাম (এই ব্যবসার অন্য নাম VirtFS)। এখানে একটি গুরুত্বপূর্ণ নোট করা উচিত: যদিও আমি লিনাক্সের সাথে দীর্ঘদিন ধরে কাজ করছি, আমি কখনই এটির অনুরাগী ছিলাম না, অর্থাৎ, আমি অন্য সবকিছুর মতো "সমভাবে শ্বাস নিই"। বিশেষ করে, আমি যদি কোনো ত্রুটি লক্ষ্য করি, তবে আমি তা একবারে নির্দেশ করতে পারি। এবং যাতে আপনি তখন কাউকে অনুসরণ করতে পারেন এবং তাদের বোঝাতে পারেন - এটি ঘটবে না।

আমার মনে আছে শেষবার, দশ বছর আগে, আপনি কার্নেল উন্নয়ন শৈলীর বেশ সমালোচনা করেছিলেন। আপনার (বা সম্ভবত কর্পোরেট) দৃষ্টিকোণ থেকে, কিছু কি পরিবর্তিত হয়েছে, সম্প্রদায় কি আরও প্রতিক্রিয়াশীল হয়ে উঠেছে নাকি? যদি না হয়, আপনি কে দায়ী মনে করেন?

আমি ভালোর জন্য কোন পরিবর্তন দেখিনি। সম্প্রদায়ের প্রধান সমস্যা হল রাজনৈতিক প্রযুক্তি, ব্যক্তিগত সম্পর্ক, সংখ্যাগরিষ্ঠ মতামত, পপুলিজম, "অভ্যন্তরীণ কণ্ঠস্বর", পচা আপস, বিজ্ঞান ছাড়া অন্য কিছুর সাথে বিজ্ঞানের প্রতিস্থাপন। কম্পিউটার বিজ্ঞান, যে যাই বলুক না কেন, প্রথম এবং সর্বাগ্রে একটি সঠিক বিজ্ঞান। এবং যদি কেউ 2x2-এর জন্য তাদের নিজস্ব মান ঘোষণা করা শুরু করে, 4 থেকে ভিন্ন, "লিনাক্স উপায়" পতাকার নীচে বা অন্য কোনও পতাকার নীচে, তাহলে এটি ক্ষতি ছাড়া অন্য কিছু আনতে পারে না।

সমস্ত সমস্যা প্রাথমিকভাবে যারা সিদ্ধান্ত নেয় তাদের অযোগ্যতা এবং শিক্ষার অভাবের কারণে। যদি একজন ম্যানেজার অযোগ্য হন, তবে তিনি একটি উদ্দেশ্যমূলক, পর্যাপ্ত সিদ্ধান্ত নিতে সক্ষম হন না। যদি সে অসংস্কৃতও হয়, তাহলে সে একজন দক্ষ বিশেষজ্ঞ খুঁজে পায় না যে তাকে সঠিক পরামর্শ দেবে। একটি উচ্চ সম্ভাবনার সাথে, পছন্দটি একজন স্ক্যামারের উপর পড়বে যে "আপাতদৃষ্টিতে সঠিক জিনিস" বলে। একটি দুর্নীতিগ্রস্ত পরিবেশ সবসময় অযোগ্য একা নেতাদের চারপাশে গড়ে ওঠে। তদুপরি, ইতিহাস এই বিষয়ে কোন ব্যতিক্রম জানে না, এবং সম্প্রদায় এটির স্পষ্ট নিশ্চিতকরণ।

আপনি কিভাবে Btrfs উন্নয়নে অগ্রগতি মূল্যায়ন করবেন? এই এফএস কি শৈশব রোগ থেকে মুক্তি পেয়েছে? আপনি কীভাবে এটিকে নিজের জন্য অবস্থান করবেন - একটি FS হিসাবে "বাড়ির জন্য" বা কর্পোরেট ব্যবহারের জন্যও?

আমি এটা থেকে পরিত্রাণ পাইনি. 11 বছর আগে আমি যা উল্লেখ করেছি তা আজও প্রাসঙ্গিক। Btrf-এর সমস্যাগুলির মধ্যে একটি যা এটিকে গুরুতর প্রয়োজনের জন্য অনুপযুক্ত করে তোলে তা হল ফাঁকা স্থানের সমস্যা। আমি এমনও কথা বলছি না যে ব্যবহারকারীকে এমন পরিস্থিতিতে একটি নতুন ডিস্কের জন্য স্টোরে দৌড়াতে বলা হয় যেখানে অন্য কোনও FS পার্টিশনে প্রচুর ফাঁকা জায়গা দেখায়। খালি জায়গার অভাবের কারণে একটি লজিক্যাল ভলিউমে একটি অপারেশন সম্পূর্ণ করতে অক্ষমতাও সবচেয়ে খারাপ জিনিস নয়। সবচেয়ে খারাপ বিষয় হল যে একটি সুবিধাবঞ্চিত ব্যবহারকারী প্রায় সবসময়ই, যেকোনো ডিস্ক কোটা বাইপাস করে, মোটামুটি অল্প সময়ের মধ্যে সবাইকে ফাঁকা স্থান থেকে বঞ্চিত করতে পারে।

এটি এই মত দেখাচ্ছে (লিনাক্স কার্নেল 5.12 এর জন্য পরীক্ষা করা হয়েছে)। একটি নতুন ইনস্টল করা সিস্টেমে একটি স্ক্রিপ্ট চালু করা হয়, যা একটি লুপে হোম ডিরেক্টরিতে নির্দিষ্ট নামের ফাইল তৈরি করে, নির্দিষ্ট অফসেটে তাদের কাছে ডেটা লেখে এবং তারপরে এই ফাইলগুলি মুছে দেয়। এই স্ক্রিপ্ট চালানোর এক মিনিটের পরে, অস্বাভাবিক কিছুই ঘটে না। পাঁচ মিনিট পরে, পার্টিশনে দখলকৃত স্থানের অংশ সামান্য বৃদ্ধি পায়। দুই থেকে তিন ঘন্টা পরে এটি 50% ছুঁয়েছে (15% এর প্রাথমিক মান সহ)। এবং পাঁচ বা ছয় ঘন্টা কাজ করার পরে, "পার্টিশনে কোন ফাঁকা জায়গা নেই" ত্রুটির সাথে স্ক্রিপ্টটি ক্র্যাশ হয়ে যায়। এর পরে, আপনি আর আপনার পার্টিশনে একটি 4K ফাইলও লিখতে পারবেন না।

একটি আকর্ষণীয় পরিস্থিতি ঘটে: আপনি পার্টিশনে কিছু না লিখে শেষ করেছেন এবং সমস্ত ফাঁকা স্থান (প্রায় 85%) কোথাও অদৃশ্য হয়ে গেছে। এই ধরনের আক্রমণের বিষয় একটি বিভাগের বিশ্লেষণ শুধুমাত্র একটি আইটেম (একটি কী দিয়ে সজ্জিত একটি বস্তু), আকারের বেশ কয়েকটি বাইট ধারণকারী অনেক ট্রি নোড প্রকাশ করবে। অর্থাৎ, যে বিষয়বস্তু পূর্বে ডিস্কের 15% স্থান দখল করেছিল তা পুরো পার্টিশনে সমানভাবে "গন্ধযুক্ত" হয়ে গেছে যাতে একটি নতুন ফাইল লেখার কোথাও নেই, কারণ এর কী বিদ্যমান সমস্ত ফাইলের চেয়ে বড় এবং বিনামূল্যে পার্টিশনের ব্লক ফুরিয়ে গেছে।

তদুপরি, এটি সমস্ত প্রাথমিক Btrfs কনফিগারেশনে ইতিমধ্যেই ঘটে থাকে (কোনও স্ন্যাপশট, সাবভলিউম ইত্যাদি ছাড়াই), এবং আপনি কীভাবে সেই FS-এ ফাইল বডিগুলিকে সংরক্ষণ করার সিদ্ধান্ত নেন তা বিবেচ্য নয় (একটি গাছে "টুকরা" হিসাবে, বা বিস্তৃতি হিসাবে বিন্যাসহীন ব্লকের) - শেষ ফলাফল একই হবে।

আপনি অন্য আপস্ট্রিম ফাইল সিস্টেমকে এই ধরনের আক্রমণের শিকার হতে পারবেন না (তারা আপনাকে যাই বলুক না কেন)। আমি অনেক আগেই সমস্যার কারণ ব্যাখ্যা করেছি: এটি Btrfs-এ B-tree ধারণার সম্পূর্ণ বিকৃতি, যা এটিকে স্বতঃস্ফূর্তভাবে বা ইচ্ছাকৃতভাবে অবক্ষয় করা সম্ভব করে তোলে। বিশেষ করে, নির্দিষ্ট লোডের অধীনে, আপনার ফাইল সিস্টেমটি বাইরের সাহায্য ছাড়াই তার নিজের কাজ করার সময় ক্রমাগত "বিচ্ছিন্ন" হয়ে যাবে। এটা স্পষ্ট যে সমস্ত ধরণের "প্রেসিং" ব্যাকগ্রাউন্ড প্রসেসগুলি শুধুমাত্র ব্যক্তিগত ডেস্কটপে দিনটিকে বাঁচাবে৷

সমষ্টিগত সার্ভারে, একজন আক্রমণকারী সর্বদা তাদের থেকে "আগে যেতে" সক্ষম হবে। সিস্টেম অ্যাডমিনিস্ট্রেটর এমনকি ঠিক কে তাকে ধমক দিয়েছে তা নির্ধারণ করতে সক্ষম হবে না। Btrfs-এ এই সমস্যাটি সমাধান করার দ্রুততম উপায় হল একটি নিয়মিত বি-ট্রির গঠন পুনরুদ্ধার করা, যেমন ডিস্ক বিন্যাস পুনরায় ডিজাইন করা এবং Btrfs কোডের উল্লেখযোগ্য অংশ পুনরায় লেখা। এটি ডিবাগিং সহ 8-10 বছর সময় নেবে, তবে শর্ত থাকে যে বিকাশকারীরা প্রাসঙ্গিক অ্যালগরিদম এবং ডেটা স্ট্রাকচারের মূল নিবন্ধগুলি কঠোরভাবে অনুসরণ করে এবং "ভাঙা ফোন" গেমটি না খেলে, যেমনটি "লিনাক্সে প্রথাগত (এবং উত্সাহিত)। পথ"।

এখানে আমাদের ডেভেলপারদের এই সব বোঝার জন্য প্রয়োজনীয় সময় যোগ করতে হবে। এটি যেখানে এটি আরও কঠিন হয়। যাই হোক, 10 বছর তাদের বোঝার জন্য যথেষ্ট ছিল না। ঠিক আছে, ততক্ষণ পর্যন্ত আপনি একটি অলৌকিক ঘটনার আশা করতে পারবেন না। এটি একটি মাউন্টিং বিকল্পের আকারে ঘটবে না "যেটি সম্পর্কে আপনি এবং আমি জানতাম না," বা একটি প্যাচ আকারে যা প্রস্তুত করা "শুধু ব্যবসার বিষয়"। এই ধরনের প্রতিটি তাড়াহুড়ার জন্য আমি অবক্ষয়ের একটি নতুন দৃশ্যকল্প উপস্থাপন করব। বি-বৃক্ষ আমার প্রিয় বিষয়গুলির মধ্যে একটি, এবং আমি অবশ্যই বলব যে এই কাঠামোগুলি নিজেদের সাথে স্বাধীনতা সহ্য করে না!

আমি কীভাবে নিজের জন্য Btrf-এর অবস্থান করব? এমন কিছু যাকে একেবারেই ফাইল সিস্টেম বলা যায় না, ব্যবহার করা যাক। কারণ, সংজ্ঞা অনুসারে, FS হল একটি OS সাবসিস্টেম যা "ডিস্ক স্পেস" রিসোর্সের কার্যকর ব্যবস্থাপনার জন্য দায়ী, যা আমরা Btrfs-এর ক্ষেত্রে দেখতে পাই না। ঠিক আছে, কল্পনা করুন যে আপনি একটি ঘড়ি কিনতে দোকানে এসেছেন যাতে কাজের জন্য দেরি না হয় এবং একটি ঘড়ির পরিবর্তে তারা আপনাকে সর্বাধিক 30 মিনিটের জন্য টাইমার সহ একটি বৈদ্যুতিক গ্রিল বিক্রি করে। সুতরাং, Btrfs এর পরিস্থিতি আরও খারাপ।

মেইলিং তালিকার মাধ্যমে খুঁজছি, আমি প্রায়ই বিবৃতিটি দেখতে পাই যে ড্রাইভের সস্তাতার কারণে কার্যকরভাবে ডিস্কের স্থান পরিচালনা করা আর প্রাসঙ্গিক নয়। এটা সম্পূর্ণ ফালতু কথা। একটি কার্যকর ডিস্ক স্পেস ম্যানেজার ছাড়া, OS দুর্বল এবং অব্যবহারযোগ্য হয়ে যাবে। আপনার মেশিনে ডিস্কের ক্ষমতা নির্বিশেষে।

আমি RHEL-এ Btrfs সমর্থন বন্ধ করার বিষয়ে মন্তব্য করতে চাই।

এখানে মন্তব্য করার বিশেষ কিছু নেই, সবকিছু খুব পরিষ্কার। তাদের এটি একটি "প্রযুক্তি পূর্বরূপ" হিসাবেও ছিল। সুতরাং, আমি এই খুব "প্রিভিউ" এর মধ্য দিয়ে যাইনি। এই লেবেলটি চিরতরে ঝুলতে দেবেন না! কিন্তু তারা সম্পূর্ণ সমর্থন সহ একটি ত্রুটিপূর্ণ বাই-ডিজাইন পণ্য চালু করতে পারে না। RHEL হল একটি এন্টারপ্রাইজ, অর্থাৎ নির্ধারিত পণ্য-অর্থ সম্পর্ক। Red Hat ব্যবহারকারীদেরকে Btrfs মেইলিং তালিকার মত ধমক দিতে পারে না। শুধু পরিস্থিতিটি কল্পনা করুন: একজন ক্লায়েন্ট যে তার কষ্টার্জিত অর্থ ডিস্কের জন্য এবং আপনাকে সহায়তার জন্য প্রদান করেছে, সে বুঝতে চায় তার ডিস্কের স্থান কোথায় গেছে সে কিছু না লেখার পরে। এ বিষয়ে আপনি তাকে কী জবাব দেবেন?

আরও Red Hat এর ক্লায়েন্টদের মধ্যে সুপরিচিত বড় ব্যাঙ্ক এবং এক্সচেঞ্জ অন্তর্ভুক্ত। Btrfs-এ উল্লিখিত দুর্বলতার উপর ভিত্তি করে যদি তারা DoS আক্রমণের শিকার হয় তবে কী হবে তা কল্পনা করুন। এর জন্য কে দায়ী বলে আপনি মনে করেন? যারা জিপিএল লাইসেন্সের লাইনের দিকে আঙুল তুলতে চলেছেন, যেখানে লেখা আছে যে লেখক কোনও কিছুর জন্য দায়ী নয়, আমি অবিলম্বে বলব: "এটি লুকিয়ে রাখুন!" রেড হ্যাট উত্তর দেবে, এবং এমনভাবে যে এটি যথেষ্ট বলে মনে হবে না! কিন্তু আমি জানি যে রেড হ্যাট এই ধরনের সমস্যার সম্মুখীন হচ্ছে না, তাদের বিশেষভাবে শক্তিশালী QA ইঞ্জিনিয়ারদের দল যাদের সাথে আমার সময়ে ঘনিষ্ঠভাবে কাজ করার সুযোগ পেয়েছি।

কেন কিছু কোম্পানি তাদের এন্টারপ্রাইজ পণ্যগুলিতে Btrf-কে সমর্থন করে চলেছে?

অনুগ্রহ করে মনে রাখবেন যে পণ্যের নামের উপসর্গ "এন্টারপ্রাইজ" এর অর্থ খুব বেশি নয়৷ এন্টারপ্রাইজ হল ক্লায়েন্টের সাথে চুক্তিগত সম্পর্কের মধ্যে এমবেড করা দায়িত্বের একটি পরিমাপ। আমি GNU/Linux-এর উপর ভিত্তি করে শুধুমাত্র একটি এন্টারপ্রাইজ সম্পর্কে জানি - RHEL। অন্য সবকিছু, আমার দৃষ্টিকোণ থেকে, শুধুমাত্র একটি এন্টারপ্রাইজ হিসাবে উপস্থাপিত হয়, কিন্তু একটি নয়। এবং অবশেষে, যদি কিছুর চাহিদা থাকে তবে সর্বদা একটি সরবরাহ থাকবে (আমাদের ক্ষেত্রে, এটি উল্লিখিত "সমর্থন")। একেবারে সবকিছু জন্য চাহিদা আছে, সহ. এবং অব্যবহারযোগ্য সফটওয়্যার। এই ধরনের চাহিদা কীভাবে তৈরি হয় এবং কারা এটিকে ইন্ধন দেয় তা অন্য বিষয়।

সুতরাং, ফেসবুকের সার্ভারে Btrfs মোতায়েন করার গুজব হওয়ার পরে আমি কোন সিদ্ধান্তে পৌঁছাব না। তদুপরি, আমি উপরের কারণগুলির জন্য সেই সার্ভারগুলির ঠিকানাগুলি সাবধানে গোপন রাখার পরামর্শ দেব।

কেন ইদানীং XFS কোড পরিষ্কার করার জন্য এত প্রচেষ্টা করা হয়েছে? সর্বোপরি, প্রাথমিকভাবে এটি একটি তৃতীয় পক্ষের ফাইল সিস্টেম, এবং ext4 দীর্ঘ সময়ের জন্য স্থিতিশীল এবং পূর্ববর্তী সমান স্থিতিশীল সংস্করণ থেকে ধারাবাহিকতা রয়েছে। XFS-এ Red Hat-এর কী আগ্রহ আছে? উদ্দেশ্যের অনুরূপ দুটি ফাইল সিস্টেম সক্রিয়ভাবে বিকাশ করা কি অর্থপূর্ণ - ext4 এবং XFS?

এটা কি অনুপ্রাণিত করেছে মনে নেই। এটা খুবই সম্ভব যে উদ্যোগটি Red Hat ক্লায়েন্টদের কাছ থেকে এসেছে। আমার মনে আছে যে এই ধরণের গবেষণা করা হয়েছিল: আপস্ট্রিম থেকে কিছু ফাইল সিস্টেমে, নতুন প্রজন্মের হাই-এন্ড ড্রাইভে বিশাল সংখ্যক বস্তু তৈরি করা হয়েছিল। ফলাফল অনুসারে, এক্সএফএস ext4 এর চেয়ে ভাল আচরণ করেছে। তাই তারা এটিকে সবচেয়ে প্রতিশ্রুতিশীল হিসাবে প্রচার করতে শুরু করে। যাই হোক না কেন, আমি এখানে উত্তেজনাপূর্ণ কিছু খুঁজব না।

আমার জন্য, এটা যেন তারা সাবান দিয়ে একটি awl প্রতিস্থাপন করেছে। ext4 এবং XFS ডেভেলপ করার কোন মানে নেই। উভয় সমান্তরাল এবং তাদের যে কোনো থেকে চয়ন করুন. এর থেকে ভালো কিছু আসবে না। যদিও, প্রকৃতিতে প্রায়শই এমন পরিস্থিতি থাকে যখন বৃদ্ধির প্রচুর সম্ভাবনা থাকে, তবে বৃদ্ধির কোনও জায়গা নেই। এই ক্ষেত্রে, বিভিন্ন উদ্ভট কুৎসিত নতুন বৃদ্ধি দেখা দেয়, যার দিকে সবাই আঙুল নির্দেশ করে ("ওহ, দেখুন, আপনি এই জীবনে কী দেখতে পাবেন না!")।

আপনি কি মনে করেন যে ext4, F2FS (Btrfs-এ RAID উল্লেখ না করার মতো) এনক্রিপশন ফাংশনগুলির আবির্ভাবের সাথে স্তর লঙ্ঘনের সমস্যাটি (একটি নেতিবাচক অর্থে) নিষ্পত্তি করা হয়েছে?

সাধারণভাবে, কোন স্তরের পরিচয় এবং তাদের অলঙ্ঘন সম্পর্কে সিদ্ধান্ত নেওয়া সাধারণত নীতির বিষয়, এবং আমি এখানে কোনও মন্তব্য করার দায়িত্ব নিই না। স্তর লঙ্ঘনের উদ্দেশ্যমূলক দিকগুলি কারও কাছে খুব কমই আগ্রহী, তবে আমরা তাদের মধ্যে কয়েকটিকে "উপর থেকে" লঙ্ঘনের উদাহরণ ব্যবহার করে বিবেচনা করতে পারি, যেমন, ব্লক স্তরে ইতিমধ্যে বিদ্যমান কার্যকারিতার FS-এ বাস্তবায়ন। এই ধরনের একটি "লঙ্ঘন" শুধুমাত্র বিরল ব্যতিক্রমগুলির সাথে ন্যায়সঙ্গত। এই ধরনের প্রতিটি ক্ষেত্রে, আপনাকে প্রথমে দুটি জিনিস প্রমাণ করতে হবে: এটি সত্যিই প্রয়োজন, এবং এটি করার ফলে সিস্টেমের নকশা ক্ষতিগ্রস্ত হবে না।

উদাহরণস্বরূপ, মিররিং, যা ঐতিহ্যগতভাবে ব্লক স্তরের জন্য একটি ক্রিয়াকলাপ, ফাইল সিস্টেম স্তরে প্রয়োগ করা অর্থপূর্ণ। বিভিন্ন কারণে। উদাহরণস্বরূপ, ডিস্ক ড্রাইভে "নীরব" ডেটা দুর্নীতি (বিট পচা) ঘটে। এটি যখন ডিভাইসটি সঠিকভাবে কাজ করছে, কিন্তু ব্লক ডেটা অপ্রত্যাশিতভাবে দূরবর্তী কোয়াসার দ্বারা নির্গত কঠিন গামা কোয়ান্টামের প্রভাবে ক্ষতিগ্রস্ত হয়। সবচেয়ে খারাপ বিষয় হল যদি এই ব্লকটি একটি FS সিস্টেম ব্লক (সুপারব্লক, বিটম্যাপ ব্লক, স্টোরেজ ট্রি নোড, ইত্যাদি) হয়ে ওঠে, কারণ এটি অবশ্যই একটি কার্নেল প্যানিকের দিকে নিয়ে যাবে।

অনুগ্রহ করে মনে রাখবেন যে ব্লক স্তর (তথাকথিত RAID 1) দ্বারা প্রস্তাবিত আয়না আপনাকে এই সমস্যা থেকে রক্ষা করবে না। ভাল, সত্যিই: কেউ চেকসাম পরীক্ষা করা উচিত এবং ব্যর্থতার ক্ষেত্রে প্রতিরূপ পড়া উচিত? উপরন্তু, এটি শুধুমাত্র সবকিছু নয়, শুধুমাত্র মেটাডেটা মিরর করার জন্য বোধগম্য হয়। কিছু গুরুত্বপূর্ণ তথ্য (উদাহরণস্বরূপ, সমালোচনামূলক অ্যাপ্লিকেশনের এক্সিকিউটেবল ফাইল) মেটাডেটা হিসাবে সংরক্ষণ করা যেতে পারে। এই ক্ষেত্রে, তারা নিরাপত্তার একই গ্যারান্টি পায়। অবশিষ্ট ডেটার সুরক্ষা অন্যান্য সাবসিস্টেমের (সম্ভবত এমনকি ব্যবহারকারীর অ্যাপ্লিকেশনগুলিও) অর্পণ করা বোধগম্য - আমরা এর জন্য সমস্ত প্রয়োজনীয় শর্ত সরবরাহ করেছি।

এই জাতীয় "অর্থনৈতিক" আয়নাগুলির অস্তিত্বের অধিকার রয়েছে এবং সেগুলি কেবল ফাইল সিস্টেম স্তরে কার্যকরভাবে সংগঠিত হতে পারে। অন্যথায়, লেয়ারিং লঙ্ঘন কিছু মাইক্রোস্কোপিক সুবিধার জন্য ডুপ্লিকেট কোড সহ একটি সাবসিস্টেমকে বিশৃঙ্খল করছে। এর একটি আকর্ষণীয় উদাহরণ হল FS ব্যবহার করে RAID-5 বাস্তবায়ন। এই ধরনের সমাধান (ফাইল সিস্টেমে নিজস্ব RAID/LVM) স্থাপত্যের দিক থেকে পরবর্তীটিকে মেরে ফেলে। এখানে এটাও উল্লেখ করা উচিত যে লেয়ারিং লঙ্ঘন বিভিন্ন ধরণের বিপণন স্ক্যামারদের দ্বারা "প্রবাহিত হয়"। কোনো ধারণার অনুপস্থিতিতে, পার্শ্ববর্তী স্তরে দীর্ঘকাল ধরে কার্যকর করা কার্যকারিতা সাবসিস্টেমগুলিতে যুক্ত করা হয়, এটি একটি নতুন অত্যন্ত দরকারী বৈশিষ্ট্য হিসাবে উপস্থাপন করা হয় এবং সক্রিয়ভাবে ধাক্কা দেওয়া হয়।

Reiser4 "নীচ থেকে" স্তর লঙ্ঘনের জন্য অভিযুক্ত করা হয়েছিল। এই সত্যের উপর ভিত্তি করে যে ফাইল সিস্টেমটি অন্য সকলের মতো একচেটিয়া নয়, কিন্তু মডুলার, একটি অপ্রমাণিত অনুমান করা হয়েছিল যে এটি উপরের স্তরের (ভিএফএস) যা করা উচিত তা করে।

ReiserFS v3.6 এবং উদাহরণস্বরূপ, JFS-এর মৃত্যু সম্পর্কে কথা বলা কি সম্ভব? ইদানীং তারা কোরে প্রায় কোন মনোযোগ পায়নি। তারা কি অপ্রচলিত?

এখানে আমাদের একটি সফ্টওয়্যার পণ্যের মৃত্যুর অর্থ কী তা সংজ্ঞায়িত করতে হবে। একদিকে, তারা সফলভাবে ব্যবহার করা হয় (যার জন্য তারা তৈরি করা হয়েছিল, সর্বোপরি), যার অর্থ তারা বেঁচে থাকে। অন্যদিকে, আমি JFS এর পক্ষে কথা বলতে পারি না (আমি অনেক কিছু জানি না), কিন্তু ReiserFS (v3) নতুন প্রবণতার সাথে খাপ খাইয়ে নেওয়া খুব কঠিন (অভ্যাসে পরীক্ষিত)। এর অর্থ হ'ল ভবিষ্যতে বিকাশকারীরা এটির দিকে মনোযোগ দেবেন না, তবে তাদের দিকে যা মানিয়ে নেওয়া সহজ। এই দিক থেকে দেখা যাচ্ছে যে, হায়, স্থাপত্যের দিক থেকে এটি মৃত। আমি মোটেও "নৈতিকভাবে অপ্রচলিত" ধারণাটি পরিচালনা করব না। এটি ভালভাবে প্রযোজ্য, উদাহরণস্বরূপ, একটি পোশাকে, কিন্তু সফ্টওয়্যার পণ্যগুলিতে নয়। কোনো কিছুতে হীনমন্যতা ও শ্রেষ্ঠত্বের ধারণা আছে। আমি একেবারে বলতে পারি যে ReserFS v3 এখন সবকিছুতেই Reiser4 থেকে নিকৃষ্ট, কিন্তু কিছু ধরণের কাজের চাপে এটি অন্য সমস্ত আপস্ট্রিম এফএস-এর থেকে উচ্চতর।

আপনি কি FS Tux3 এবং HAMMER/HAMMER2 (FS for DragonFly BSD) এর উন্নয়ন সম্পর্কে জানেন?

হ্যা আমরা জানি. Tux3-এ আমি একবার তাদের স্ন্যাপশটের প্রযুক্তিতে আগ্রহী ছিলাম (তথাকথিত "সংস্করণ পয়েন্টার"), কিন্তু Reiser4-এ আমরা সম্ভবত একটি ভিন্ন পথে যাব। আমি দীর্ঘদিন ধরে স্ন্যাপশট সমর্থন করার বিষয়ে চিন্তা করছি এবং সাধারণ Reiser4 ভলিউমের জন্য কীভাবে সেগুলি বাস্তবায়ন করা যায় তা এখনও সিদ্ধান্ত নিইনি। আসল বিষয়টি হল ওহাদ রোদেহ দ্বারা প্রস্তাবিত নতুন "অলস" রেফারেন্স কাউন্টার কৌশলটি শুধুমাত্র বি-বৃক্ষের জন্য কাজ করে। আমাদের কাছে সেগুলো নেই। Reiesr4-এ ব্যবহৃত ডেটা স্ট্রাকচারের জন্য, "অলস" কাউন্টারগুলি সংজ্ঞায়িত করা হয়নি - তাদের পরিচয় করিয়ে দেওয়ার জন্য, কিছু অ্যালগরিদমিক সমস্যার সমাধান করা প্রয়োজন, যা এখনও কেউ গ্রহণ করেনি।

হ্যামারের মতে: আমি স্রষ্টার কাছ থেকে একটি নিবন্ধ পড়েছি। আগ্রহী নই. আবার বি-গাছ। এই তথ্য কাঠামো আশাহীনভাবে পুরানো. আমরা গত শতাব্দীতে এটি পরিত্যাগ করেছি।

আপনি কিভাবে CephFS/GlusterFS/etc এর মত নেটওয়ার্ক ক্লাস্টার FS-এর ক্রমবর্ধমান চাহিদা মূল্যায়ন করবেন? এই চাহিদার মানে কি নেটওয়ার্ক FS-এর দিকে ডেভেলপারদের অগ্রাধিকারের পরিবর্তন এবং স্থানীয় FS-এর প্রতি অপর্যাপ্ত মনোযোগ?

হ্যাঁ, অগ্রাধিকারে এমন পরিবর্তন ঘটেছে। স্থানীয় ফাইল সিস্টেমের বিকাশ স্থবির হয়ে পড়েছে। হায়, স্থানীয় ভলিউমের জন্য উল্লেখযোগ্য কিছু করা এখন বেশ কঠিন এবং সবাই তা করতে পারে না। তাদের উন্নয়নে কেউ বিনিয়োগ করতে চায় না। এটি একটি বাণিজ্যিক প্রতিষ্ঠানকে গাণিতিক গবেষণার জন্য অর্থ বরাদ্দ করার জন্য বলার মতোই - কোন উত্সাহ ছাড়াই তারা আপনাকে জিজ্ঞাসা করবে কিভাবে আপনি একটি নতুন উপপাদ্যের উপর অর্থ উপার্জন করতে পারেন। এখন একটি স্থানীয় এফএস এমন কিছু যা যাদুকরীভাবে "বাক্সের বাইরে" এবং "সর্বদা কাজ করা উচিত" এবং যদি এটি কাজ না করে তবে এটি অনাকাঙ্খিত গুঞ্জন সৃষ্টি করে যেমন: "হ্যাঁ, তারা কী ভাবছে!"

তাই স্থানীয় এফএসের প্রতি মনোযোগের অভাব, যদিও সেই এলাকায় এখনও অনেক কাজ বাকি আছে। এবং হ্যাঁ, সবাই ডিস্ট্রিবিউটেড স্টোরেজের দিকে ঝুঁকছে, যা ইতিমধ্যে বিদ্যমান স্থানীয় ফাইল সিস্টেমের ভিত্তিতে তৈরি করা হয়েছে। এটা এখন খুব ফ্যাশনেবল. "বিগ ডেটা" বাক্যাংশটি অনেকের জন্য একটি অ্যাড্রেনালিন রাশ সৃষ্টি করে, এটিকে সম্মেলন, কর্মশালা, বড় বেতন ইত্যাদির সাথে যুক্ত করে।

ইউজার স্পেসের পরিবর্তে কার্নেল স্পেসে নেটওয়ার্ক ফাইল সিস্টেম বাস্তবায়ন করা নীতিগতভাবে কতটা যুক্তিসঙ্গত?

একটি খুব যুক্তিসঙ্গত পদ্ধতি যা এখনও কোথাও বাস্তবায়িত হয়নি। সাধারণভাবে, একটি নেটওয়ার্ক ফাইল সিস্টেম কোন জায়গায় প্রয়োগ করা উচিত সেই প্রশ্নটি হল একটি "দ্বিধারী তরোয়াল।" ওয়েল, এর একটি উদাহরণ তাকান. ক্লায়েন্ট একটি দূরবর্তী মেশিনে ডেটা রেকর্ড করে। তারা নোংরা পাতা আকারে তার পৃষ্ঠা ক্যাশে পড়ে. এটি কার্নেল স্পেসে একটি "পাতলা গেটওয়ে" নেটওয়ার্ক ফাইল সিস্টেমের জন্য কাজ। তারপর অপারেটিং সিস্টেম শীঘ্রই বা পরে আপনাকে সেই পৃষ্ঠাগুলিকে মুক্ত করতে ডিস্কে লিখতে বলবে। তারপর IO-ফরোয়ার্ডিং (পাঠানো) নেটওয়ার্ক FS মডিউল খেলায় আসে। এটি নির্ধারণ করে যে এই পৃষ্ঠাগুলি কোন সার্ভার মেশিনে (সার্ভার নোড) যাবে।

তারপর নেটওয়ার্ক স্ট্যাক দখল করে নেয় (এবং, আমরা জানি, এটি কার্নেল স্পেসে প্রয়োগ করা হয়)। এর পরে, সার্ভার নোড ডেটা বা মেটাডেটা সহ সেই প্যাকেটটি গ্রহণ করে এবং ব্যাকএন্ড স্টোরেজ মডিউলকে নির্দেশ দেয় (অর্থাৎ, স্থানীয় এফএস যা কার্নেল স্পেসে কাজ করে) এই সমস্ত জিনিস রেকর্ড করতে। সুতরাং, আমরা প্রশ্নটি কমিয়ে দিয়েছি যেখানে "প্রেরণ" এবং "গ্রহণ" মডিউলগুলি কাজ করবে। যদি এই মডিউলগুলির মধ্যে যেকোনও ব্যবহারকারীর জায়গায় চলে, তবে এটি অনিবার্যভাবে প্রসঙ্গ পরিবর্তনের দিকে পরিচালিত করবে (কারনেল পরিষেবাগুলি ব্যবহার করার প্রয়োজনের কারণে)। এই ধরনের সুইচের সংখ্যা বাস্তবায়নের বিবরণের উপর নির্ভর করে।

যদি এরকম অনেক সুইচ থাকে, তাহলে স্টোরেজ থ্রুপুট (I/O কর্মক্ষমতা) কমে যাবে। যদি আপনার ব্যাকএন্ড স্টোরেজ স্লো ডিস্ক দিয়ে তৈরি হয়, তাহলে আপনি উল্লেখযোগ্য ড্রপ লক্ষ্য করবেন না। কিন্তু যদি আপনার দ্রুত ডিস্ক থাকে (SSD, NVRAM, ইত্যাদি), তাহলে প্রসঙ্গ স্যুইচিং ইতিমধ্যেই একটি "বাটলনেক" হয়ে ওঠে এবং, প্রসঙ্গ স্যুইচিং সংরক্ষণ করে, কর্মক্ষমতা উল্লেখযোগ্যভাবে বৃদ্ধি করা যেতে পারে। অর্থ সঞ্চয় করার আদর্শ উপায় হল কার্নেল স্পেসে মডিউলগুলি সরানো। উদাহরণস্বরূপ, আমরা দেখতে পেয়েছি যে 9p সার্ভারটিকে QEMU থেকে হোস্ট মেশিনে কার্নেলে স্থানান্তর করা হলে VirtFS কর্মক্ষমতা তিনগুণ বৃদ্ধি পায়।

এটি, অবশ্যই, একটি নেটওয়ার্ক FS নয়, তবে এটি সম্পূর্ণরূপে জিনিসগুলির সারমর্মকে প্রতিফলিত করে। এই অপ্টিমাইজেশনের নেতিবাচক দিক হল পোর্টেবিলিটি সমস্যা। কারও কারও জন্য, পরবর্তীটি সমালোচনামূলক হতে পারে। উদাহরণস্বরূপ, GlusterFS-এর কার্নেলে কোনো মডিউল নেই। এর জন্য ধন্যবাদ, এটি এখন NetBSD সহ অনেক প্ল্যাটফর্মে কাজ করে।

স্থানীয় FSs নেটওয়ার্কের থেকে এবং তদ্বিপরীত থেকে কি ধারণা ধার করতে পারে?

আজকাল, নেটওয়ার্ক FSs, একটি নিয়ম হিসাবে, স্থানীয় FSs-এর উপর অ্যাড-অন রয়েছে, তাই আমি ঠিক বুঝতে পারছি না আপনি কীভাবে পরবর্তী থেকে কিছু ধার করতে পারেন। ঠিক আছে, প্রকৃতপক্ষে, আসুন 4 জন কর্মচারীর একটি সংস্থা বিবেচনা করি, যেখানে প্রত্যেকে তাদের নিজস্ব কাজ করে: একজন বিতরণ করে, অন্যটি প্রেরণ করে, তৃতীয়টি গ্রহণ করে, চতুর্থ স্টোর। এবং প্রশ্ন, কোম্পানিটি তার কর্মচারীর কাছ থেকে কী ধার নিতে পারে যারা এটি সঞ্চয় করে, এটি একরকম ভুল শোনায় (এটি ইতিমধ্যে তার কাছ থেকে দীর্ঘ সময়ের জন্য ধার নিতে পারে)।

কিন্তু স্থানীয় FS-এর নেটওয়ার্ক থেকে অনেক কিছু শেখার আছে। প্রথমত, আপনাকে তাদের কাছ থেকে শিখতে হবে কিভাবে উচ্চ স্তরে লজিক্যাল ভলিউম একত্রিত করতে হয়। এখন তথাকথিত "উন্নত" স্থানীয় ফাইল সিস্টেমগুলি একচেটিয়াভাবে LVM থেকে ধার করা "ভার্চুয়াল ডিভাইস" প্রযুক্তি ব্যবহার করে লজিক্যাল ভলিউমগুলিকে একত্রিত করে (সেই সংক্রামক লেয়ারিং লঙ্ঘন যা প্রথম ZFS-এ প্রয়োগ করা হয়েছিল)। অন্য কথায়, ভার্চুয়াল ঠিকানাগুলির (ব্লক নম্বরগুলি) বাস্তবে অনুবাদ করা হয় এবং পিছনে একটি নিম্ন স্তরে ঘটে (অর্থাৎ, ফাইল সিস্টেম একটি I/O অনুরোধ জারি করার পরে)।

অনুগ্রহ করে মনে রাখবেন যে ব্লক লেয়ারে সাজানো লজিক্যাল ভলিউম (আয়না নয়) ডিভাইসগুলি যোগ করা এবং অপসারণ করার ফলে এই ধরনের "বৈশিষ্ট্য" সরবরাহকারীরা বিনয়ীভাবে নীরব। আমি বাস্তব ডিভাইসে ফ্র্যাগমেন্টেশন সম্পর্কে কথা বলছি, যা দানবীয় মানগুলিতে পৌঁছাতে পারে, যখন একটি ভার্চুয়াল ডিভাইসে সবকিছু ঠিক থাকে। যাইহোক, খুব কম লোকই ভার্চুয়াল ডিভাইসগুলিতে আগ্রহী: প্রত্যেকেই আপনার আসল ডিভাইসগুলিতে কী ঘটছে তা নিয়ে আগ্রহী। কিন্তু ZFS-এর মত FS (পাশাপাশি LVM-এর সাথে যেকোন FS) শুধুমাত্র ভার্চুয়াল ডিস্ক ডিভাইসগুলির সাথে কাজ করে (ফ্রিগুলির মধ্যে ভার্চুয়াল ডিস্কের ঠিকানা বরাদ্দ করুন, এই ভার্চুয়াল ডিভাইসগুলি ডিফ্র্যাগমেন্ট করুন ইত্যাদি)। এবং বাস্তব ডিভাইসে কি ঘটছে তা তাদের কোন ধারণা নেই!

এখন কল্পনা করুন যে ভার্চুয়াল ডিভাইসে আপনার শূন্য ফ্র্যাগমেন্টেশন রয়েছে (অর্থাৎ, আপনি সেখানে বাস করছেন মাত্র একটি বিশাল পরিমাণ), আপনি আপনার লজিক্যাল ভলিউমে একটি ডিস্ক যুক্ত করুন এবং তারপরে আপনার লজিক্যাল ভলিউম থেকে অন্য একটি র্যান্ডম ডিস্ক সরিয়ে ফেলুন এবং তারপরে ভারসাম্য বজায় রাখুন। এবং তাই অনেক বার. এটা কল্পনা করা কঠিন নয় যে ভার্চুয়াল ডিভাইসে আপনি এখনও একই পরিমাণে বেঁচে থাকবেন, কিন্তু বাস্তব ডিভাইসে আপনি ভাল কিছু দেখতে পাবেন না।

সবচেয়ে খারাপ বিষয় হল আপনি এই পরিস্থিতি সংশোধন করতেও সক্ষম নন! এখানে আপনি যা করতে পারেন তা হল ফাইল সিস্টেমকে ভার্চুয়াল ডিভাইস ডিফ্র্যাগমেন্ট করতে বলা। তবে তিনি আপনাকে বলবেন যে সেখানে সবকিছু দুর্দান্ত - কেবলমাত্র একটি পরিমাণ রয়েছে, বিভাজন শূন্য, এবং এটি আরও ভাল হতে পারে না! সুতরাং, ব্লক স্তরে সাজানো যৌক্তিক ভলিউমগুলি বারবার ডিভাইসগুলি সংযোজন/অপসারণের উদ্দেশ্যে নয়। একটি ভাল উপায়ে, আপনাকে শুধুমাত্র একবার ব্লক স্তরে একটি লজিক্যাল ভলিউম একত্র করতে হবে, এটি ফাইল সিস্টেমে দিতে হবে এবং তারপরে এটির সাথে অন্য কিছু করবেন না।

উপরন্তু, স্বাধীন FS+LVM সাবসিস্টেমের সংমিশ্রণে লজিক্যাল ভলিউম একত্রিত করা হয় এমন ড্রাইভের ভিন্ন প্রকৃতি বিবেচনায় নেওয়ার অনুমতি দেয় না। প্রকৃতপক্ষে, ধরুন আপনি HDD এবং সলিড-স্টেট ডিভাইস থেকে একটি লজিক্যাল ভলিউম একত্র করেছেন। কিন্তু তারপর আগেরটির ডিফ্র্যাগমেন্টেশনের প্রয়োজন হবে, এবং পরেরটির হবে না। পরেরটির জন্য, আপনাকে বাতিলের অনুরোধ জারি করতে হবে, কিন্তু আগেরটির জন্য নয়, ইত্যাদি। যাইহোক, এই সংমিশ্রণে এই ধরনের নির্বাচনীতা প্রদর্শন করা বেশ কঠিন।

মনে রাখবেন যে ফাইল সিস্টেমে আপনার নিজস্ব LVM তৈরি করার পরে, পরিস্থিতির উন্নতি হয় না। তদুপরি, এটি করার মাধ্যমে আপনি আসলে ভবিষ্যতে এটির উন্নতি করার সম্ভাবনাকে শেষ করে দিয়েছেন। এটা খুব খারাপ. একই মেশিনে বিভিন্ন ধরণের ড্রাইভ থাকতে পারে। আর যদি ফাইল সিস্টেম তাদের মধ্যে পার্থক্য না করে, তাহলে কে করবে?

আরেকটি সমস্যা তথাকথিত জন্য অপেক্ষা করা হয়. "যেকোনো জায়গায় লিখুন" ফাইল সিস্টেম (এর মধ্যে Reiser4ও রয়েছে, যদি আপনি মাউন্ট করার সময় উপযুক্ত লেনদেনের মডেল উল্লেখ করেন)। এই ধরনের ফাইল সিস্টেমগুলিকে অবশ্যই ডিফ্র্যাগমেন্টেশন টুল সরবরাহ করতে হবে যা তাদের ক্ষমতায় অভূতপূর্ব। এবং নিম্ন-স্তরের ভলিউম ম্যানেজার এখানে সাহায্য করে না, তবে শুধুমাত্র পথ পায়। আসল বিষয়টি হল যে এই ধরনের একজন পরিচালকের সাথে, আপনার FS শুধুমাত্র একটি ডিভাইসের বিনামূল্যে ব্লকগুলির একটি মানচিত্র সংরক্ষণ করবে - একটি ভার্চুয়াল। সেই অনুযায়ী, আপনি শুধুমাত্র একটি ভার্চুয়াল ডিভাইস ডিফ্র্যাগমেন্ট করতে পারেন। এর মানে হল যে আপনার ডিফ্রাগমেন্টার ভার্চুয়াল ঠিকানাগুলির একটি বিশাল একক স্থানে দীর্ঘ, দীর্ঘ সময়ের জন্য কাজ করবে।

এবং যদি আপনার প্রচুর ব্যবহারকারী থাকে র্যান্ডম ওভাররাইট করে, তাহলে এই জাতীয় ডিফ্র্যাগমেন্টারের দরকারী প্রভাব শূন্যে হ্রাস পাবে। আপনার সিস্টেম অনিবার্যভাবে ধীর হতে শুরু করবে, এবং আপনি শুধুমাত্র হতাশাজনক নির্ণয়ের সামনে আপনার হাত ভাঁজ করতে হবে "ভাঙা নকশা"। একই অ্যাড্রেস স্পেসে চলমান বেশ কয়েকটি ডিফ্র্যাগমেন্টার কেবল একে অপরের সাথে হস্তক্ষেপ করবে। আপনি যদি প্রতিটি বাস্তব ডিভাইসের জন্য বিনামূল্যে ব্লকের নিজস্ব মানচিত্র বজায় রাখেন তবে এটি সম্পূর্ণ ভিন্ন বিষয়। এটি কার্যকরভাবে ডিফ্র্যাগমেন্টেশন প্রক্রিয়াটিকে সমান্তরাল করবে।

তবে এটি কেবল তখনই করা যেতে পারে যদি আপনার কাছে উচ্চ-স্তরের লজিক্যাল ভলিউম ম্যানেজার থাকে। এই ধরনের পরিচালকদের সাথে স্থানীয় ফাইল সিস্টেমগুলি আগে বিদ্যমান ছিল না (অন্তত, আমি তাদের সম্পর্কে জানি না)। শুধুমাত্র নেটওয়ার্ক ফাইল সিস্টেমে (উদাহরণস্বরূপ GlusterFS) এই ধরনের ম্যানেজার ছিল। আরেকটি অত্যন্ত গুরুত্বপূর্ণ উদাহরণ হল ভলিউম ইন্টিগ্রিটি চেক (fsck) ইউটিলিটি। আপনি যদি প্রতিটি সাবভলিউমের জন্য বিনামূল্যে ব্লকের নিজস্ব স্বাধীন মানচিত্র সংরক্ষণ করেন, তাহলে একটি যৌক্তিক ভলিউম পরীক্ষা করার পদ্ধতিটি কার্যকরভাবে সমান্তরাল করা যেতে পারে। অন্য কথায়, উচ্চ-স্তরের পরিচালকদের সাথে যৌক্তিক ভলিউমগুলি আরও ভাল স্কেল করে।

উপরন্তু, নিম্ন-স্তরের ভলিউম পরিচালকদের সাথে আপনি সম্পূর্ণ স্ন্যাপশটগুলি সংগঠিত করতে সক্ষম হবেন না। LVM এবং ZFS-এর মতো ফাইল সিস্টেমের সাথে, আপনি শুধুমাত্র স্থানীয় স্ন্যাপশট নিতে পারেন, কিন্তু বিশ্বব্যাপী স্ন্যাপশট নয়। স্থানীয় স্ন্যাপশট আপনাকে অবিলম্বে শুধুমাত্র নিয়মিত ফাইল অপারেশন রোল ব্যাক করার অনুমতি দেয়। এবং সেখানে কেউ লজিক্যাল ভলিউম (ডিভাইসগুলি যোগ/সরানো) সহ ক্রিয়াকলাপগুলি ফিরিয়ে আনবে না। আসুন একটি উদাহরণ সহ এটি দেখি। কিছু সময়ে, যখন আপনার কাছে 100টি ফাইল সম্বলিত দুটি ডিভাইস A এবং B এর লজিক্যাল ভলিউম থাকে, আপনি সিস্টেম S-এর একটি স্ন্যাপশট নেন এবং তারপরে আরও একশটি ফাইল তৈরি করেন।

После этого вы добавляете к вашему тому устройство С, и наконец откатываете вашу систему к снимку S. Вопрос: сколько файлов и устройств содержит ваш логический том после отката к S? Файлов, как вы уже догадались, будет 100, но вот устройств будет 3 — это те же устройства A, B и C, хотя, на момент создания снимка в системе было всего два устройства (A и B). Операция добавления устройства C не откатилась, и если вы сейчас удалите устройство C из компьютера, то это закорраптит ваши данные, так что перед удалением вам вам нужно будет сначала провести дорогостоящую операцию удаления устройства из логического тома с перебалансировкой, которая раскидает все данные с устройства C на устройства A и B. А вот если бы ваша ФС поддерживала глобальные снимки, такая перебалансировка бы не потребовалась, и после моментального отката к S вы бы могли смело удалить устройство C из компьютера.

সুতরাং, গ্লোবাল স্ন্যাপশটগুলি ভাল কারণ তারা আপনাকে লজিক্যাল ভলিউম (যৌক্তিক ভলিউম) থেকে প্রচুর পরিমাণে ডেটা সহ একটি ডিভাইসের ব্যয়বহুল অপসারণ (সংযোজন) এড়াতে দেয় (অবশ্যই, যদি আপনি আপনার সিস্টেমকে "স্ন্যাপশট" করার কথা মনে রাখেন। সঠিক সময়ে). আমি আপনাকে মনে করিয়ে দিই যে স্ন্যাপশট তৈরি করা এবং ফাইল সিস্টেমকে তাদের কাছে ফিরিয়ে আনা হল তাত্ক্ষণিক ক্রিয়াকলাপ। প্রশ্ন উঠতে পারে: লজিক্যাল ভলিউমে একটি অপারেশনকে তাত্ক্ষণিকভাবে রোল ব্যাক করা কীভাবে সম্ভব যা আপনার তিন দিন সময় নিয়েছে? কিন্তু এটা সম্ভব! আপনার ফাইল সিস্টেম সঠিকভাবে ডিজাইন করা হয়েছে যে প্রদান. আমি তিন বছর আগে এই জাতীয় "3D স্ন্যাপশট" এর ধারণা নিয়ে এসেছি এবং গত বছর আমি এই কৌশলটি পেটেন্ট করেছি।

পরবর্তী জিনিস যা স্থানীয় FS-এর নেটওয়ার্ক থেকে শেখা উচিত তা হল পৃথক ডিভাইসে মেটাডেটা সংরক্ষণ করা যেভাবে নেটওয়ার্ক FS-গুলিকে আলাদা মেশিনে (তথাকথিত মেটাডেটা সার্ভার) সংরক্ষণ করে। এমন অ্যাপ্লিকেশন রয়েছে যা প্রাথমিকভাবে মেটাডেটা নিয়ে কাজ করে এবং এই অ্যাপ্লিকেশনগুলিকে ব্যয়বহুল উচ্চ-পারফরম্যান্স স্টোরেজ ডিভাইসে মেটাডেটা স্থাপন করে ব্যাপকভাবে ত্বরান্বিত করা যেতে পারে। FS+LVM কম্বিনেশনের সাহায্যে, আপনি এই ধরনের সিলেক্টিভিটি প্রদর্শন করতে পারবেন না: LVM জানেন না যে ব্লকটি আপনি এটিতে পাঠিয়েছেন (সেখানে ডেটা বা মেটাডেটা)।

FS+LVM সংমিশ্রণের তুলনায় FS-এ আপনার নিজের নিম্ন-স্তরের LVM প্রয়োগ করে আপনি খুব বেশি সুবিধা পাবেন না, তবে আপনি যা করতে পারেন তা হল FS-কে বিশৃঙ্খল করা যাতে পরে এটির কোডের সাথে কাজ করা অসম্ভব হয়ে পড়ে। ZFS এবং Btrfs, যেগুলি ভার্চুয়াল ডিভাইসগুলির সাথে ছুটে আসে, সমস্তই স্পষ্ট উদাহরণ যে কীভাবে লেয়ারিং লঙ্ঘন স্থাপত্যের পরিপ্রেক্ষিতে সিস্টেমকে হত্যা করে। তাহলে, আমি কেন এই সব? উপরন্তু, ফাইল সিস্টেমে আপনার নিজের নিম্ন-স্তরের LVM ইনস্টল করার প্রয়োজন নেই। পরিবর্তে, আপনাকে একটি উচ্চ স্তরে যৌক্তিক ভলিউমে ডিভাইসগুলিকে একত্রিত করতে হবে, যেমন কিছু নেটওয়ার্ক ফাইল সিস্টেম বিভিন্ন মেশিনের (স্টোরেজ নোড) সাথে করে। সত্য, তারা খারাপ অ্যালগরিদম ব্যবহারের কারণে এটি ঘৃণ্যভাবে করে।

একেবারে ভয়ানক অ্যালগরিদমের উদাহরণ হল GlusterFS ফাইল সিস্টেমে DHT অনুবাদক এবং Ceph ফাইল সিস্টেমে তথাকথিত CRUSH মানচিত্র। আমি যে অ্যালগরিদম দেখেছি তার কোনটিই সরলতা এবং ভাল মাপযোগ্যতার পরিপ্রেক্ষিতে আমাকে সন্তুষ্ট করেনি। তাই আমাকে বীজগণিত মনে রাখতে হয়েছিল এবং নিজেকে সবকিছু আবিষ্কার করতে হয়েছিল। 2015 সালে, হ্যাশ ফাংশনগুলির উপর বান্ডিল নিয়ে পরীক্ষা করার সময়, আমি এমন কিছু নিয়ে এসেছি এবং পেটেন্ট করেছি যা আমার জন্য উপযুক্ত। এখন আমি বলতে পারি যে এই সব বাস্তবে প্রয়োগ করার প্রচেষ্টা সফল হয়েছিল। আমি নতুন পদ্ধতিতে স্কেলেবিলিটির সাথে কোন সমস্যা দেখতে পাচ্ছি না।

হ্যাঁ, প্রতিটি সাবভলিউমের জন্য একটি পৃথক কাঠামোর প্রয়োজন হবে যেমন মেমরিতে একটি সুপারব্লক। এটা কি খুব ভীতিকর? সাধারণভাবে, আমি জানি না কে "সমুদ্র ফুটিয়ে তুলতে" যাচ্ছে এবং একটি স্থানীয় মেশিনে কয়েক হাজার বা তার বেশি ডিভাইসের যৌক্তিক ভলিউম তৈরি করবে। যদি কেউ আমাকে এই ব্যাখ্যা করতে পারেন, আমি খুব কৃতজ্ঞ হবে. এরই মধ্যে, আমার জন্য এটি বিপণন বাজে কথা।

কার্নেল ব্লক ডিভাইস সাবসিস্টেমের পরিবর্তনগুলি (উদাহরণস্বরূপ, blk-mq-এর উপস্থিতি) FS বাস্তবায়নের প্রয়োজনীয়তাগুলিকে প্রভাবিত করেছে?

তাদের কোনো প্রভাব পড়েনি। আমি জানি না ব্লক স্তরে কী ঘটবে যা একটি নতুন এফএস ডিজাইন করতে প্রয়োজনীয় করে তুলবে। এই সাবসিস্টেমের মিথস্ক্রিয়া ইন্টারফেস খুব খারাপ। ড্রাইভারের দিক থেকে, FS শুধুমাত্র নতুন ধরনের ড্রাইভের উপস্থিতি দ্বারা প্রভাবিত হওয়া উচিত, যেখানে ব্লক স্তরটি প্রথমে সামঞ্জস্য করা হবে এবং তারপর FS (রিজার 4 এর জন্য এর অর্থ নতুন প্লাগইনগুলির উপস্থিতি হবে)।

নতুন ধরনের মিডিয়ার উত্থান (উদাহরণস্বরূপ, এসএমআর, বা এসএসডির সর্বব্যাপীতা) মানে কি ফাইল সিস্টেম ডিজাইনের জন্য মৌলিকভাবে নতুন চ্যালেঞ্জ?

হ্যাঁ. এবং এগুলি এফএসের বিকাশের জন্য স্বাভাবিক প্রণোদনা। চ্যালেঞ্জ ভিন্ন এবং সম্পূর্ণ অপ্রত্যাশিত হতে পারে। উদাহরণস্বরূপ, আমি এমন ড্রাইভের কথা শুনেছি যেখানে একটি I/O অপারেশনের গতি ডেটার একটি অংশ এবং এর অফসেটের আকারের উপর অত্যন্ত নির্ভরশীল। লিনাক্সে, যেখানে এফএস ব্লকের আকার পৃষ্ঠার আকারের চেয়ে বেশি হতে পারে না, এই ধরনের ড্রাইভ ডিফল্টরূপে তার সম্পূর্ণ ক্ষমতা দেখাবে না। যাইহোক, যদি আপনার ফাইল সিস্টেমটি সঠিকভাবে ডিজাইন করা হয়, তবে এটি থেকে আরও অনেক কিছু পাওয়ার সুযোগ রয়েছে।

আপনি ছাড়া বর্তমানে কতজন লোক Reiser4 কোড নিয়ে কাজ করছেন?

আমি চাই তার চেয়ে কম, কিন্তু আমি সম্পদের তীব্র ঘাটতিও অনুভব করি না। আমি Reiser4 এর বিকাশের গতিতে বেশি সন্তুষ্ট। আমি "ঘোড়া চালাতে" যাচ্ছি না - এটি সঠিক এলাকা নয়। এখানে, "আপনি যদি আরও নিঃশব্দে গাড়ি চালান তবে আপনি চালিয়ে যাবেন!" একটি আধুনিক ফাইল সিস্টেম হল সবচেয়ে জটিল কার্নেল সাবসিস্টেম, যার ভুল ডিজাইন সিদ্ধান্তগুলি পরবর্তী বছরের মানুষের কাজকে পূর্বাবস্থায় ফিরিয়ে আনতে পারে।

কিছু বাস্তবায়ন করার জন্য স্বেচ্ছাসেবকদের অফার করে, আমি সর্বদা গ্যারান্টি দিই যে প্রচেষ্টা অবশ্যই সঠিক ফলাফলের দিকে নিয়ে যাবে, যা গুরুতর প্রয়োজনের জন্য চাহিদা হতে পারে। আপনি বুঝতে পেরেছেন, একবারে এই ধরনের অনেক গ্যারান্টি থাকতে পারে না। একই সময়ে, আমি এমন "পরিসংখ্যান" দাঁড়াতে পারি না যারা নির্লজ্জভাবে স্পষ্টতই অব্যবহারযোগ্য সফ্টওয়্যারগুলির "বৈশিষ্ট্যগুলি" প্রচার করে, শত শত ব্যবহারকারী এবং বিকাশকারীদের প্রতারিত করে এবং একই সাথে কার্নেল সামিটগুলিতে বসে হাসে।

কোন কোম্পানী Reiser4 উন্নয়নে সমর্থন করার ইচ্ছা প্রকাশ করেছে?

হ্যাঁ, এই ধরনের প্রস্তাব ছিল, সহ. এবং একটি প্রধান বিক্রেতার কাছ থেকে। কিন্তু এর জন্য আমাকে অন্য দেশে চলে যেতে হয়েছে। দুর্ভাগ্যবশত, আমি আর 30 বছর বয়সী নই, আমি ভেঙে যেতে পারি না এবং প্রথম বাঁশিতে এভাবে চলে যেতে পারি না।

Reiser4 থেকে বর্তমানে কোন বৈশিষ্ট্য অনুপস্থিত?

সাধারণ ভলিউমের জন্য কোন "রিসাইজ" ফাংশন নেই, যা ReiserFS(v3) এ পাওয়া যায়। উপরন্তু, DIRECT_IO পতাকার সাথে ফাইল অপারেশন ক্ষতিগ্রস্থ হবে না। এর পরে, আমি একটি ভলিউমকে "অর্থবোধক সাবভলিউম"-এ আলাদা করতে সক্ষম হতে চাই, যার একটি নির্দিষ্ট আকার নেই এবং যেগুলি স্বাধীন ভলিউম হিসাবে মাউন্ট করা যেতে পারে। এই সমস্যাগুলি নতুনদের জন্য ভাল যারা "আসল জিনিস" এ তাদের হাত চেষ্টা করতে চান।

এবং পরিশেষে, আমি সহজ বাস্তবায়ন এবং প্রশাসনের সাথে নেটওয়ার্ক লজিক্যাল ভলিউম থাকতে চাই (আধুনিক অ্যালগরিদম ইতিমধ্যে এটির অনুমতি দেয়)। কিন্তু Reiser4 এর কাছে যেটা অবশ্যই থাকবে না তা হল RAID-Z, স্ক্রাব, ফ্রি স্পেস ক্যাশে, 128-বিট ভেরিয়েবল এবং অন্যান্য মার্কেটিং বাজে কথা যা কিছু ফাইল সিস্টেমের ডেভেলপারদের মধ্যে ধারণার অভাবের পটভূমিতে উদ্ভূত হয়েছে।

প্লাগইন দ্বারা প্রয়োজন হতে পারে যে সবকিছু বাস্তবায়ন করা যেতে পারে?

যদি আমরা শুধুমাত্র ইন্টারফেস এবং প্লাগইনগুলির (মডিউল) ক্ষেত্রে কথা বলি যা তাদের বাস্তবায়ন করে, তবে সবকিছু নয়। কিন্তু আপনি যদি এই ইন্টারফেসে সম্পর্কগুলিও প্রবর্তন করেন, তাহলে, অন্যান্য জিনিসগুলির মধ্যে, আপনার কাছে উচ্চতর পলিমারফিজমের ধারণা থাকবে, যা আপনি ইতিমধ্যেই পেতে পারেন। কল্পনা করুন যে আপনি একটি অবজেক্ট-ওরিয়েন্টেড রানটাইম সিস্টেমকে অনুমানিতভাবে হিমায়িত করেছেন, নির্দেশ পয়েন্টারের মান পরিবর্তন করে অন্য প্লাগইনকে নির্দেশ করেছেন যা একই X ইন্টারফেস প্রয়োগ করে, এবং তারপর সিস্টেমটিকে আনফ্রোজ করে যাতে এটি কার্যকর করা অব্যাহত থাকে।

যদি শেষ ব্যবহারকারী এই ধরনের একটি "প্রতিস্থাপন" লক্ষ্য না করেন, তাহলে আমরা বলি যে সিস্টেমটির X ইন্টারফেসে শূন্য-ক্রম পলিমরফিজম রয়েছে (বা সিস্টেমটি X ইন্টারফেসে ভিন্নধর্মী, যা একই জিনিস)। এখন যদি আপনার কাছে কেবলমাত্র ইন্টারফেসের একটি সেট না থাকে, তবে সেগুলিতে সম্পর্কও থাকে (ইন্টারফেস গ্রাফ), তবে আপনি উচ্চতর অর্ডারের পলিমরফিজমগুলি প্রবর্তন করতে পারেন, যা ইতিমধ্যে যে কোনও ইন্টারফেসের "পাড়ায়" সিস্টেমের ভিন্নতাকে চিহ্নিত করবে। আমি অনেক আগে এই ধরনের শ্রেণীবিভাগ চালু করেছি, কিন্তু, দুর্ভাগ্যবশত, এটি কখনই ঘটেনি।

সুতরাং, প্লাগইন এবং এই জাতীয় উচ্চতর পলিমারফিজমের সাহায্যে, আপনি যে কোনও পরিচিত বৈশিষ্ট্য বর্ণনা করতে পারেন, সেইসাথে "ভবিষ্যদ্বাণী" করতে পারেন যা কখনও উল্লেখ করা হয়নি। আমি এটি কঠোরভাবে প্রমাণ করতে সক্ষম হইনি, তবে আমি এখনও একটি পাল্টা উদাহরণ জানি না। সাধারণভাবে, এই প্রশ্নটি আমাকে ফেলিক্স ক্লেইনের "এরলাঞ্জেন প্রোগ্রাম" এর কথা মনে করিয়ে দিয়েছে। এক সময় তিনি বীজগণিতের একটি শাখা হিসাবে সমস্ত জ্যামিতিকে উপস্থাপন করার চেষ্টা করেছিলেন (বিশেষত, গ্রুপ তত্ত্ব)।

এখন মূল প্রশ্নে - Reiser4 এর প্রচারের সাথে মূল কোরে জিনিসগুলি কীভাবে যাচ্ছে? এই ফাইল সিস্টেমের আর্কিটেকচারের উপর কি কোন প্রকাশনা ছিল যা আপনি শেষ সাক্ষাৎকারে বলেছিলেন? আপনার দৃষ্টিকোণ থেকে এই প্রশ্নটি কতটা প্রাসঙ্গিক?

সাধারণভাবে, আমরা তিন বছর ধরে মূল শাখায় অন্তর্ভুক্তির জন্য বলে আসছি। পাবলিক থ্রেডে রিসারের শেষ মন্তব্য যেখানে পুল অনুরোধটি করা হয়েছিল তার উত্তর দেওয়া হয়নি। তাই আরও সব প্রশ্ন আমাদের জন্য নয়। আমি ব্যক্তিগতভাবে বুঝতে পারছি না কেন আমাদের একটি নির্দিষ্ট অপারেটিং সিস্টেমে "মার্জ" করতে হবে। লিনাক্সে, আলো কীলকের মতো একত্রিত হয়নি। সুতরাং, একটি পৃথক সংগ্রহস্থল রয়েছে যেখানে বিভিন্ন ওএসের জন্য বেশ কয়েকটি শাখা-বন্দর থাকবে। যার প্রয়োজন তার সংশ্লিষ্ট পোর্টটি ক্লোন করতে পারে এবং এটি দিয়ে আপনি যা চান তা করতে পারেন (অবশ্যই লাইসেন্সের মধ্যে)। ঠিক আছে, যদি কারও এটির প্রয়োজন না হয় তবে এটি আমার সমস্যা নয়। এই মুহুর্তে, আমি "প্রধান লিনাক্স কার্নেলে পদোন্নতির" প্রশ্নটিকে নিষ্পত্তি হিসাবে বিবেচনা করার প্রস্তাব করছি।

FS আর্কিটেকচারের প্রকাশনাগুলি প্রাসঙ্গিক, কিন্তু এখনও পর্যন্ত আমি আমার নতুন ফলাফলের জন্য সময় পেয়েছি, যেটিকে আমি উচ্চ অগ্রাধিকার বলে মনে করি। আরেকটি বিষয় হল যে আমি একজন গণিতবিদ, এবং গণিতে যে কোনও প্রকাশনা উপপাদ্য এবং তাদের প্রমাণগুলির সংক্ষিপ্তসার। প্রমাণ ছাড়া সেখানে কিছু প্রকাশ করা খারাপ রুচির লক্ষণ। যদি আমি এফএসের স্থাপত্য সম্পর্কে কোনও বিবৃতিকে পুঙ্খানুপুঙ্খভাবে প্রমাণ করি বা অস্বীকার করি, তবে ফলাফলটি এমন গাদা হবে যে এটি অতিক্রম করা বেশ কঠিন হবে। কে এটা প্রয়োজন? এই কারণেই সম্ভবত সবকিছু তার পুরানো ফর্মে রয়ে গেছে - সোর্স কোড এবং এটিতে মন্তব্য।

বিগত কয়েক বছরে Reiser4 এ নতুন কি আছে?

দীর্ঘ প্রতীক্ষিত স্থিতিশীলতা অবশেষে বাস্তবায়িত হয়েছে। সর্বশেষ প্রদর্শিত একটি বাগ ছিল যা "অনালোচিত" ডিরেক্টরিগুলির দিকে পরিচালিত করেছিল৷ অসুবিধা ছিল যে এটি শুধুমাত্র নামের হ্যাশ সংঘর্ষের পটভূমিতে এবং একটি ট্রি নোডে ডিরেক্টরি রেকর্ডের একটি নির্দিষ্ট অবস্থানের সাথে উপস্থিত হয়েছিল। যাইহোক, আমি এখনও উত্পাদনের জন্য Reiser4 সুপারিশ করতে পারি না: এর জন্য আপনাকে উত্পাদন সিস্টেম প্রশাসকদের সাথে সক্রিয় মিথস্ক্রিয়া সহ কিছু কাজ করতে হবে।

আমরা অবশেষে আমাদের দীর্ঘস্থায়ী ধারণা - বিভিন্ন লেনদেনের মডেলগুলি বাস্তবায়ন করতে পেরেছি। পূর্বে, Reiser4 শুধুমাত্র একটি হার্ডকোডেড Macdonald-Reiser মডেল চালাত। এটি ডিজাইনের সমস্যা তৈরি করেছে। বিশেষ করে, এই জাতীয় লেনদেন মডেলে স্ন্যাপশটগুলি সম্ভব নয় - সেগুলি "ওভাররাইট সেট" নামক একটি পারমাণবিক উপাদান দ্বারা দূষিত হবে৷ Reiser4 বর্তমানে তিনটি লেনদেন মডেল সমর্থন করে। তাদের মধ্যে একটিতে (যেকোনও জায়গায় লিখুন), পারমাণবিক উপাদান ওভাররাইট সেটে শুধুমাত্র সিস্টেম পৃষ্ঠাগুলি (ডিস্ক বিটম্যাপের ছবি, ইত্যাদি) অন্তর্ভুক্ত থাকে, যেগুলি "ফটোগ্রাফ" (মুরগি এবং ডিমের সমস্যা) করা যায় না।

তাই ছবিগুলো এখন সবচেয়ে ভালো উপায়ে উপলব্ধি করা যায়। অন্য লেনদেন মডেলে, সমস্ত পরিবর্তিত পৃষ্ঠাগুলি শুধুমাত্র ওভাররাইট সেটে যায় (অর্থাৎ, এটি মূলত বিশুদ্ধ জার্নালিং)। এই মডেলটি তাদের জন্য যারা Reiser4 পার্টিশনের দ্রুত বিভাজন সম্পর্কে অভিযোগ করেছেন। এখন এই মডেলে আপনার পার্টিশন ReiserFS (v3) এর চেয়ে দ্রুত খণ্ডিত হবে না। তিনটি বিদ্যমান মডেল, কিছু রিজার্ভেশন সহ, অপারেশনগুলির পারমাণবিকতার গ্যারান্টি দেয়, তবে পারমাণবিকতা হারানো এবং শুধুমাত্র বিভাগের অখণ্ডতা রক্ষা করা মডেলগুলিও কার্যকর হতে পারে। এই ধরনের মডেলগুলি সমস্ত ধরণের অ্যাপ্লিকেশনের জন্য উপযোগী হতে পারে (ডাটাবেস, ইত্যাদি), যা ইতিমধ্যে এই ফাংশনগুলির কিছু গ্রহণ করেছে। এই মডেলগুলি Reiser4 এ যুক্ত করা খুব সহজ, কিন্তু আমি তা করিনি, কারণ কেউ আমাকে জিজ্ঞাসা করেনি এবং আমার ব্যক্তিগতভাবে এটির প্রয়োজন নেই।

মেটাডেটা চেকসামগুলি উপস্থিত হয়েছিল এবং আমি সম্প্রতি সেগুলিকে "অর্থনৈতিক" আয়না" (এখনও অস্থির উপাদান) দিয়ে পরিপূরক করেছি। কোনো ব্লকের চেকসাম ব্যর্থ হলে, Reiser4 অবিলম্বে রেপ্লিকা ডিভাইস থেকে সংশ্লিষ্ট ব্লকটি পড়ে। মনে রাখবেন যে ZFS এবং Btrfগুলি এটি করতে পারে না: নকশা এটির অনুমতি দেয় না। সেখানে আপনাকে "স্ক্রাব" নামে একটি বিশেষ ব্যাকগ্রাউন্ড স্ক্যানিং প্রক্রিয়া চালাতে হবে এবং সমস্যাযুক্ত ব্লকে যাওয়ার জন্য অপেক্ষা করতে হবে। প্রোগ্রামাররা রূপকভাবে এই ধরনের ঘটনাকে "ক্র্যাচ" বলে।

এবং অবশেষে, ভিন্নধর্মী লজিক্যাল ভলিউম উপস্থিত হয়েছে, যা ZFS, Btrfs, ব্লক লেয়ার, সেইসাথে FS+LVM সমন্বয়গুলি নীতিগতভাবে প্রদান করতে পারে না - সমান্তরাল স্কেলিং, O(1) ডিস্ক ঠিকানা বরাদ্দকারী, সাবভলিউমের মধ্যে স্বচ্ছ ডেটা মাইগ্রেশন। পরেরটিরও একটি ইউজার ইন্টারফেস রয়েছে। এখন আপনি সহজেই হটেস্ট ডেটা আপনার ভলিউমের সর্বোচ্চ-পারফরম্যান্স ড্রাইভে স্থানান্তর করতে পারেন।

উপরন্তু, এই জাতীয় ড্রাইভে যেকোন নোংরা পৃষ্ঠাগুলিকে জরুরীভাবে ফ্লাশ করা সম্ভব, যার ফলে প্রায়শই fsync(2) নামে পরিচিত অ্যাপ্লিকেশনগুলির গতি বৃদ্ধি পায়। আমি লক্ষ্য করি যে ব্লক লেয়ার কার্যকারিতা, যাকে বলা হয় bcache, এই ধরনের কর্মের স্বাধীনতা প্রদান করে না। নতুন লজিক্যাল ভলিউমগুলি আমার অ্যালগরিদমের উপর ভিত্তি করে (সেখানে সংশ্লিষ্ট পেটেন্ট রয়েছে)। সফ্টওয়্যারটি ইতিমধ্যে বেশ স্থিতিশীল, এটি চেষ্টা করা, কর্মক্ষমতা পরিমাপ করা ইত্যাদি বেশ সম্ভব। একমাত্র অসুবিধা হল যে আপাতত আপনাকে ভলিউম কনফিগারেশনটি ম্যানুয়ালি আপডেট করতে হবে এবং এটি কোথাও সংরক্ষণ করতে হবে।

এখন পর্যন্ত আমি আমার ধারণাগুলি 10 শতাংশ বাস্তবায়ন করতে সক্ষম হয়েছি৷ যাইহোক, আমি যেটিকে সবচেয়ে কঠিন বলে মনে করেছি তাতে সফল হয়েছি - একটি ফ্ল্যাশ পদ্ধতির সাথে যৌক্তিক ভলিউমগুলিকে সংযুক্ত করা যা reiser4 এ সমস্ত বিলম্বিত ক্রিয়া সম্পাদন করে৷ এটি এখনও পরীক্ষামূলক "ফরম্যাট 41" শাখায় রয়েছে।

Reiser4 কি xfstests পাস করে?

আমি যখন শেষ প্রকাশের প্রস্তুতি নিচ্ছিলাম তখন অন্তত এটা আমার জন্য হয়েছিল।

প্লাগইন ব্যবহার করে Reiser4 কে একটি নেটওয়ার্ক (ক্লাস্টার) FS করা নীতিগতভাবে সম্ভব?

এটা সম্ভব, এবং এমনকি প্রয়োজনীয়! আপনি যদি একটি সঠিকভাবে ডিজাইন করা স্থানীয় ফাইল সিস্টেমের উপর ভিত্তি করে একটি নেটওয়ার্ক ফাইল তৈরি করেন, ফলাফলটি খুব চিত্তাকর্ষক হবে! আধুনিক নেটওয়ার্ক এফএস-এ, আমি একটি ব্যাকএন্ড স্টোরেজ স্তরের উপস্থিতিতে সন্তুষ্ট নই, যেটি স্থানীয় FS ব্যবহার করে বাস্তবায়িত হয়। এই স্তরের অস্তিত্ব সম্পূর্ণরূপে অযৌক্তিক। নেটওয়ার্ক FS-কে অবশ্যই ব্লক লেয়ারের সাথে সরাসরি ইন্টারঅ্যাক্ট করতে হবে, এবং স্থানীয় FS কে অন্য কোন সার্ভিস ফাইল তৈরি করতে বলবেন না!

সাধারণভাবে, ফাইল সিস্টেমকে স্থানীয় এবং নেটওয়ার্কে বিভক্ত করা মন্দ থেকে। এটি ত্রিশ বছর আগে ব্যবহৃত অ্যালগরিদমগুলির অপূর্ণতা থেকে উদ্ভূত হয়েছিল এবং যার জায়গায় এখনও কিছু প্রস্তাব করা হয়নি। এটি অপ্রয়োজনীয় সফ্টওয়্যার উপাদানগুলির (বিভিন্ন পরিষেবা, ইত্যাদি) উপস্থিতির কারণও। একটি ভাল উপায়ে, একটি কার্নেল মডিউল আকারে শুধুমাত্র একটি FS থাকা উচিত এবং প্রতিটি মেশিনে ইনস্টল করা ব্যবহারকারী ইউটিলিটিগুলির একটি সেট - একটি ক্লাস্টার নোড। এই FS স্থানীয় এবং নেটওয়ার্ক উভয়. আর কিছু না!

যদি লিনাক্সে Reiser4 এর সাথে কিছু কাজ করে না, আমি FreeBSD-এর জন্য একটি FS অফার করতে চাই (আগের একটি সাক্ষাত্কার থেকে উদ্ধৃতি: “...FreeBSD... একাডেমিক শিকড় রয়েছে... এবং এর মানে হল উচ্চ মাত্রার সম্ভাবনা সহ আমরা বিকাশকারীদের সাথে একটি সাধারণ ভাষা খুঁজে পাবে")?

সুতরাং, যেমনটি আমরা এইমাত্র খুঁজে পেয়েছি, সবকিছু ইতিমধ্যেই লিনাক্সের সাথে নিখুঁতভাবে কাজ করেছে: আমাদের সংগ্রহস্থলের একটি মাস্টার শাখার আকারে এটির জন্য একটি পৃথক কার্যকরী Reiser4 পোর্ট রয়েছে। আমি FreeBSD সম্পর্কে ভুলে যাইনি! অফার ! যারা FreeBSD এর ভেতরটা ভালো করে জানেন তাদের সাথে ঘনিষ্ঠভাবে কাজ করতে আমি প্রস্তুত। যাইহোক: আমি তাদের সম্প্রদায় সম্পর্কে সত্যিই যা পছন্দ করি তা হল যে সিদ্ধান্তগুলি স্বাধীন বিশেষজ্ঞদের একটি আপডেট কাউন্সিল দ্বারা নেওয়া হয়, যার সাথে একজন স্থায়ী ব্যক্তির সরকারী প্রতারণার সাথে কোন সম্পর্ক নেই।

আপনি আজ লিনাক্স ব্যবহারকারী সম্প্রদায়কে কীভাবে রেট দেন? এটা কি আরো "পপ" হয়ে গেছে?

আমার কাজের প্রকৃতি দেখে, এটি মূল্যায়ন করা আমার পক্ষে বেশ কঠিন। বেশিরভাগ ব্যবহারকারীরা আমার কাছে বাগ রিপোর্ট এবং বিভাগটি ঠিক করার অনুরোধ নিয়ে আসে। ব্যবহারকারী হিসাবে ব্যবহারকারী. কেউ বেশি বুদ্ধিমান, কেউ কম। সবার সাথে একই আচরণ করা হয়। ঠিক আছে, যদি ব্যবহারকারী আমার নির্দেশাবলী উপেক্ষা করে, তাহলে আমাকে ক্ষমা করুন: উপেক্ষা আদেশটি আমার পক্ষ থেকেও প্রবেশ করা হবে।

আগামী পাঁচ থেকে দশ বছরের জন্য ফাইল সিস্টেমের বিকাশের ভবিষ্যদ্বাণী করা কি সম্ভব? আপনি কি মনে করেন যে FS বিকাশকারীরা মুখ্য চ্যালেঞ্জগুলির মুখোমুখি হতে পারে?

হ্যাঁ, এই ধরনের একটি পূর্বাভাস করা কঠিন নয়। দীর্ঘদিন ধরে আপস্ট্রিমে ফাইল সিস্টেমের কোনো উন্নয়ন হয়নি। শুধু এমন চেহারা তৈরি হয়। স্থানীয় ফাইল সিস্টেমের বিকাশকারীরা দুর্বল ডিজাইনের সাথে যুক্ত সমস্যায় পড়েন। এখানে একটি সতর্কতা তৈরি করা প্রয়োজন। আমি তথাকথিত "স্টোরেজ", "চাটা" এবং কোডের পোর্টিংকে উন্নয়ন এবং উন্নয়ন বলে মনে করি না। এবং আমি "Btrfs" নামক ভুল বোঝাবুঝিটিকে উন্নয়ন হিসাবে শ্রেণীবদ্ধ করি না যে কারণে আমি ইতিমধ্যে ব্যাখ্যা করেছি।

প্রতিটি প্যাচ শুধুমাত্র তার সমস্যা আরও খারাপ করে তোলে। আমরা হব. এবং সর্বদা বিভিন্ন ধরণের "প্রচারক" আছে যাদের জন্য "সবকিছু কাজ করে।" মূলত, এরা স্কুলছাত্র এবং ছাত্ররা বক্তৃতা এড়িয়ে যাচ্ছে। শুধু কল্পনা করুন: এটি তার জন্য কাজ করে, কিন্তু অধ্যাপক তা করেন না। এই কি একটি অ্যাড্রেনালিন রাশ! আমার দৃষ্টিকোণ থেকে, সবচেয়ে বড় ক্ষতি হয় "কারিগরদের" দ্বারা যারা উৎসাহের সাথে Btrfs-এর বিস্ময়কর বৈশিষ্ট্যগুলিকে সিস্টেমড, ডকার, ইত্যাদির মতো সব ধরণের স্তরে "স্ক্রু" করতে ছুটে যায়। - এটি ইতিমধ্যে মেটাস্টেসের সাথে সাদৃশ্যপূর্ণ।

আসুন এখন পাঁচ থেকে দশ বছরের জন্য একটি পূর্বাভাস তৈরি করার চেষ্টা করি। Reiser4 এ আমরা কি করব তা আমি ইতিমধ্যেই সংক্ষেপে তালিকাভুক্ত করেছি। আপস্ট্রিম থেকে স্থানীয় FS ডেভেলপারদের জন্য প্রধান চ্যালেঞ্জ হবে (হ্যাঁ, এটি ইতিমধ্যেই হয়ে গেছে) বেতনের জন্য একটি উপযুক্ত কাজ করতে অক্ষমতা। ডেটা স্টোরেজের ক্ষেত্রে কোনও ধারণা ছাড়াই, তারা এই দুর্ভাগ্যজনক VFS, XFS এবং ext4 প্যাচ করার চেষ্টা চালিয়ে যাবে। এই পটভূমিতে ভিএফএস-এর পরিস্থিতি বিশেষ করে হাস্যকর দেখায়, একটি রেস্তোরাঁর উন্মত্ত আধুনিকীকরণের কথা মনে করিয়ে দেয় যেখানে কোনও শেফ নেই এবং কোনও শেফ প্রত্যাশিত নয়।

এখন VFS কোড, কোনো শর্ত ছাড়াই, একই সময়ে একাধিক মেমরি পৃষ্ঠা লক করে এবং অন্তর্নিহিত FS-কে সেগুলি চালানোর জন্য আমন্ত্রণ জানায়। ডিলিট অপারেশনে Ext4-এর কর্মক্ষমতা উন্নত করার জন্য এটি চালু করা হয়েছিল, কিন্তু বোঝা সহজ, এই ধরনের সমবর্তী লকিং উন্নত লেনদেন মডেলগুলির সাথে সম্পূর্ণরূপে বেমানান। অর্থাৎ, আপনি কার্নেলের কিছু স্মার্ট ফাইল সিস্টেমের জন্য সমর্থন যোগ করতে পারবেন না। আমি জানি না লিনাক্সের অন্যান্য ক্ষেত্রগুলিতে পরিস্থিতি কী, কিন্তু যতদূর ফাইল সিস্টেম উদ্বিগ্ন, এখানে যে কোনও উন্নয়ন অনুশীলনে Torvalds দ্বারা অনুসরণ করা নীতির সাথে সামঞ্জস্যপূর্ণ হওয়ার সম্ভাবনা নেই (একাডেমিক প্রকল্পগুলিকে বের করে দেওয়া হয়, এবং স্ক্যামাররা যারা একটি বি-বৃক্ষ কি কোন ধারণা নেই, বিশ্বাসের অবিরাম ক্রেডিট জারি করা হয়)। অতএব, ধীর ক্ষয়ের জন্য একটি কোর্স সেট করা হয়েছিল। অবশ্যই, তারা তাদের সমস্ত শক্তি দিয়ে চেষ্টা করবে এটিকে "উন্নয়ন" হিসাবে পাস করার জন্য।

তদুপরি, ফাইল সিস্টেমের "কাস্টোডিয়ান"রা, বুঝতে পেরে যে আপনি একা "স্টোরেজ" থেকে বেশি উপার্জন করতে পারবেন না, তারা আরও লাভজনক ব্যবসায় তাদের হাত চেষ্টা করবে। এগুলি হল, একটি নিয়ম হিসাবে, বিতরণ করা ফাইল সিস্টেম এবং ভার্চুয়ালাইজেশন। সম্ভবত তারা ফ্যাশনেবল ZFS অন্য কোথাও পোর্ট করবে যেখানে এটি এখনও বিদ্যমান নেই। তবে এটি, উজান থেকে আসা সমস্ত এফএসের মতো, একটি নতুন বছরের গাছের মতো: আপনি যদি উপরে আরও কিছু ছোট জিনিস ঝুলিয়ে রাখতে পারেন তবে আপনি আরও গভীরে যেতে পারবেন না। আমি স্বীকার করি যে জেডএফএস-এর উপর ভিত্তি করে একটি গুরুতর এন্টারপ্রাইজ সিস্টেম তৈরি করা সম্ভব, তবে যেহেতু আমরা এখন ভবিষ্যতের বিষয়ে আলোচনা করছি, আমি কেবল দুঃখের সাথে বলতে পারি যে জেডএফএস এই ক্ষেত্রে হতাশ: তাদের ভার্চুয়াল ডিভাইসগুলির সাথে, ছেলেরা অক্সিজেন কেটে দিয়েছে। আরও উন্নয়নের জন্য নিজেদের এবং ভবিষ্যত প্রজন্মের জন্য। ZFS অতীতের একটি জিনিস. এবং ext4 এবং XFS গতকালের আগের দিনও নয়।

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

ফাইল সিস্টেমগুলি এর জন্য নিখুঁত, কারণ আপনি ফলাফলের উপর দশ বছরের জন্য নিরাপদে দর কষাকষি করতে পারেন। ঠিক আছে, যদি কেউ পরে এই ফলাফলের অভাব সম্পর্কে অভিযোগ করে, তবে সে কেবল ফাইল সিস্টেম সম্পর্কে কিছুই বোঝে না! এটি একটি আর্থিক পিরামিডের কথা মনে করিয়ে দেয়: শীর্ষে রয়েছে দুঃসাহসীরা যারা এই জগাখিচুড়িটি শুরু করেছিল, এবং সেই কয়েকজন যারা "ভাগ্যবান" ছিল: তারা "লভ্যাংশ প্রত্যাহার করে নিয়েছে," অর্থাৎ উন্নয়নের জন্য অর্থ পেয়েছেন, ম্যানেজার হিসাবে একটি ভাল বেতনের চাকরি পেয়েছেন, সম্মেলনে "দেখালেন" ইত্যাদি।

এরপরে যারা "অভাগা": তারা লোকসান গণনা করবে, একটি অব্যবহারযোগ্য সফ্টওয়্যার পণ্য উৎপাদনে মোতায়েন করার পরিণতি মোকাবেলা করবে, "ইত্যাদি। তাদের মধ্যে আরো অনেক আছে। ঠিক আছে, পিরামিডের গোড়ায় ডেভেলপারদের একটি বিশাল ভর রয়েছে "সায়িং" অকেজো কোড। তারাই সবচেয়ে বড় ক্ষতিগ্রস্থ, কারণ নষ্ট সময় ফেরত দেওয়া যায় না। এই ধরনের পিরামিড Torvalds এবং তার সহযোগীদের জন্য অত্যন্ত উপকারী। আর এই পিরামিড যত বেশি, তাদের জন্য তত ভালো। এই জাতীয় পিরামিড খাওয়ানোর জন্য, যে কোনও কিছুকে মূলে নেওয়া যেতে পারে। অবশ্য জনসমক্ষে তারা উল্টো কথা বলে। কিন্তু আমি কথা দিয়ে নয়, কাজ দিয়ে বিচার করি।

সুতরাং, "লিনাক্সে ফাইল সিস্টেমের ভবিষ্যত" আরেকটি অত্যন্ত প্রচারিত, কিন্তু খুব কমই ব্যবহারযোগ্য সফ্টওয়্যার। Btrfs-এর পরে, একটি উচ্চ সম্ভাবনা সহ, এই ধরনের একটি "ভবিষ্যতের" স্থান Bcachefs দ্বারা নেওয়া হবে, যা একটি ফাইল সিস্টেমের সাথে লিনাক্স ব্লক স্তর অতিক্রম করার আরেকটি প্রচেষ্টা (একটি খারাপ উদাহরণ সংক্রামক)। এবং সাধারণ কি: Btrfs এর মতো একই সমস্যা রয়েছে। আমি এটিকে দীর্ঘ সময়ের জন্য সন্দেহ করেছিলাম, এবং তারপরে আমি কোনওভাবে প্রতিরোধ করতে পারিনি এবং কোডটি দেখেছিলাম - এটি সত্য!

Bcachefs এবং Btrfs এর লেখকরা, তাদের FS তৈরি করার সময়, সক্রিয়ভাবে অন্যান্য লোকের উত্স ব্যবহার করেছিলেন, তাদের সম্পর্কে খুব কমই বুঝতেন। পরিস্থিতিটি বাচ্চাদের "ভাঙা ফোন" গেমটির খুব স্মরণ করিয়ে দেয়। এবং আমি মোটামুটিভাবে কল্পনা করতে পারি কিভাবে এই কোডটি কার্নেলে অন্তর্ভুক্ত করা হবে। আসলে, কেউ "রেকস" দেখতে পাবে না (সবাই পরে তাদের উপর পা রাখবে)। কোডের শৈলী, অস্তিত্বহীন লঙ্ঘনের অভিযোগ ইত্যাদি সম্পর্কে অসংখ্য বিভ্রান্তির পরে, লেখকের "আনুগত্য" সম্পর্কে একটি উপসংহার তৈরি করা হবে, তিনি অন্যান্য বিকাশকারীদের সাথে কতটা ভালভাবে "মিথস্ক্রিয়া করেন" এবং এই সব কতটা সফলভাবে করতে পারে তারপর কর্পোরেশন বিক্রি করা হবে.

শেষ ফলাফল কেউ আগ্রহী হবে না. বিশ বছর আগে, সম্ভবত, আমি আগ্রহী হতাম, কিন্তু এখন প্রশ্নগুলি ভিন্নভাবে উত্থাপিত হয়েছে: এটি কি প্রচার করা সম্ভব হবে যাতে আগামী দশ বছরের মধ্যে কিছু লোক নিয়োগ করা যায়। এবং, হায়, শেষ ফলাফল সম্পর্কে আশ্চর্য হওয়ার প্রথা নেই।

সাধারণভাবে, আমি স্ক্র্যাচ থেকে আপনার ফাইল সিস্টেম পুনরায় উদ্ভাবন শুরু করার বিরুদ্ধে দৃঢ়ভাবে পরামর্শ দেব। কারণ এমনকি উল্লেখযোগ্য আর্থিক বিনিয়োগও দশ বছরে প্রতিযোগিতামূলক কিছু পেতে যথেষ্ট হবে না। অবশ্যই, আমি গুরুতর প্রকল্পগুলির কথা বলছি, এবং সেগুলি সম্পর্কে নয় যেগুলি কার্নেলে "ধাক্কা" দেওয়ার উদ্দেশ্যে করা হয়েছে। সুতরাং, নিজেকে প্রকাশ করার আরও কার্যকর উপায় হল আমাদের মতো বাস্তব উন্নয়নে যোগদান করা। এটি, অবশ্যই, করা সহজ নয় - তবে এটি কোনও উচ্চ-স্তরের প্রকল্পের ক্ষেত্রে।

প্রথমত, আমি যে সমস্যাটি দেব তা আপনাকে স্বাধীনভাবে কাটিয়ে উঠতে হবে। এর পরে, আপনার উদ্দেশ্যগুলির গুরুত্ব সম্পর্কে নিশ্চিত হয়ে, আমি সাহায্য করতে শুরু করব। ঐতিহ্যগতভাবে, আমরা শুধুমাত্র আমাদের নিজস্ব উন্নয়ন ব্যবহার করি। ব্যতিক্রম হল কম্প্রেশন অ্যালগরিদম এবং কিছু হ্যাশ ফাংশন। আমরা কনফারেন্সে ভ্রমণের জন্য ডেভেলপারদের পাঠাই না, এবং তারপরে আমরা বসে থাকি না এবং অন্যান্য লোকের ধারণাগুলিকে একত্রিত করি না ("হয়তো কি ঘটবে"), যেমনটি বেশিরভাগ স্টার্টআপে প্রচলিত।

আমরা নিজেরাই সমস্ত অ্যালগরিদম বিকাশ করি। আমি বর্তমানে ডেটা স্টোরেজ সায়েন্সের বীজগণিত এবং সমন্বিত দিকগুলিতে আগ্রহী। বিশেষ করে, সীমিত ক্ষেত্র, উপসর্গ, অসমতার প্রমাণ। সাধারণ প্রোগ্রামারদের জন্যও কাজ আছে, কিন্তু আমাকে এখনই আপনাকে সতর্ক করতে হবে: "অন্য এফএসের দিকে তাকান এবং একই কাজ" করার সমস্ত পরামর্শ উপেক্ষা করা হয়েছে। ভিএফএস এর মাধ্যমে লিনাক্সের সাথে ঘনিষ্ঠ সংহতকরণের লক্ষ্যে প্যাচগুলিও সেখানে যাবে।

সুতরাং, আমাদের একটি রেক নেই, তবে আমাদের কোথায় যেতে হবে সে সম্পর্কে আমাদের ধারণা রয়েছে এবং আমাদের আস্থা আছে যে এই দিকটি সঠিক। এই উপলব্ধি স্বর্গ থেকে মান্না আকারে আসেনি। আমি আপনাকে মনে করিয়ে দিই যে আমাদের পিছনে 29 বছরের উন্নয়ন অভিজ্ঞতা রয়েছে, দুটি ফাইল সিস্টেম স্ক্র্যাচ থেকে লেখা। এবং ডেটা পুনরুদ্ধার ইউটিলিটি একই সংখ্যা. আর এই তো অনেক!

উত্স: opennet.ru