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

ঠিক আছে, জেডএফএস, অনুসন্ধিৎসু পাঠকদের সাথে পরিচিত হওয়ার সেরা দিন আজ। শুধু জেনে রাখুন যে OpenZFS বিকাশকারী ম্যাট আহরেন্সের বিনীত মতামতে, "এটি সত্যিই কঠিন।"

তবে আমরা সংখ্যায় পৌঁছানোর আগে - এবং তারা করবে, আমি প্রতিশ্রুতি দিচ্ছি - একটি আট-ডিস্ক ZFS কনফিগারেশনের সমস্ত বিকল্পের জন্য, আমাদের কথা বলা দরকার কিভাবে সাধারণভাবে, ZFS ডিস্কে ডেটা সঞ্চয় করে।

Zpool, vdev এবং ডিভাইস

এই পূর্ণ পুল ডায়াগ্রামে তিনটি সহায়ক vdevs, প্রতিটি শ্রেণীর একটি এবং RAIDz2 এর জন্য চারটি অন্তর্ভুক্ত রয়েছে

অমিল vdev প্রকার এবং আকারের একটি পুল তৈরি করার সাধারণত কোন কারণ নেই - তবে আপনি যদি চান তবে তা করা থেকে আপনাকে বাধা দেওয়ার কিছু নেই।

ZFS ফাইল সিস্টেমটি সত্যিই বুঝতে, আপনাকে এর প্রকৃত গঠনটি ঘনিষ্ঠভাবে দেখতে হবে। প্রথমত, ZFS ভলিউম এবং ফাইল সিস্টেম পরিচালনার ঐতিহ্যগত স্তরকে একীভূত করে। দ্বিতীয়ত, এটি একটি লেনদেনমূলক কপি-অন-রাইট প্রক্রিয়া ব্যবহার করে। এই বৈশিষ্ট্যগুলির মানে হল যে সিস্টেমটি কাঠামোগতভাবে প্রচলিত ফাইল সিস্টেম এবং RAID অ্যারে থেকে খুব আলাদা। প্রাথমিক বিল্ডিং ব্লকগুলির প্রথম সেটগুলি হল স্টোরেজ পুল (zpool), ভার্চুয়াল ডিভাইস (vdev), এবং বাস্তব ডিভাইস (ডিভাইস)।

zpool

zpool স্টোরেজ পুল হল শীর্ষ ZFS কাঠামো। প্রতিটি পুলে এক বা একাধিক ভার্চুয়াল ডিভাইস থাকে। পরিবর্তে, তাদের প্রত্যেকটিতে এক বা একাধিক বাস্তব ডিভাইস (ডিভাইস) রয়েছে। ভার্চুয়াল পুল হল স্বয়ংসম্পূর্ণ ব্লক। একটি ভৌত ​​কম্পিউটারে দুটি বা ততোধিক পৃথক পুল থাকতে পারে, তবে প্রতিটি অন্যদের থেকে সম্পূর্ণ স্বাধীন। পুল ভার্চুয়াল ডিভাইস শেয়ার করতে পারে না.

ZFS-এর রিডানডেন্সি ভার্চুয়াল ডিভাইস লেভেলে, পুল লেভেলে নয়। পুল স্তরে একেবারেই কোনও অপ্রয়োজনীয়তা নেই - যদি কোনও ড্রাইভ vdev বা বিশেষ vdev হারিয়ে যায়, তবে পুরো পুলটি তার সাথে হারিয়ে যায়।

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

একটি সাধারণ ভুল ধারণা রয়েছে যে পুরো পুল জুড়ে ZFS "ডেটা স্ট্রাইপ" লেখা আছে। এটা সত্য নয়। Zpool মোটেও মজার RAID0 নয়, এটি বরং মজার জেবিডি একটি জটিল পরিবর্তনশীল বন্টন প্রক্রিয়া সহ।

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

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

vdev

প্রতিটি স্টোরেজ পুল এক বা একাধিক ভার্চুয়াল ডিভাইস (ভার্চুয়াল ডিভাইস, vdev) নিয়ে গঠিত। পরিবর্তে, প্রতিটি vdev এক বা একাধিক বাস্তব ডিভাইস ধারণ করে। বেশিরভাগ ভার্চুয়াল ডিভাইসগুলি সাধারণ ডেটা স্টোরেজের জন্য ব্যবহৃত হয়, তবে CACHE, LOG এবং বিশেষ সহ বেশ কয়েকটি vdev সহায়ক ক্লাস রয়েছে। এই প্রতিটি vdev প্রকারের পাঁচটি টপোলজির একটি থাকতে পারে: একক ডিভাইস (একক-ডিভাইস), RAIDz1, RAIDz2, RAIDz3, বা মিরর (মিরর)।

