اس موسم بہار میں ہم پہلے ہی کچھ تعارفی موضوعات پر بات کر چکے ہیں، مثال کے طور پر، اپنی ڈرائیوز کی رفتار کو کیسے چیک کریں۔ и RAID کیا ہے؟. ان میں سے دوسرے میں، ہم نے ZFS میں مختلف ملٹی ڈسک ٹوپولاجیز کی کارکردگی کا مطالعہ جاری رکھنے کا وعدہ بھی کیا۔ یہ اگلی نسل کا فائل سسٹم ہے جسے اب ہر جگہ لاگو کیا جا رہا ہے: from ایپل پر اوبنٹو.

ٹھیک ہے، آج ZFS، متجسس قارئین سے واقف ہونے کا بہترین دن ہے۔ بس اتنا جان لیں کہ OpenZFS ڈویلپر Matt Ahrens کی عاجزانہ رائے میں، "یہ واقعی مشکل ہے۔"

لیکن اس سے پہلے کہ ہم نمبروں تک پہنچیں - اور وہ کریں گے، میں وعدہ کرتا ہوں - آٹھ ڈسک ZFS کنفیگریشن کے تمام اختیارات کے لیے، ہمیں اس کے بارے میں بات کرنے کی ضرورت ہے۔ کے طور پر عام طور پر، ZFS ڈسک پر ڈیٹا ذخیرہ کرتا ہے۔

Zpool، vdev اور ڈیوائس

اس مکمل پول ڈایاگرام میں تین معاون vdevs، ہر کلاس میں سے ایک، اور RAIDz2 کے لیے چار شامل ہیں۔

عام طور پر غیر مماثل vdev قسموں اور سائزوں کا تالاب بنانے کی کوئی وجہ نہیں ہے - لیکن اگر آپ چاہیں تو آپ کو ایسا کرنے سے کوئی چیز نہیں روک سکتی۔

ZFS فائل سسٹم کو واقعی سمجھنے کے لیے، آپ کو اس کی اصل ساخت پر گہری نظر ڈالنے کی ضرورت ہے۔ سب سے پہلے، ZFS حجم اور فائل سسٹم مینجمنٹ کی روایتی سطحوں کو یکجا کرتا ہے۔ دوم، یہ ایک ٹرانزیکشنل کاپی آن رائٹ میکانزم کا استعمال کرتا ہے۔ ان خصوصیات کا مطلب یہ ہے کہ نظام ساختی طور پر روایتی فائل سسٹمز اور RAID صفوں سے بہت مختلف ہے۔ سمجھنے کے لیے بنیادی بلڈنگ بلاکس کا پہلا سیٹ اسٹوریج پول (zpool)، ورچوئل ڈیوائس (vdev)، اور اصلی ڈیوائس (ڈیوائس) ہیں۔

zpool

zpool اسٹوریج پول ZFS کا سب سے اوپر کا ڈھانچہ ہے۔ ہر پول میں ایک یا زیادہ ورچوئل آلات ہوتے ہیں۔ بدلے میں، ان میں سے ہر ایک میں ایک یا زیادہ حقیقی آلات (آلہ) ہوتے ہیں۔ ورچوئل پولز خود ساختہ بلاکس ہیں۔ ایک جسمانی کمپیوٹر میں دو یا دو سے زیادہ علیحدہ پول ہو سکتے ہیں، لیکن ہر ایک دوسرے سے مکمل طور پر آزاد ہے۔ پولز ورچوئل ڈیوائسز کا اشتراک نہیں کرسکتے ہیں۔

ZFS کی فالتو پن ورچوئل ڈیوائس کی سطح پر ہے، پول کی سطح پر نہیں۔ پول کی سطح پر کوئی فالتو پن نہیں ہے - اگر کوئی ڈرائیو vdev یا اسپیشل vdev کھو جائے، تو اس کے ساتھ پورا پول بھی ضائع ہو جاتا ہے۔

جدید سٹوریج پولز کیشے یا ورچوئل ڈیوائس لاگ کے نقصان سے بچ سکتے ہیں - حالانکہ اگر وہ بجلی کی بندش یا سسٹم کریش کے دوران vdev لاگ کھو دیتے ہیں تو وہ تھوڑا سا گندا ڈیٹا کھو سکتے ہیں۔

ایک عام غلط فہمی ہے کہ ZFS "ڈیٹا سٹرپس" پورے پول میں لکھی جاتی ہیں۔ یہ سچ نہیں ہے. Zpool بالکل بھی مضحکہ خیز RAID0 نہیں ہے، بلکہ مضحکہ خیز ہے۔ جے بی او ڈی ایک پیچیدہ متغیر تقسیم کے طریقہ کار کے ساتھ۔

زیادہ تر حصے کے لیے، ریکارڈز دستیاب ورچوئل ڈیوائسز میں دستیاب خالی جگہ کے مطابق تقسیم کیے جاتے ہیں، لہذا نظریہ میں وہ سب ایک ہی وقت میں بھرے جائیں گے۔ ZFS کے بعد کے ورژنز میں، موجودہ vdev کے استعمال (استعمال) کو مدنظر رکھا جاتا ہے - اگر ایک ورچوئل ڈیوائس دوسرے کے مقابلے میں نمایاں طور پر مصروف ہے (مثال کے طور پر، پڑھنے کے بوجھ کی وجہ سے)، سب سے زیادہ مفت ہونے کے باوجود، اسے عارضی طور پر لکھنے کے لیے چھوڑ دیا جائے گا۔ خلائی تناسب