RAIDz1, RAIDz2 এবং RAIDz3 হল বিশেষ বৈচিত্র্য যাকে পুরানো টাইমাররা দ্বিগুণ (তির্যক) প্যারিটি RAID বলে। 1, 2 এবং 3 প্রতিটি ডেটা স্ট্রিপের জন্য কতগুলি প্যারিটি ব্লক বরাদ্দ করা হয়েছে তা উল্লেখ করে। প্যারিটির জন্য আলাদা ডিস্কের পরিবর্তে, RAIDz ভার্চুয়াল ডিভাইস এই প্যারিটি ডিস্ক জুড়ে আধা-সমভাবে বিতরণ করে। একটি RAIDz অ্যারে যতগুলি ডিস্ক হারাতে পারে তাতে প্যারিটি ব্লক রয়েছে; যদি এটি অন্য একটি হারায়, এটি ক্র্যাশ করবে এবং স্টোরেজ পুলটি সাথে নিয়ে যাবে।

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

একক vdevs সহজাত বিপজ্জনক. এই ধরনের একটি ভার্চুয়াল ডিভাইস একটি একক ব্যর্থতা থেকে বাঁচবে না - এবং যদি স্টোরেজ বা একটি বিশেষ vdev হিসাবে ব্যবহার করা হয়, তবে এর ব্যর্থতা পুরো পুলটির ধ্বংসের দিকে নিয়ে যাবে। এখানে খুব, খুব সতর্ক থাকুন।

উপরের যেকোনও টপোলজি ব্যবহার করে CACHE, LOG এবং SPECIAL VA তৈরি করা যেতে পারে - কিন্তু মনে রাখবেন যে একটি বিশেষ VA হারানো মানে পুলের ক্ষতি, তাই একটি অপ্রয়োজনীয় টপোলজি অত্যন্ত সুপারিশ করা হয়।

যন্ত্র

এটি সম্ভবত ZFS-এ বোঝার সবচেয়ে সহজ শব্দ - এটি আক্ষরিক অর্থে একটি ব্লক র্যান্ডম অ্যাক্সেস ডিভাইস। মনে রাখবেন যে ভার্চুয়াল ডিভাইসগুলি পৃথক ডিভাইসগুলির দ্বারা গঠিত, যখন একটি পুল ভার্চুয়াল ডিভাইসগুলির দ্বারা গঠিত।

ডিস্ক - হয় চৌম্বক বা কঠিন অবস্থা - হল সবচেয়ে সাধারণ ব্লক ডিভাইস যা vdev এর বিল্ডিং ব্লক হিসাবে ব্যবহৃত হয়। যাইহোক, /dev-এ একটি বর্ণনাকারী সহ যেকোন ডিভাইস করবে, তাই সম্পূর্ণ হার্ডওয়্যার RAID অ্যারে আলাদা ডিভাইস হিসাবে ব্যবহার করা যেতে পারে।

একটি সাধারণ কাঁচা ফাইল হল সবচেয়ে গুরুত্বপূর্ণ বিকল্প ব্লক ডিভাইসগুলির মধ্যে একটি যা থেকে একটি vdev তৈরি করা যেতে পারে। থেকে পরীক্ষা পুল স্পার্স ফাইল পুল কমান্ড চেক করার এবং একটি প্রদত্ত টপোলজির একটি পুল বা ভার্চুয়াল ডিভাইসে কতটা জায়গা পাওয়া যায় তা দেখার একটি খুব সহজ উপায়।

আপনি মাত্র কয়েক সেকেন্ডের মধ্যে স্পার্স ফাইলগুলি থেকে একটি পরীক্ষা পুল তৈরি করতে পারেন - তবে পরে পুরো পুল এবং এর উপাদানগুলি মুছতে ভুলবেন না

ধরা যাক আপনি আটটি ডিস্কে একটি সার্ভার রাখতে চান এবং 10 টিবি ডিস্ক (~9300 GiB) ব্যবহার করার পরিকল্পনা করতে চান - কিন্তু আপনি নিশ্চিত নন যে কোন টপোলজি আপনার প্রয়োজনে সবচেয়ে উপযুক্ত। উপরের উদাহরণে, আমরা কয়েক সেকেন্ডে স্পার্স ফাইল থেকে একটি পরীক্ষা পুল তৈরি করি - এবং এখন আমরা জানি যে আটটি 2 ​​টিবি ডিস্কের একটি RAIDz10 vdev ব্যবহারযোগ্য ক্ষমতার 50 TiB প্রদান করে।

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

প্রভাবিত vdev এর সাথে সংযোগ করার পরে, অতিরিক্ত ডিভাইসটি অনুপস্থিত ডিভাইসে থাকা ডেটার অনুলিপি বা পুনর্গঠন পেতে শুরু করে। প্রথাগত RAID-এ একে বলা হয় পুনর্নির্মাণ, যখন ZFS-এ একে বলা হয় রিসিলভারিং।

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

ডেটা সেট, ব্লক এবং সেক্টর

আমাদের ZFS যাত্রায় বোঝার জন্য পরবর্তী বিল্ডিং ব্লকগুলি হার্ডওয়্যার সম্পর্কে কম এবং ডেটা কীভাবে সংগঠিত এবং সংরক্ষণ করা হয় সে সম্পর্কে আরও বেশি। আমরা এখানে কয়েকটি স্তর এড়িয়ে যাচ্ছি - যেমন মেটাসল্যাব - যাতে সামগ্রিক কাঠামোর বোঝা বজায় রাখার সময় বিশদ বিশৃঙ্খল না হয়।

ডেটা সেট (ডেটাসেট)