جدید ZFS رائٹ ایلوکیشن کے طریقوں میں بنایا گیا استعمال کا پتہ لگانے کا طریقہ کار تاخیر کو کم کر سکتا ہے اور غیر معمولی طور پر زیادہ بوجھ کے دوران تھرو پٹ کو بڑھا سکتا ہے - لیکن ایسا نہیں ہے۔ کارٹے بلانچ ایک تالاب میں سست HDDs اور تیز SSDs کے غیر رضاکارانہ اختلاط پر۔ اس طرح کا غیر مساوی پول اب بھی سست ترین ڈیوائس کی رفتار سے کام کرے گا، یعنی گویا یہ مکمل طور پر ایسے آلات پر مشتمل ہے۔

vdev

ہر اسٹوریج پول ایک یا زیادہ ورچوئل ڈیوائسز (ورچوئل ڈیوائس، vdev) پر مشتمل ہوتا ہے۔ بدلے میں، ہر vdev میں ایک یا زیادہ حقیقی آلات ہوتے ہیں۔ زیادہ تر ورچوئل ڈیوائسز سادہ ڈیٹا اسٹوریج کے لیے استعمال کیے جاتے ہیں، لیکن کئی وی ڈیو مددگار کلاسز ہیں، جن میں CACHE، LOG، اور SPECIAL شامل ہیں۔ ان vdev قسموں میں سے ہر ایک میں پانچ میں سے ایک ٹوپولوجی ہو سکتی ہے: سنگل ڈیوائس (سنگل ڈیوائس)، RAIDz1، RAIDz2، RAIDz3، یا آئینہ (آئینہ)۔

RAIDz1، RAIDz2 اور RAIDz3 اس کی خاص قسمیں ہیں جنہیں پرانے وقت والے ڈبل (ڈیگنل) برابری RAID کہتے ہیں۔ 1، 2 اور 3 کا حوالہ دیتے ہیں کہ ہر ڈیٹا سٹرپ کے لیے کتنے برابری بلاکس مختص کیے گئے ہیں۔ برابری کے لیے علیحدہ ڈسک کے بجائے، RAIDz ورچوئل ڈیوائسز اس برابری کو نیم یکساں طور پر تمام ڈسکوں میں تقسیم کرتے ہیں۔ RAIDz سرنی اتنی زیادہ ڈسکیں کھو سکتی ہے جتنی اس میں برابری کے بلاکس ہیں۔ اگر یہ ایک اور کھو دیتا ہے، تو یہ کریش ہو جائے گا اور اسٹوریج پول کو اپنے ساتھ لے جائے گا۔

مررڈ ورچوئل ڈیوائسز (مرر وی ڈیو) میں، ہر بلاک وی ڈی وی میں ہر ڈیوائس پر محفوظ ہوتا ہے۔ اگرچہ دو چوڑے آئینے سب سے زیادہ عام ہیں، لیکن کسی بھی صوابدیدی تعداد میں آلات آئینے میں ہوسکتے ہیں - پڑھنے کی بہتر کارکردگی اور غلطی کو برداشت کرنے کے لیے اکثر بڑی تنصیبات میں ٹرپل استعمال کیے جاتے ہیں۔ ایک vdev آئینہ کسی بھی ناکامی سے بچ سکتا ہے جب تک کہ vdev میں کم از کم ایک آلہ کام کرتا رہے۔

سنگل vdevs فطری طور پر خطرناک ہیں۔ اس طرح کا ورچوئل ڈیوائس ایک بھی ناکامی سے بچ نہیں پائے گا - اور اگر اسے سٹوریج یا خصوصی وی ڈیو کے طور پر استعمال کیا جائے تو اس کی ناکامی پورے پول کی تباہی کا باعث بنے گی۔ یہاں بہت، بہت محتاط رہیں۔

CACHE، LOG، اور SPECIAL VA مندرجہ بالا ٹوپولاجی میں سے کسی کا استعمال کرتے ہوئے بنائے جا سکتے ہیں - لیکن یاد رکھیں کہ ایک خصوصی VA کے نقصان کا مطلب پول کا نقصان ہے، اس لیے ایک بے کار ٹوپولوجی کی انتہائی سفارش کی جاتی ہے۔

آلہ

ZFS میں سمجھنے کے لیے یہ شاید سب سے آسان اصطلاح ہے - یہ لفظی طور پر ایک بلاک رینڈم ایکسیس ڈیوائس ہے۔ یاد رکھیں کہ ورچوئل ڈیوائسز انفرادی ڈیوائسز پر مشتمل ہوتی ہیں، جب کہ ایک پول ورچوئل ڈیوائسز پر مشتمل ہوتا ہے۔

ڈسک - یا تو مقناطیسی یا ٹھوس حالت - سب سے عام بلاک ڈیوائسز ہیں جو vdev کے بلڈنگ بلاکس کے طور پر استعمال ہوتے ہیں۔ تاہم، /dev میں ڈسکرپٹر والا کوئی بھی ڈیوائس کرے گا، لہذا پوری ہارڈ ویئر RAID صفوں کو علیحدہ ڈیوائس کے طور پر استعمال کیا جا سکتا ہے۔

ایک سادہ خام فائل سب سے اہم متبادل بلاک ڈیوائسز میں سے ایک ہے جس سے vdev بنایا جا سکتا ہے۔ سے ٹیسٹ پولز ویرل فائلیں پول کمانڈز کو چیک کرنے اور یہ دیکھنے کا ایک بہت ہی آسان طریقہ ہے کہ پول یا دی گئی ٹوپولوجی کے ورچوئل ڈیوائس میں کتنی جگہ دستیاب ہے۔

آپ صرف چند سیکنڈ میں ویرل فائلوں سے ایک ٹیسٹ پول بنا سکتے ہیں - لیکن اس کے بعد پورے پول اور اس کے اجزاء کو حذف کرنا نہ بھولیں۔

فرض کریں کہ آپ آٹھ ڈسکوں پر سرور لگانا چاہتے ہیں اور 10 TB ڈسک (~9300 GiB) استعمال کرنے کا ارادہ رکھتے ہیں - لیکن آپ کو یقین نہیں ہے کہ کون سی ٹوپولوجی آپ کی ضروریات کے مطابق ہے۔ اوپر کی مثال میں، ہم سیکنڈوں میں ویرل فائلوں سے ایک ٹیسٹ پول بناتے ہیں - اور اب ہم جانتے ہیں کہ آٹھ 2 TB ڈسکوں کا RAIDz10 vdev قابل استعمال صلاحیت 50 TiB فراہم کرتا ہے۔

آلات کی ایک اور خاص کلاس SPARE (اسپیئر) ہے۔ ہاٹ سویپ ڈیوائسز، ریگولر ڈیوائسز کے برعکس، پورے پول سے تعلق رکھتی ہیں، نہ کہ کسی ایک ورچوئل ڈیوائس سے۔ اگر پول میں ایک وی ڈی وی ناکام ہوجاتا ہے اور اسپیئر ڈیوائس پول سے منسلک ہے اور دستیاب ہے، تو یہ خود بخود متاثرہ وی ڈیو میں شامل ہوجائے گا۔

متاثرہ وی ڈیو سے منسلک ہونے کے بعد، اسپیئر ڈیوائس کو ڈیٹا کی کاپیاں یا ری کنسٹرکشن موصول ہونا شروع ہو جاتا ہے جو گمشدہ ڈیوائس پر ہونا چاہیے۔ روایتی RAID میں اسے ری بلڈنگ کہا جاتا ہے، جبکہ ZFS میں اسے resilvering کہا جاتا ہے۔

یہ نوٹ کرنا ضروری ہے کہ فاضل آلات مستقل طور پر ناکام آلات کی جگہ نہیں لیتے ہیں۔ یہ صرف ایک عارضی متبادل ہے جس سے وقت کی مقدار کو کم کیا جا سکتا ہے 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 سیکٹرز کے لیے ترتیب دی گئی ہیں، اور کچھ - خاص طور پر SSDs - میں 8 KiB سیکٹرز یا اس سے بھی زیادہ ہیں۔

ZFS سسٹم میں ایک خاصیت ہے جو آپ کو دستی طور پر سیکٹر کا سائز سیٹ کرنے کی اجازت دیتی ہے۔ یہ پراپرٹی ashift. کسی حد تک مبہم طور پر، شفٹ دو کی طاقت ہے۔ مثال کے طور پر، ashift=9 مطلب 2^9، یا 512 بائٹس کا سیکٹر سائز۔

ZFS ہر بلاک ڈیوائس کے بارے میں تفصیلی معلومات کے لیے آپریٹنگ سسٹم سے استفسار کرتا ہے جب اسے کسی نئے vdev میں شامل کیا جاتا ہے، اور نظریاتی طور پر خود بخود اس معلومات کی بنیاد پر ashft کو درست طریقے سے انسٹال کرتا ہے۔ بدقسمتی سے، ونڈوز ایکس پی کے ساتھ مطابقت برقرار رکھنے کے لیے بہت سی ڈرائیوز اپنے سیکٹر کے سائز کے بارے میں جھوٹ بولتی ہیں (جو دوسرے سیکٹر کے سائز کے ساتھ ڈرائیوز کو سمجھنے سے قاصر تھی)۔

اس کا مطلب یہ ہے کہ ZFS منتظم کو سختی سے مشورہ دیا جاتا ہے کہ وہ اپنے آلات کے اصل سیکٹر سائز کو جانیں اور دستی طور پر سیٹ کریں۔ ashift. اگر شفٹ کو بہت کم سیٹ کیا جاتا ہے، تو پڑھنے/لکھنے کی کارروائیوں کی تعداد فلکیاتی طور پر بڑھ جاتی ہے۔ لہذا، 512 بائٹ کے "سیکٹرز" کو حقیقی 4 KiB سیکٹر میں لکھنے کا مطلب ہے کہ پہلے "سیکٹر" کو لکھنا ہوگا، پھر 4 KiB سیکٹر کو پڑھیں، دوسرے 512-بائٹ "سیکٹر" کے ساتھ اس میں ترمیم کریں، اسے واپس نئے پر لکھیں۔ 4 KiB سیکٹر، اور اسی طرح ہر اندراج کے لیے۔