যখন আমরা প্রথম একটি ডেটাসেট তৈরি করি, তখন এটি সমস্ত উপলব্ধ পুল স্থান দেখায়। তারপর আমরা কোটা সেট - এবং মাউন্ট পয়েন্ট পরিবর্তন। ম্যাজিক !

Zvol হল বেশিরভাগ অংশে শুধুমাত্র একটি ডেটাসেট এর ফাইল সিস্টেম লেয়ার থেকে ছিনতাই করা হয়েছে, যা আমরা এখানে একটি সম্পূর্ণ স্বাভাবিক ext4 ফাইল সিস্টেম দিয়ে প্রতিস্থাপন করছি।

একটি ZFS ডেটাসেট মোটামুটি একটি স্ট্যান্ডার্ড মাউন্ট করা ফাইল সিস্টেমের মতো। একটি নিয়মিত ফাইল সিস্টেমের মত, প্রথম নজরে এটি "শুধু অন্য ফোল্ডার" এর মত দেখাচ্ছে। কিন্তু নিয়মিত মাউন্টযোগ্য ফাইল সিস্টেমের মতো, প্রতিটি ZFS ডেটাসেটের নিজস্ব মৌলিক বৈশিষ্ট্যের সেট রয়েছে।

প্রথমত, একটি ডেটাসেটের একটি নির্ধারিত কোটা থাকতে পারে। যদি সেট করা হয় zfs set quota=100G poolname/datasetname, তাহলে আপনি মাউন্ট করা ফোল্ডারে লিখতে পারবেন না /poolname/datasetname 100 GiB এর বেশি।

প্রতিটি লাইনের শুরুতে স্ল্যাশের উপস্থিতি - এবং অনুপস্থিতি - লক্ষ্য করুন? ZFS হায়ারার্কি এবং সিস্টেম মাউন্ট হায়ারার্কি উভয় ক্ষেত্রেই প্রতিটি ডেটাসেটের নিজস্ব জায়গা রয়েছে। ZFS অনুক্রমে কোন অগ্রণী স্ল্যাশ নেই - আপনি পুলের নাম দিয়ে শুরু করেন এবং তারপর একটি ডেটাসেট থেকে পরবর্তীতে যাওয়ার পথ। উদাহরণ স্বরূপ, pool/parent/child নামের একটি ডেটাসেটের জন্য child মূল ডেটাসেটের অধীনে parent একটি সৃজনশীল নাম সহ একটি পুলে pool.

ডিফল্টরূপে, ডেটাসেটের মাউন্ট পয়েন্ট ZFS অনুক্রমের নামের সমতুল্য হবে, একটি অগ্রণী স্ল্যাশ সহ - পুল নামক pool হিসাবে মাউন্ট করা হয়েছে /pool, ডেটা সেট parent মধ্যে মাউন্ট করা /pool/parent, এবং চাইল্ড ডেটাসেট child মধ্যে মাউন্ট করা /pool/parent/child. যাইহোক, ডেটাসেটের সিস্টেম মাউন্ট পয়েন্ট পরিবর্তন করা যেতে পারে।

যদি আমরা নির্দিষ্ট করি zfs set mountpoint=/lol pool/parent/child, তারপর ডেটা সেট pool/parent/child হিসাবে সিস্টেমে মাউন্ট /lol.

ডেটাসেট ছাড়াও, আমাদের ভলিউম (zvols) উল্লেখ করা উচিত। একটি ভলিউম মোটামুটি একটি ডেটাসেটের মতোই, ব্যতীত এটিতে আসলে কোনও ফাইল সিস্টেম নেই - এটি কেবল একটি ব্লক ডিভাইস। আপনি, উদাহরণস্বরূপ, তৈরি করতে পারেন zvol নাম সহ mypool/myzvol, তারপর এটিকে একটি ext4 ফাইল সিস্টেম দিয়ে ফরম্যাট করুন, এবং তারপর সেই ফাইল সিস্টেমটি মাউন্ট করুন - আপনার কাছে এখন একটি ext4 ফাইল সিস্টেম আছে, কিন্তু ZFS-এর সমস্ত নিরাপত্তা বৈশিষ্ট্য সহ! এটি একটি একক মেশিনে মূর্খ বলে মনে হতে পারে, কিন্তু একটি iSCSI ডিভাইস রপ্তানি করার সময় ব্যাকএন্ড হিসাবে অনেক বেশি অর্থবহ।

ব্লক

ফাইলটি এক বা একাধিক ব্লক দ্বারা উপস্থাপিত হয়। প্রতিটি ব্লক একটি ভার্চুয়াল ডিভাইসে সংরক্ষণ করা হয়। ব্লকের আকার সাধারণত পরামিতি সমান হয় রেকর্ড আকার, কিন্তু হ্রাস করা যেতে পারে 2^শিফটযদি এতে মেটাডেটা বা একটি ছোট ফাইল থাকে।

আমরা সত্যিই সত্যিই আপনি যদি খুব ছোট শিফট সেট করেন তবে বিশাল পারফরম্যান্স পেনাল্টি নিয়ে মজা করবেন না