حقیقی دنیا میں، اس طرح کی سزا Samsung EVO SSDs کو لگتی ہے، جس کے لیے ashift=13، لیکن یہ SSDs اپنے سیکٹر کے سائز کے بارے میں جھوٹ بولتے ہیں، اور اس لیے پہلے سے طے شدہ سیٹ ہے۔ ashift=9. اگر ایک تجربہ کار سسٹم ایڈمنسٹریٹر اس ترتیب کو تبدیل نہیں کرتا ہے، تو یہ SSD کام کرتا ہے۔ آہستہ روایتی مقناطیسی HDD

مقابلے کے لیے، بہت بڑے سائز کے لیے ashift عملی طور پر کوئی سزا نہیں ہے. کارکردگی کا کوئی حقیقی جرمانہ نہیں ہے، اور غیر استعمال شدہ جگہ میں اضافہ لامحدود ہے (یا کمپریشن فعال ہونے کے ساتھ صفر)۔ لہذا، ہم پرزور مشورہ دیتے ہیں کہ وہ ڈرائیوز بھی انسٹال کریں جو 512 بائٹ سیکٹر استعمال کرتی ہیں۔ ashift=12 یا یہاں تک کہ ashift=13اعتماد کے ساتھ مستقبل کا سامنا کرنا۔

پراپرٹی ashift ہر vdev ورچوئل ڈیوائس کے لیے سیٹ کیا گیا ہے، اور پول کے لئے نہیں، جیسا کہ بہت سے لوگ غلطی سے سوچتے ہیں - اور انسٹالیشن کے بعد تبدیل نہیں ہوتا ہے۔ اگر آپ نے غلطی سے مارا۔ ashift جب آپ کسی پول میں ایک نیا وی ڈی وی شامل کرتے ہیں، تو آپ نے اس پول کو کم کارکردگی والے آلے کے ساتھ ناقابل تلافی طور پر آلودہ کر دیا ہے اور عام طور پر پول کو تباہ کرنے اور دوبارہ شروع کرنے کے علاوہ کوئی چارہ نہیں ہوتا ہے۔ یہاں تک کہ vdev کو ہٹانا بھی آپ کو ٹوٹی ہوئی ترتیب سے نہیں بچائے گا۔ ashift!

کاپی پر لکھنے کا طریقہ کار

اگر ایک باقاعدہ فائل سسٹم کو ڈیٹا کو اوور رائٹ کرنے کی ضرورت ہوتی ہے، تو یہ ہر بلاک کو تبدیل کرتا ہے جہاں یہ ہے۔

کاپی آن رائٹ فائل سسٹم ایک نیا بلاک ورژن لکھتا ہے اور پھر پرانے ورژن کو کھول دیتا ہے۔

خلاصہ میں، اگر ہم بلاکس کے اصل جسمانی مقام کو نظر انداز کرتے ہیں، تو ہمارا "ڈیٹا دومکیت" ایک "ڈیٹا ورم" میں آسان ہو جاتا ہے جو دستیاب جگہ کے نقشے پر بائیں سے دائیں حرکت کرتا ہے۔

اب ہم اچھی طرح سے اندازہ لگا سکتے ہیں کہ کاپی آن رائٹ اسنیپ شاٹس کیسے کام کرتے ہیں - ہر بلاک کا تعلق متعدد سنیپ شاٹس سے ہو سکتا ہے، اور اس وقت تک برقرار رہے گا جب تک کہ تمام متعلقہ سنیپ شاٹس تباہ نہیں ہو جاتے۔

کاپی آن رائٹ (CoW) میکانزم اس کی بنیادی بنیاد ہے جو ZFS کو ایسا حیرت انگیز نظام بناتا ہے۔ بنیادی تصور سادہ ہے - اگر آپ روایتی فائل سسٹم سے فائل کو تبدیل کرنے کے لیے کہیں گے، تو یہ وہی کرے گا جو آپ نے پوچھا ہے۔ اگر آپ کاپی آن رائٹ فائل سسٹم سے ایسا کرنے کو کہیں گے تو وہ کہے گا "ٹھیک ہے" لیکن آپ سے جھوٹ بولے گا۔

اس کے بجائے، ایک کاپی آن رائٹ فائل سسٹم ترمیم شدہ بلاک کا ایک نیا ورژن لکھتا ہے اور پھر فائل کے میٹا ڈیٹا کو اپ ڈیٹ کرتا ہے تاکہ پرانے بلاک کا لنک ختم کیا جا سکے اور اس نئے بلاک کو منسلک کیا جا سکے جسے آپ نے ابھی لکھا ہے۔

پرانے بلاک کو الگ کرنا اور نئے کو جوڑنا ایک آپریشن میں کیا جاتا ہے، اس لیے اس میں خلل نہیں ڈالا جا سکتا ہے - اگر آپ ایسا ہونے کے بعد پاور ڈاؤن کرتے ہیں، تو آپ کے پاس فائل کا نیا ورژن ہے، اور اگر آپ جلدی سے پاور ڈاؤن کرتے ہیں، تو آپ کے پاس پرانا ورژن ہے۔ . کسی بھی صورت میں، فائل سسٹم میں کوئی تنازعہ نہیں ہوگا۔

ZFS میں کاپی آن رائٹ نہ صرف فائل سسٹم کی سطح پر ہوتی ہے بلکہ ڈسک مینجمنٹ کی سطح پر بھی ہوتی ہے۔ اس کا مطلب ہے کہ ZFS سفید جگہ سے متاثر نہیں ہوتا ہے (RAID میں ایک سوراخ) - ایک ایسا واقعہ جب پٹی کے پاس سسٹم کے کریش ہونے سے پہلے صرف جزوی طور پر ریکارڈ کرنے کا وقت ہوتا تھا، ریبوٹ کے بعد سرنی کو پہنچنے والے نقصان کے ساتھ۔ یہاں پٹی کو جوہری طور پر لکھا جاتا ہے، vdev ہمیشہ ترتیب وار ہوتا ہے، اور باب آپ کے چچا ہیں۔.

ZIL: ZFS ارادے کا لاگ

ZFS سسٹم ہم وقت ساز تحریروں کو ایک خاص طریقے سے دیکھتا ہے - یہ عارضی طور پر لیکن فوری طور پر انہیں ZIL میں محفوظ کر لیتا ہے اس سے پہلے کہ انہیں مستقل طور پر غیر مطابقت پذیر تحریروں کے ساتھ لکھیں۔

عام طور پر، ZIL کو لکھا گیا ڈیٹا دوبارہ کبھی نہیں پڑھا جاتا ہے۔ لیکن یہ سسٹم کریش کے بعد ممکن ہے۔

SLOG، یا ثانوی LOG ڈیوائس، صرف ایک خاص ہے - اور ترجیحا بہت تیز - vdev، جہاں ZIL کو مرکزی اسٹوریج سے الگ ذخیرہ کیا جا سکتا ہے۔

حادثے کے بعد، ZIL میں تمام گندا ڈیٹا دوبارہ چلایا جاتا ہے - اس صورت میں، ZIL SLOG پر ہے، لہذا اسے وہاں سے دوبارہ چلایا جاتا ہے

تحریری کارروائیوں کی دو اہم قسمیں ہیں - ہم وقت ساز (مطابقت پذیر) اور غیر مطابقت پذیر (async)۔ زیادہ تر کام کے بوجھ کے لیے، تحریروں کی اکثریت غیر مطابقت پذیر ہوتی ہے - فائل سسٹم انھیں جمع کرنے اور بیچوں میں جاری کرنے کی اجازت دیتا ہے، جس سے ٹکڑے ٹکڑے ہونے میں کمی آتی ہے اور تھرو پٹ میں بہت زیادہ اضافہ ہوتا ہے۔

مطابقت پذیر ریکارڈنگ ایک بالکل مختلف معاملہ ہے۔ جب کوئی ایپلیکیشن ہم وقت ساز تحریر کی درخواست کرتی ہے، تو یہ فائل سسٹم کو بتاتی ہے: "آپ کو یہ غیر متزلزل میموری کے ساتھ کرنے کی ضرورت ہے۔ ابھیتب تک میں اور کچھ نہیں کر سکتا۔" اس لیے، ہم وقت ساز تحریروں کو فوری طور پر ڈسک کے لیے پابند کیا جانا چاہیے — اور اگر اس سے فریگمنٹیشن میں اضافہ ہوتا ہے یا تھرو پٹ کم ہوتا ہے، تو ایسا ہی ہو۔

ZFS ہم وقت ساز تحریروں کو باقاعدہ فائل سسٹم سے مختلف طریقے سے ہینڈل کرتا ہے — انہیں فوری طور پر باقاعدہ اسٹوریج میں بھیجنے کے بجائے، ZFS انہیں ZFS Intent Log، یا ZIL نامی ایک خاص اسٹوریج ایریا میں بھیجتا ہے۔ چال یہ ہے کہ یہ ریکارڈ بھی میموری میں رہیں، عام غیر مطابقت پذیر تحریری درخواستوں کے ساتھ جمع ہونے کے بعد، بعد میں بالکل عام TXGs (ٹرانزیکشن گروپس) کے طور پر اسٹوریج میں فلش کیا جائے گا۔

عام آپریشن میں، ZIL کو لکھا جاتا ہے اور دوبارہ کبھی نہیں پڑھا جاتا ہے۔ جب، چند لمحوں کے بعد، ZIL کے ریکارڈز RAM سے عام TXGs میں مرکزی اسٹوریج کے لیے پرعزم ہوتے ہیں، تو وہ ZIL سے الگ ہو جاتے ہیں۔ ZIL سے صرف اس وقت کچھ پڑھا جاتا ہے جب پول درآمد کیا جاتا ہے۔

اگر ZFS ناکام ہوجاتا ہے - آپریٹنگ سسٹم کا کریش یا بجلی کی بندش - جب کہ ZIL میں ڈیٹا موجود ہے، وہ ڈیٹا اگلے پول امپورٹ کے دوران پڑھا جائے گا (مثال کے طور پر، جب ایمرجنسی سسٹم دوبارہ شروع ہوتا ہے)۔ ZIL میں موجود کچھ بھی پڑھا جائے گا، TXGs میں گروپ کیا جائے گا، مرکزی اسٹوریج کے لیے پابند کیا جائے گا، اور پھر درآمدی عمل کے دوران ZIL سے الگ کر دیا جائے گا۔