একটি ZFS পুলে, মেটাডেটা সহ সমস্ত ডেটা ব্লকগুলিতে সংরক্ষণ করা হয়। প্রতিটি ডেটা সেটের জন্য সর্বাধিক ব্লক আকার প্রপার্টিতে সংজ্ঞায়িত করা হয় recordsize (রেকর্ড আকার)। রেকর্ডের আকার পরিবর্তন করা যেতে পারে, কিন্তু এটি ইতিমধ্যেই ডেটাসেটে লেখা ব্লকের আকার বা অবস্থান পরিবর্তন করবে না - এটি শুধুমাত্র নতুন ব্লকগুলিকে প্রভাবিত করে যেহেতু সেগুলি লেখা হয়েছে৷

অন্যথায় নির্দিষ্ট না হলে, বর্তমান ডিফল্ট রেকর্ড আকার হল 128 KiB। এটি এক ধরনের জটিল ট্রেড-অফ যেখানে কর্মক্ষমতা নিখুঁত নয়, তবে বেশিরভাগ ক্ষেত্রেই এটি ভয়ানক নয়। Recordsize 4K থেকে 1M পর্যন্ত যেকোনো মান সেট করা যেতে পারে (উন্নত সেটিংস সহ recordsize আপনি আরও বেশি ইনস্টল করতে পারেন, তবে এটি খুব কমই একটি ভাল ধারণা)।

যেকোন ব্লক শুধুমাত্র একটি ফাইলের ডেটা বোঝায় - আপনি একটি ব্লকে দুটি ভিন্ন ফাইল ক্র্যাম করতে পারবেন না। আকারের উপর নির্ভর করে প্রতিটি ফাইলে এক বা একাধিক ব্লক থাকে। ফাইলের আকার রেকর্ড আকারের চেয়ে ছোট হলে, এটি একটি ছোট ব্লক আকারে সংরক্ষণ করা হবে - উদাহরণস্বরূপ, একটি 2 KiB ফাইল সহ একটি ব্লক ডিস্কে শুধুমাত্র একটি 4 KiB সেক্টর দখল করবে।

যদি ফাইলটি যথেষ্ট বড় হয় এবং বেশ কয়েকটি ব্লকের প্রয়োজন হয়, তাহলে এই ফাইলের সাথে সমস্ত রেকর্ড আকারের হবে recordsize - শেষ এন্ট্রি সহ, যার প্রধান অংশ হতে পারে অব্যবহৃত স্থান.

zvols একটি সম্পত্তি নেই recordsize - পরিবর্তে তাদের একটি সমতুল্য সম্পত্তি আছে volblocksize.

সেক্টর

সর্বশেষ, সবচেয়ে মৌলিক বিল্ডিং ব্লক হল সেক্টর। এটি হল ক্ষুদ্রতম ভৌত একক যা অন্তর্নিহিত ডিভাইস থেকে লেখা বা পড়া যায়। কয়েক দশক ধরে, বেশিরভাগ ডিস্ক 512-বাইট সেক্টর ব্যবহার করে। সম্প্রতি, বেশিরভাগ ডিস্ক 4 KiB সেক্টরের জন্য কনফিগার করা হয়েছে, এবং কিছু - বিশেষ করে SSD - 8 KiB সেক্টর বা তারও বেশি।

ZFS সিস্টেমের একটি সম্পত্তি রয়েছে যা আপনাকে সেক্টরের আকার ম্যানুয়ালি সেট করতে দেয়। এই সম্পত্তি ashift. কিছুটা বিভ্রান্তিকরভাবে, শিফট হল দুটি শক্তি। উদাহরণ স্বরূপ, ashift=9 মানে 2^9 বা 512 বাইটের একটি সেক্টর সাইজ।

যখন কোনো নতুন vdev-এ প্রতিটি ব্লক ডিভাইস যুক্ত করা হয়, তখন ZFS সেটির বিস্তারিত তথ্যের জন্য অপারেটিং সিস্টেমকে জিজ্ঞাসা করে এবং তাত্ত্বিকভাবে, এই তথ্যের উপর ভিত্তি করে স্বয়ংক্রিয়ভাবে ashift যথাযথভাবে সেট করে। দুর্ভাগ্যবশত, অনেক ড্রাইভ সামঞ্জস্যতা বজায় রাখার জন্য তাদের সেক্টর সাইজ সম্পর্কে মিথ্যা তথ্য দেয়। Windows এক্সপি (যা বিভিন্ন সেক্টর আকারের ড্রাইভ বুঝতে অক্ষম ছিল)।

এর মানে হল যে একজন ZFS প্রশাসককে তাদের ডিভাইসের প্রকৃত সেক্টরের আকার জানতে এবং ম্যানুয়ালি সেট করার পরামর্শ দেওয়া হয় ashift. যদি শিফট খুব কম সেট করা হয়, তাহলে রিড/রাইট অপারেশনের সংখ্যা জ্যোতির্বিদ্যাগতভাবে বৃদ্ধি পায়। সুতরাং, 512-বাইট "সেক্টর"কে একটি বাস্তব 4 KiB সেক্টরে লেখার অর্থ হল প্রথম "সেক্টর" লিখতে হবে, তারপর 4 KiB সেক্টর পড়ুন, দ্বিতীয় 512-বাইটের "সেক্টর" দিয়ে এটিকে পরিবর্তন করুন, এটিকে নতুন করে লিখুন। 4 KiB সেক্টর, এবং তাই. প্রতিটি এন্ট্রি জন্য.