vdev مددگار کلاسوں میں سے ایک کو LOG یا SLOG کہا جاتا ہے، LOG کا ثانوی آلہ۔ اس کا ایک مقصد ہے - ZIL کو مرکزی vdev سٹور پر ذخیرہ کرنے کے بجائے، پول کو ایک علیحدہ، اور ترجیحی طور پر بہت تیز، بہت لکھنے کے لیے مزاحم vdev فراہم کرنا۔ ZIL خود ایک جیسا برتاؤ کرتا ہے اس سے کوئی فرق نہیں پڑتا ہے کہ اسے کہاں ذخیرہ کیا گیا ہے، لیکن اگر LOG vdev کی تحریری کارکردگی بہت زیادہ ہے تو ہم وقت ساز تحریریں تیز تر ہوں گی۔

پول میں LOG کے ساتھ vdev شامل کرنا کام نہیں کرتا ہے۔ نہیں کر سکتا غیر مطابقت پذیر تحریری کارکردگی کو بہتر بنائیں - یہاں تک کہ اگر آپ ZIL کو تمام لکھنے پر مجبور کرتے ہیں۔ zfs set sync=always، وہ اب بھی TXG میں مرکزی اسٹوریج سے اسی طرح اور اسی رفتار سے منسلک ہوں گے جیسے لاگ کے بغیر۔ صرف براہ راست کارکردگی میں بہتری مطابقت پذیر تحریروں کی تاخیر ہے (کیونکہ تیزی سے لاگ ان کارروائیوں کو تیز کرتا ہے)۔ sync).

تاہم، ایک ایسے ماحول میں جس میں پہلے سے ہی بہت زیادہ مطابقت پذیر تحریروں کی ضرورت ہوتی ہے، vdev LOG بالواسطہ طور پر غیر مطابقت پذیر تحریروں اور غیر کیشڈ ریڈز کو تیز کر سکتا ہے۔ ZIL اندراجات کو علیحدہ vdev LOG میں آف لوڈ کرنے کا مطلب ہے کہ بنیادی اسٹوریج پر IOPS کے لیے کم تنازعہ، جو تمام پڑھنے اور لکھنے کی کارکردگی کو کسی حد تک بہتر بناتا ہے۔

سنیپ شاٹس

کاپی آن رائٹ میکانزم ZFS ایٹمک اسنیپ شاٹس اور انکریمنٹل غیر مطابقت پذیر نقل کے لیے بھی ایک ضروری بنیاد ہے۔ ایکٹو فائل سسٹم میں ایک پوائنٹر ٹری ہے جو تمام ریکارڈز کو موجودہ ڈیٹا کے ساتھ نشان زد کرتا ہے - جب آپ اسنیپ شاٹ لیتے ہیں، تو آپ صرف اس پوائنٹر ٹری کی ایک کاپی بناتے ہیں۔

جب ایکٹو فائل سسٹم پر ریکارڈ کو اوور رائٹ کیا جاتا ہے، ZFS پہلے نئے بلاک ورژن کو غیر استعمال شدہ جگہ پر لکھتا ہے۔ اس کے بعد یہ موجودہ فائل سسٹم سے بلاک کے پرانے ورژن کو الگ کر دیتا ہے۔ لیکن اگر کچھ سنیپ شاٹ پرانے بلاک کی طرف اشارہ کرتا ہے، یہ اب بھی کوئی تبدیلی نہیں ہے. پرانے بلاک کو اس وقت تک خالی جگہ کے طور پر بحال نہیں کیا جائے گا جب تک کہ اس بلاک کا حوالہ دینے والے تمام اسنیپ شاٹس کو تباہ نہ کر دیا جائے!

نقل۔

2015 میں میری سٹیم لائبریری 158 GiB تھی اور اس میں 126 فائلیں شامل تھیں۔ یہ rsync کے لیے بہترین صورتحال کے بالکل قریب ہے - نیٹ ورک پر ZFS کی نقل "صرف" 927% تیز تھی۔

اسی نیٹ ورک پر، ایک واحد 40GB ونڈوز 7 ورچوئل مشین امیج فائل کو نقل کرنا بالکل مختلف کہانی ہے۔ ZFS نقل rsync سے 289 گنا تیز ہے - یا "صرف" 161 گنا تیز ہے اگر آپ --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، اور پھر ان بلاکس میں پوائنٹر شامل کریں۔ Voila، ہمارے پاس ہے @2 نئے نظام میں!

ZFS غیر سنکرونس انکریمنٹل ریپلیکیشن پہلے کے نان اسنیپ شاٹ پر مبنی طریقوں جیسے rsync کے مقابلے میں ایک بہت بڑی بہتری ہے۔ دونوں صورتوں میں، صرف تبدیل شدہ ڈیٹا منتقل کیا جاتا ہے - لیکن پہلے rsync ضروری ہے۔ پڑھیں ڈسک سے دونوں اطراف کے تمام ڈیٹا کو چیک کریں اور اس کا موازنہ کریں۔ اس کے برعکس، ZFS ریپلیکشن پوائنٹر ٹری کے علاوہ کچھ نہیں پڑھتا ہے - اور کوئی بھی بلاکس جو مشترکہ اسنیپ شاٹ میں موجود نہیں ہیں۔