বাস্তব জগতে, এই ধরনের শাস্তি স্যামসাং ইভিও এসএসডিগুলিকে আঘাত করে, যার জন্য ashift=13, কিন্তু এই SSD গুলি তাদের সেক্টরের আকার সম্পর্কে মিথ্যা বলে, এবং তাই ডিফল্ট সেট করা আছে ashift=9. যদি একজন অভিজ্ঞ সিস্টেম অ্যাডমিনিস্ট্রেটর এই সেটিং পরিবর্তন না করেন, তাহলে এই SSD কাজ করে ধীর প্রচলিত চৌম্বক HDD.

তুলনার জন্য, খুব বড় আকারের জন্য ashift কার্যত কোন শাস্তি নেই। কোন বাস্তব কর্মক্ষমতা জরিমানা নেই, এবং অব্যবহৃত স্থান বৃদ্ধি অসীম (বা কম্প্রেশন সক্ষম সহ শূন্য)। অতএব, আমরা দৃঢ়ভাবে সুপারিশ করি যে এমনকি সেই ড্রাইভগুলিও যেগুলি 512-বাইট সেক্টর ব্যবহার করে ইনস্টল করুন ashift=12 বা এমনকি এমনকি ashift=13আত্মবিশ্বাসের সাথে ভবিষ্যতের মুখোমুখি হতে।

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

কপি-অন-রাইট মেকানিজম

যদি একটি নিয়মিত ফাইল সিস্টেমের ডেটা ওভাররাইট করার প্রয়োজন হয়, তবে এটি প্রতিটি ব্লক যেখানে আছে সেখানে পরিবর্তন করে

একটি কপি-অন-রাইট ফাইল সিস্টেম একটি নতুন ব্লক সংস্করণ লেখে এবং তারপরে পুরানো সংস্করণটি আনলক করে

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

এখন আমরা কপি-অন-রাইট স্ন্যাপশটগুলি কীভাবে কাজ করে সে সম্পর্কে একটি ভাল ধারণা পেতে পারি - প্রতিটি ব্লক একাধিক স্ন্যাপশটের অন্তর্গত হতে পারে এবং সমস্ত সম্পর্কিত স্ন্যাপশটগুলি ধ্বংস না হওয়া পর্যন্ত অব্যাহত থাকবে

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

পরিবর্তে, একটি অনুলিপি-অন-রাইট ফাইল সিস্টেম পরিবর্তিত ব্লকের একটি নতুন সংস্করণ লেখে এবং তারপরে পুরানো ব্লকটিকে আনলিঙ্ক করতে এবং আপনার লেখা নতুন ব্লকটিকে সংযুক্ত করতে ফাইলের মেটাডেটা আপডেট করে।

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

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

ZIL: ZFS অভিপ্রায় লগ

ZFS সিস্টেম সিঙ্ক্রোনাস রাইটগুলিকে একটি বিশেষ উপায়ে ব্যবহার করে - এটি অস্থায়ীভাবে কিন্তু অবিলম্বে সেগুলিকে ZIL-এ সঞ্চয় করে পরে স্থায়ীভাবে অসিঙ্ক্রোনাস রাইটের সাথে লেখার আগে।

সাধারণত, একটি ZIL-তে লেখা ডেটা আর পড়া হয় না। কিন্তু এটি একটি সিস্টেম ক্র্যাশ পরে সম্ভব

SLOG, বা সেকেন্ডারি LOG ডিভাইস, শুধুমাত্র একটি বিশেষ - এবং বিশেষত খুব দ্রুত - vdev, যেখানে ZIL প্রধান স্টোরেজ থেকে আলাদাভাবে সংরক্ষণ করা যেতে পারে

ক্র্যাশের পরে, ZIL-এর সমস্ত নোংরা ডেটা পুনরায় প্লে করা হয় - এই ক্ষেত্রে, ZIL SLOG-তে রয়েছে, তাই এটি সেখান থেকে পুনরায় প্লে করা হয়

লেখার ক্রিয়াকলাপের দুটি প্রধান বিভাগ রয়েছে - সিঙ্ক্রোনাস (সিঙ্ক) এবং অ্যাসিঙ্ক্রোনাস (অসিঙ্ক)। বেশিরভাগ কাজের চাপের জন্য, বেশিরভাগ লেখাই অ্যাসিঙ্ক্রোনাস - ফাইল সিস্টেম সেগুলিকে একত্রিত এবং ব্যাচে জারি করার অনুমতি দেয়, ফ্র্যাগমেন্টেশন হ্রাস করে এবং ব্যাপকভাবে থ্রুপুট বৃদ্ধি করে।

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

ZFS নিয়মিত ফাইল সিস্টেমের চেয়ে ভিন্নভাবে সিঙ্ক্রোনাস রাইট পরিচালনা করে — অবিলম্বে তাদের নিয়মিত স্টোরেজে কমিট করার পরিবর্তে, ZFS সেগুলিকে ZFS ইন্টেন্ট লগ বা ZIL নামে একটি বিশেষ স্টোরেজ এলাকায় কমিট করে। কৌশলটি হল এই রেকর্ডগুলি এছাড়াও মেমরিতে থাকে, সাধারণ অ্যাসিঙ্ক্রোনাস লেখার অনুরোধের সাথে একত্রিত করা হয়, পরে পুরোপুরি স্বাভাবিক TXGs (লেনদেন গ্রুপ) হিসাবে স্টোরেজে ফ্লাশ করা হয়।

স্বাভাবিক ক্রিয়াকলাপে, ZIL লেখা হয় এবং আর পড়া হয় না। যখন, কয়েক মুহূর্ত পরে, ZIL-এর রেকর্ডগুলি RAM থেকে সাধারণ TXG-তে প্রধান স্টোরেজের জন্য প্রতিশ্রুতিবদ্ধ হয়, তখন সেগুলি ZIL থেকে বিচ্ছিন্ন হয়। শুধুমাত্র যখন পুল আমদানি করা হয় তখনই ZIL থেকে কিছু পড়া হয়।

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

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

পুলে LOG সহ একটি vdev যোগ করা কাজ করে না নারা অ্যাসিঙ্ক্রোনাস লেখার কার্যকারিতা উন্নত করুন - এমনকি যদি আপনি জোর করে ZIL-এ সমস্ত লিখতে পারেন zfs set sync=always, তারা এখনও লগ ছাড়া একই ভাবে এবং একই গতিতে TXG-এর মূল স্টোরেজের সাথে লিঙ্ক করা হবে। একমাত্র সরাসরি কর্মক্ষমতা উন্নতি হল সিঙ্ক্রোনাস রাইটের লেটেন্সি (কারণ দ্রুত লগ অপারেশনের গতি বাড়ায়)। sync).

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

স্ন্যাপশট

কপি-অন-রাইট প্রক্রিয়া ZFS পারমাণবিক স্ন্যাপশট এবং ক্রমবর্ধমান অ্যাসিঙ্ক্রোনাস প্রতিলিপির জন্য একটি প্রয়োজনীয় ভিত্তি। সক্রিয় ফাইল সিস্টেমে একটি পয়েন্টার ট্রি রয়েছে যা বর্তমান ডেটা সহ সমস্ত রেকর্ড চিহ্নিত করে - যখন আপনি একটি স্ন্যাপশট নেন, আপনি কেবল এই পয়েন্টার ট্রিটির একটি অনুলিপি তৈরি করেন।

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

প্রতিলিপি

2015 সালে আমার স্টিম লাইব্রেরি ছিল 158 GiB এবং এতে 126 ফাইল অন্তর্ভুক্ত ছিল। এটি rsync-এর জন্য সর্বোত্তম পরিস্থিতির বেশ কাছাকাছি - নেটওয়ার্কে ZFS প্রতিলিপি "কেবল" 927% দ্রুত ছিল৷

একই নেটওয়ার্কে, একটি ৪০-গিগাবাইটের ভার্চুয়াল মেশিন ইমেজ ফাইলের প্রতিলিপি তৈরি Windows ৭ নম্বর বিষয়টি সম্পূর্ণ ভিন্ন। ZFS রেপ্লিকেশন rsync-এর চেয়ে ২৮৯ গুণ দ্রুততর—অথবা "মাত্র" ১৬১ গুণ দ্রুততর, যদি আপনি --inplace সুইচটি ব্যবহার করে rsync কল করার মতো যথেষ্ট পারদর্শী হন।

যখন একটি VM চিত্র স্কেল করা হয়, তখন rsync এটির সাথে স্কেল সমস্যা করে। 1,9 TiB একটি আধুনিক VM চিত্রের জন্য এত বড় নয় - তবে এটি যথেষ্ট বড় যে ZFS প্রতিলিপি rsync এর চেয়ে 1148 গুণ দ্রুত, এমনকি rsync-এর --inplace আর্গুমেন্টের সাথেও

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

জিনিসগুলি দ্বিতীয়টিতে আরও আকর্ষণীয় হয়ে ওঠে zfs send. আমরা এখন দুটি সিস্টেম আছে, প্রতিটি ধারণকারী poolname/datasetname@1, এবং আপনি একটি নতুন স্ন্যাপশট নিন poolname/datasetname@2. অতএব, মূল পুল আপনি আছে datasetname@1 и datasetname@2, এবং লক্ষ্য পুল এ পর্যন্ত শুধুমাত্র প্রথম স্ন্যাপশট datasetname@1.

যেহেতু আমাদের উৎস এবং লক্ষ্যের মধ্যে একটি সাধারণ স্ন্যাপশট আছে datasetname@1, আমরা এটা করতে পারি ক্রমবর্ধমান zfs send এর উপর. আমরা যখন সিস্টেমকে বলি zfs send -i poolname/datasetname@1 poolname/datasetname@2, এটি দুটি পয়েন্টার গাছের তুলনা করে। যে কোনো পয়েন্টার যে শুধুমাত্র বিদ্যমান @2, স্পষ্টতই নতুন ব্লকগুলি উল্লেখ করুন - তাই আমাদের এই ব্লকগুলির বিষয়বস্তু প্রয়োজন।

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