بلٹ ان کمپریشن

کاپی آن رائٹ میکانزم ان لائن کمپریشن سسٹم کو بھی آسان بناتا ہے۔ روایتی فائل سسٹم میں، کمپریشن مشکل ہے - پرانا ورژن اور ترمیم شدہ ڈیٹا کا نیا ورژن دونوں ایک ہی جگہ پر رہتے ہیں۔

اگر ہم کسی فائل کے بیچ میں موجود ڈیٹا کے ایک ٹکڑے پر غور کریں جو 0x00000000 سے صفر کے میگا بائٹ کے طور پر زندگی شروع کرتا ہے اور اسی طرح، اسے ڈسک کے ایک سیکٹر میں کمپریس کرنا بہت آسان ہے۔ لیکن کیا ہوتا ہے اگر ہم زیرو کے اس میگا بائٹ کو JPEG یا چھدم بے ترتیب شور جیسے ناقابل تسخیر ڈیٹا کے میگا بائٹ سے بدل دیں؟ غیر متوقع طور پر، ڈیٹا کے اس میگا بائٹ کے لیے ایک نہیں بلکہ 256 4 KiB سیکٹرز کی ضرورت ہوگی، اور اس جگہ ڈسک پر صرف ایک سیکٹر محفوظ ہے۔

ZFS کو یہ مسئلہ نہیں ہے، کیونکہ ترمیم شدہ ریکارڈ ہمیشہ غیر استعمال شدہ جگہ پر لکھے جاتے ہیں - اصل بلاک صرف ایک 4 KiB سیکٹر پر قبضہ کرتا ہے، اور نیا ریکارڈ 256 پر قبضہ کرے گا، لیکن یہ کوئی مسئلہ نہیں ہے - ایک حال ہی میں ترمیم شدہ ٹکڑا " فائل کے درمیان" کو غیر استعمال شدہ جگہ پر لکھا جائے گا قطع نظر اس کے کہ اس کا سائز تبدیل ہوا ہے یا نہیں، لہذا ZFS کے لیے یہ کافی معمول کی صورتحال ہے۔

مقامی ZFS کمپریشن بطور ڈیفالٹ غیر فعال ہے، اور سسٹم پلگ ایبل الگورتھم پیش کرتا ہے—فی الحال LZ4، gzip (1-9)، LZJB، اور ZLE۔

• LZ4 ایک اسٹریمنگ الگورتھم ہے جو انتہائی تیز کمپریشن اور ڈیکمپریشن اور زیادہ تر استعمال کے معاملات کے لیے کارکردگی کے فوائد پیش کرتا ہے - یہاں تک کہ کافی سست CPUs پر بھی۔
• GZIP ایک قابل احترام الگورتھم ہے جسے یونکس کے تمام صارفین جانتے اور پسند کرتے ہیں۔ اسے کمپریشن لیول 1-9 کے ساتھ لاگو کیا جا سکتا ہے، کمپریشن ریشو اور سی پی یو کے استعمال میں اضافہ کے ساتھ جب یہ سطح 9 کے قریب پہنچتا ہے۔ الگورتھم تمام ٹیکسٹ (یا دیگر انتہائی کمپریسیبل) استعمال کے معاملات کے لیے موزوں ہے، لیکن دوسری صورت میں اکثر سی پی یو کے مسائل کا سبب بنتا ہے - اسے استعمال کریں۔ دیکھ بھال کے ساتھ، خاص طور پر اعلی سطحوں پر۔
• ایل زیڈ جے بی ZFS میں اصل الگورتھم ہے۔ یہ متروک ہے اور اسے مزید استعمال نہیں کیا جانا چاہیے، LZ4 اسے ہر طرح سے پیچھے چھوڑ دیتا ہے۔
• بری طرح - زیرو لیول انکوڈنگ، زیرو لیول انکوڈنگ۔ یہ عام ڈیٹا کو بالکل نہیں چھوتا، لیکن زیرو کے بڑے سلسلے کو کمپریس کرتا ہے۔ مکمل طور پر ناقابل استعمال ڈیٹا سیٹس (جیسے JPEG، MP4، یا دیگر پہلے سے کمپریس شدہ فارمیٹس) کے لیے مفید ہے کیونکہ یہ ناقابل استعمال ڈیٹا کو نظر انداز کرتا ہے لیکن نتیجے میں ریکارڈ میں غیر استعمال شدہ جگہ کو کمپریس کرتا ہے۔

ہم تقریباً تمام استعمال کے معاملات کے لیے LZ4 کمپریشن کی تجویز کرتے ہیں۔ ناقابل تسخیر ڈیٹا کا سامنا کرنے پر کارکردگی کا جرمانہ بہت چھوٹا ہے، اور حاصل عام ڈیٹا کے لیے کارکردگی اہم ہے۔ ونڈوز آپریٹنگ سسٹم کی نئی انسٹالیشن کے لیے ورچوئل مشین امیج کو کاپی کرنا (تازہ انسٹال کردہ OS، ابھی تک کوئی ڈیٹا نہیں ہے) compression=lz4 کے مقابلے میں 27 فیصد تیزی سے گزر گیا۔ compression=noneمیں یہ ٹیسٹ 2015 میں.

ARC - انکولی متبادل کیش

ZFS وہ واحد جدید فائل سسٹم ہے جس کے بارے میں ہم جانتے ہیں کہ RAM میں حال ہی میں پڑھے گئے بلاکس کی کاپیاں ذخیرہ کرنے کے لیے آپریٹنگ سسٹم کے صفحہ کیش پر انحصار کرنے کے بجائے اس کا اپنا ریڈ کیشنگ میکانزم استعمال کرتا ہے۔

اگرچہ مقامی کیشے اس کے مسائل کے بغیر نہیں ہے - ZFS نئی میموری مختص کرنے کی درخواستوں کا جواب دانا کی طرح جلدی نہیں دے سکتا، لہذا نیا چیلنج malloc() میموری مختص کرنے میں ناکام ہو سکتا ہے اگر اسے فی الحال ARC کے زیر قبضہ RAM کی ضرورت ہو۔ لیکن کم از کم ابھی کے لیے آپ کے اپنے کیشے کو استعمال کرنے کی اچھی وجوہات ہیں۔

تمام معروف جدید آپریٹنگ سسٹمز، بشمول MacOS، Windows، Linux اور BSD، صفحہ کیش کو نافذ کرنے کے لیے LRU (Least Recently Used) الگورتھم کا استعمال کرتے ہیں۔ یہ ایک قدیم الگورتھم ہے جو ہر پڑھنے کے بعد کیش شدہ بلاک کو "قطار کے اوپر" دھکیلتا ہے، اور نئے کیش مسز (بلاکس جنہیں ڈسک سے پڑھنا چاہیے تھا، کیشے سے نہیں) شامل کرنے کے لیے ضرورت کے مطابق بلاکس کو "قطار سے نیچے" دھکیلتا ہے۔ اوپر

الگورتھم عام طور پر ٹھیک کام کرتا ہے، لیکن بڑے کام کرنے والے ڈیٹاسیٹس والے سسٹمز پر، LRU آسانی سے تھریشنگ کا باعث بنتا ہے - بلاکس کے لیے جگہ بنانے کے لیے اکثر درکار بلاکس کو نکالنا جو دوبارہ کبھی کیشے سے نہیں پڑھے جائیں گے۔

آر آر سی ایک بہت ہی کم بولی الگورتھم ہے جس کے بارے میں سوچا جا سکتا ہے "وزن والے" کیشے۔ ہر بار جب ایک کیشڈ بلاک پڑھا جاتا ہے، تو اسے تھوڑا سا "بھاری" اور نکالنا مشکل ہو جاتا ہے - اور بلاک کو بے دخل کرنے کے بعد بھی ٹریک کیا وقت کی ایک مخصوص مدت کے اندر. ایک بلاک جسے بے دخل کر دیا گیا ہے لیکن پھر اسے دوبارہ کیشے میں پڑھنے کی ضرورت ہے وہ بھی "بھاری" ہو جائے گا۔

اس سب کا حتمی نتیجہ ایک کیش ہے جس میں بہت زیادہ ہٹ تناسب ہوتا ہے، کیش ہٹ (کیشے سے پڑھا جاتا ہے) اور کیش مسز (ڈسک سے پڑھا جاتا ہے) کے درمیان تناسب۔ یہ ایک انتہائی اہم اعدادوشمار ہے - نہ صرف کیش ہٹس نے خود ہی تیز رفتاری کے آرڈرز پیش کیے ہیں، بلکہ کیش مسز بھی تیزی سے پیش کیے جا سکتے ہیں، کیونکہ جتنی زیادہ کیش ہٹ ہوں گی، کم کنکرنٹ ڈسک کی درخواستیں اور ان باقی رہ جانے والوں کے لیے لیٹنسی اتنی ہی کم ہوگی۔ ڈسک کے ساتھ پیش کیا جائے۔

حاصل يہ ہوا

ZFS کی بنیادی اصطلاحات سیکھنے کے بعد - کاپی آن رائٹ کیسے کام کرتا ہے، نیز اسٹوریج پولز، ورچوئل ڈیوائسز، بلاکس، سیکٹرز اور فائلوں کے درمیان تعلقات - ہم حقیقی نمبروں کے ساتھ حقیقی دنیا کی کارکردگی پر بات کرنے کے لیے تیار ہیں۔

اگلے حصے میں، ہم عکس والے vdevs اور RAIDz کے ساتھ پولز کی اصل کارکردگی پر ایک نظر ڈالیں گے، ایک دوسرے کے مقابلے میں، اور ساتھ ہی روایتی لینکس کرنل RAID ٹوپولاجیز جن کی ہم نے دریافت کی ہے۔ پہلے.

سب سے پہلے، ہم صرف بنیادی باتوں کا احاطہ کرنا چاہتے تھے - خود ZFS ٹوپولاجیز - لیکن بعد میں اس طرح آئیے ZFS کے مزید جدید سیٹ اپ اور ٹیوننگ کے بارے میں بات کرنے کے لیے تیار ہو جائیں، بشمول معاون vdev قسموں جیسے L2ARC، SLOG اور اسپیشل ایلوکیشن کا استعمال۔

ماخذ: www.habr.com