ZFS অ্যাসিঙ্ক্রোনাস ইনক্রিমেন্টাল রেপ্লিকেশন আগের নন-স্ন্যাপশট ভিত্তিক পদ্ধতি যেমন rsync-এর তুলনায় একটি বিশাল উন্নতি। উভয় ক্ষেত্রেই, শুধুমাত্র পরিবর্তিত ডেটা স্থানান্তর করা হয় - তবে প্রথমে rsync আবশ্যক পড়া ডিস্ক থেকে উভয় পক্ষের সমস্ত ডেটা যোগফল পরীক্ষা করে তুলনা করুন। বিপরীতে, ZFS রেপ্লিকেশন পয়েন্টার ট্রি ছাড়া আর কিছুই পড়ে না - এবং যে কোনো ব্লক যা শেয়ার করা স্ন্যাপশটে উপস্থিত নেই।

অন্তর্নির্মিত কম্প্রেশন

কপি-অন-রাইট মেকানিজম ইনলাইন কম্প্রেশন সিস্টেমকেও সরল করে। একটি প্রথাগত ফাইল সিস্টেমে, কম্প্রেশন সমস্যাযুক্ত - পুরানো সংস্করণ এবং পরিবর্তিত ডেটার নতুন সংস্করণ উভয়ই একই স্থানে থাকে।

যদি আমরা একটি ফাইলের মাঝখানে ডেটার একটি অংশ বিবেচনা করি যা 0x00000000 থেকে শূন্যের মেগাবাইট হিসাবে জীবন শুরু করে এবং তাই, এটি ডিস্কের একটি সেক্টরে সংকুচিত করা খুব সহজ। কিন্তু কি হবে যদি আমরা শূন্যের সেই মেগাবাইটটিকে জেপিইজি বা সিউডো-র্যান্ডম নয়েজের মতো অসংকোচনীয় ডেটার মেগাবাইট দিয়ে প্রতিস্থাপন করি? অপ্রত্যাশিতভাবে, এই মেগাবাইট ডেটার জন্য একটি নয়, 256 4 KiB সেক্টর প্রয়োজন হবে এবং ডিস্কের এই জায়গায় শুধুমাত্র একটি সেক্টর সংরক্ষিত আছে।

ZFS-এর এই সমস্যা নেই, কারণ সংশোধিত রেকর্ডগুলি সর্বদা অব্যবহৃত স্থানে লেখা হয় - আসল ব্লকটি শুধুমাত্র একটি 4 KiB সেক্টর দখল করে, এবং নতুন রেকর্ডটি 256 দখল করবে, তবে এটি কোনও সমস্যা নয় - একটি সাম্প্রতিক সংশোধিত খণ্ড " ফাইলের মাঝামাঝি" অব্যবহৃত স্থানে লেখা হবে, এর আকার পরিবর্তিত হয়েছে কিনা তা নির্বিশেষে, তাই ZFS-এর জন্য এটি একটি নিয়মিত পরিস্থিতি।

নেটিভ ZFS কম্প্রেশন ডিফল্টরূপে অক্ষম করা হয়, এবং সিস্টেমটি প্লাগেবল অ্যালগরিদম অফার করে—বর্তমানে LZ4, gzip (1-9), LZJB, এবং ZLE।

• LZ4 একটি স্ট্রিমিং অ্যালগরিদম যা অত্যন্ত দ্রুত কম্প্রেশন এবং ডিকম্প্রেশন এবং বেশিরভাগ ব্যবহারের ক্ষেত্রে পারফরম্যান্স সুবিধা প্রদান করে - এমনকি মোটামুটি ধীর CPU-তেও।
• GZIP একটি সম্মানীয় অ্যালগরিদম যা সকল ইউনিক্স ব্যবহারকারীরা জানেন এবং ভালবাসেন। এটি কম্প্রেশন লেভেল 1-9 এর সাথে প্রয়োগ করা যেতে পারে, কম্প্রেশন রেশিও এবং সিপিইউ ব্যবহার বাড়ার সাথে সাথে এটি 9 লেভেলের কাছে পৌঁছায়। অ্যালগরিদমটি সমস্ত টেক্সট (বা অন্যান্য উচ্চ সংকোচনযোগ্য) ব্যবহারের ক্ষেত্রে উপযুক্ত, তবে অন্যথায় প্রায়শই CPU সমস্যা সৃষ্টি করে - এটি ব্যবহার করুন যত্ন সহ, বিশেষ করে উচ্চ স্তরে।
• এলজেডজেবি ZFS এর মূল অ্যালগরিদম। এটি অবহেলিত এবং আর ব্যবহার করা উচিত নয়, LZ4 এটিকে সব দিক থেকে ছাড়িয়ে গেছে।
• জেডএলই - জিরো লেভেল এনকোডিং, জিরো লেভেল এনকোডিং। এটি মোটেও সাধারণ ডেটা স্পর্শ করে না, তবে শূন্যের বড় ক্রম সংকুচিত করে। সম্পূর্ণরূপে অসংকোচনীয় ডেটাসেটগুলির জন্য দরকারী (যেমন JPEG, MP4, বা অন্যান্য ইতিমধ্যে সংকুচিত ফর্ম্যাট) কারণ এটি অসংকোচনীয় ডেটা উপেক্ষা করে কিন্তু ফলাফল রেকর্ডে অব্যবহৃত স্থান সংকুচিত করে।

আমরা প্রায় সব ব্যবহারের ক্ষেত্রে LZ4 কম্প্রেশন সুপারিশ করি; অসংকোচনীয় ডেটার সম্মুখীন হওয়ার সময় কার্যক্ষমতার শাস্তি খুবই ছোট, এবং উন্নতি সাধারণ ডেটার ক্ষেত্রে পারফরম্যান্সের উপর এর প্রভাব উল্লেখযোগ্য। নতুন অপারেটিং সিস্টেম ইনস্টলেশনের জন্য একটি ভার্চুয়াল মেশিন ইমেজ কপি করা। Windows (নতুন ইনস্টল করা ওএস, এখনও ভিতরে কোনো ডেটা নেই) compression=lz4 সঙ্গে 27% দ্রুত পাস compression=none, ইন 2015 সালে এই পরীক্ষা.

ARC - অভিযোজিত প্রতিস্থাপন ক্যাশে

ZFS হল একমাত্র আধুনিক ফাইল সিস্টেম যা আমরা জানি যেটি RAM-তে সম্প্রতি পঠিত ব্লকের কপি সংরক্ষণ করার জন্য অপারেটিং সিস্টেমের পৃষ্ঠা ক্যাশের উপর নির্ভর না করে নিজস্ব রিড ক্যাশিং পদ্ধতি ব্যবহার করে।

যদিও নেটিভ ক্যাশে তার সমস্যা ছাড়াই নয় - ZFS কার্নেলের মতো দ্রুত নতুন মেমরি বরাদ্দের অনুরোধে সাড়া দিতে পারে না, তাই নতুন চ্যালেঞ্জ malloc() মেমরি বরাদ্দ ব্যর্থ হতে পারে যদি এটি বর্তমানে ARC দ্বারা দখলকৃত RAM এর প্রয়োজন হয়। কিন্তু আপনার নিজের ক্যাশে ব্যবহার করার জন্য ভাল কারণ আছে, অন্তত এখন জন্য.

ম্যাকওএস সহ সকল পরিচিত আধুনিক অপারেটিং সিস্টেম, Windows, Linux এবং BSD পেজ ক্যাশে বাস্তবায়নের জন্য LRU (Least Recently Used) অ্যালগরিদম ব্যবহার করে। এটি একটি আদিম অ্যালগরিদম যা প্রতিটি রিডের পরে একটি ক্যাশ করা ব্লক "কিউ-এর শীর্ষে" নিয়ে যায় এবং নতুন ক্যাশে মিস (যে ব্লকগুলি ক্যাশে থেকে না পড়ে ডিস্ক থেকে পড়া উচিত ছিল) শীর্ষে যুক্ত করার জন্য প্রয়োজন অনুযায়ী ব্লকগুলিকে "কিউ-এর নীচে" পাঠিয়ে দেয়।

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

এআরসি একটি অনেক কম সরল অ্যালগরিদম যা একটি "ভারী" ক্যাশে হিসাবে চিন্তা করা যেতে পারে। প্রতিবার একটি ক্যাশড ব্লক পড়া হলে, এটি একটু "ভারী" এবং উচ্ছেদ করা কঠিন হয়ে যায় - এবং এমনকি একটি ব্লক উচ্ছেদ করার পরেও ট্র্যাক করা একটি নির্দিষ্ট সময়ের মধ্যে। একটি ব্লক যা উচ্ছেদ করা হয়েছে কিন্তু তারপর ক্যাশে আবার পড়তে হবে সেটিও "ভারী" হয়ে যাবে।

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

উপসংহার

ZFS-এর মৌলিক শব্দার্থবিদ্যা শেখার পরে - কীভাবে কপি-অন-রাইট কাজ করে, সেইসাথে স্টোরেজ পুল, ভার্চুয়াল ডিভাইস, ব্লক, সেক্টর এবং ফাইলগুলির মধ্যে সম্পর্ক - আমরা বাস্তব সংখ্যার সাথে বাস্তব-বিশ্বের পারফরম্যান্স নিয়ে আলোচনা করতে প্রস্তুত।

পরবর্তী অংশে, আমরা মিররড ভিডেভ এবং RAIDz যুক্ত পুলগুলোর প্রকৃত পারফরম্যান্স একে অপরের সাথে এবং প্রচলিত কার্নেল RAID টপোলজির সাথে তুলনা করে দেখব। Linuxযেটি আমরা গবেষণা করেছি পূর্বে.

প্রথমে, আমরা শুধুমাত্র মৌলিক বিষয়গুলি কভার করতে চেয়েছিলাম - ZFS টপোলজিগুলি নিজেরাই - কিন্তু পরে৷ যেমন একটি চলুন, L2ARC, SLOG এবং বিশেষ বরাদ্দের মতো সহায়ক vdev ধরনের ব্যবহার সহ ZFS-এর আরও উন্নত সেটআপ এবং টিউনিং সম্পর্কে কথা বলার জন্য প্রস্তুত হই।

উত্স: www.habr.com