RAID 6.2/5 کے نفاذ میں "رائٹ ہول" کے مسئلے کو حل کرنے کے لیے لینکس 6 کرنل میں شامل کرنے کے لیے Btrfs میں بہتری کی تجویز ہے۔ مسئلہ کا نچوڑ اس حقیقت پر ابلتا ہے کہ اگر ریکارڈنگ کے دوران کوئی حادثہ پیش آیا، تو ابتدائی طور پر یہ سمجھنا ناممکن ہے کہ RAID ڈیوائسز میں سے کس بلاک پر صحیح لکھا گیا تھا، اور کس میں ریکارڈنگ مکمل نہیں ہوئی تھی۔ اگر آپ اس صورت حال میں RAID کو دوبارہ بنانے کی کوشش کرتے ہیں، تو انڈر رائٹ بلاکس کے مساوی بلاکس خراب ہوسکتے ہیں کیونکہ RAID بلاکس کی حالت مطابقت پذیر نہیں ہے۔ یہ مسئلہ کسی بھی RAID1/5/6 صفوں میں ہوتا ہے جہاں اس اثر سے نمٹنے کے لیے خصوصی اقدامات نہیں کیے جاتے ہیں۔
btrfs میں RAID1 جیسے RAID کے نفاذ میں، یہ مسئلہ دونوں کاپیوں پر چیکسم کے استعمال سے حل کیا جاتا ہے، اگر کوئی مماثلت نہیں ہے، تو ڈیٹا کو دوسری کاپی سے بحال کیا جاتا ہے۔ یہ نقطہ نظر اس وقت بھی کام کرتا ہے جب کچھ ڈیوائس مکمل ناکامی کے بجائے غلط ڈیٹا دینا شروع کر دیتی ہے۔
تاہم، RAID5/6 کی صورت میں، فائل سسٹم پیریٹی بلاکس کے لیے چیکسم کو ذخیرہ نہیں کرتا ہے: ایک عام صورت حال میں، بلاکس کی درستگی کی جانچ پڑتال اس حقیقت سے کی جاتی ہے کہ وہ تمام چیکسم سے لیس ہیں، اور برابری بلاک کر سکتے ہیں۔ ڈیٹا سے دوبارہ بنایا جائے۔ تاہم، جزوی ریکارڈنگ کی صورت میں، یہ نقطہ نظر بعض حالات میں کام نہیں کر سکتا۔ اس صورت میں، سرنی کو بحال کرتے وقت، یہ ممکن ہے کہ نامکمل ریکارڈ کے نیچے گرے ہوئے بلاکس کو غلط طریقے سے بحال کیا جائے۔
btrfs کے معاملے میں، یہ مسئلہ سب سے زیادہ متعلقہ ہے اگر تیار کی جانے والی تحریر پٹی سے چھوٹی ہو۔ اس صورت میں، فائل سسٹم کو ریڈ-موڈیف-رائٹ (RMW) آپریشن کرنا چاہیے۔ اگر اس کو رائٹ ان پروگریس بلاکس کا سامنا کرنا پڑتا ہے، تو RMW آپریشن بدعنوانی کا سبب بن سکتا ہے جن کا پتہ نہیں چل سکے گا، چاہے چیکسم کچھ بھی ہوں۔ ڈویلپرز نے تبدیلیاں کی ہیں جس میں RMW آپریشن اس آپریشن کو انجام دینے سے پہلے بلاکس کے چیک سم کو چیک کرتا ہے، اور اگر ضروری ہو تو، ڈیٹا ریکوری لکھنے کے بعد ایک چیکسم چیک بھی کرتا ہے۔ بدقسمتی سے، ایک نامکمل پٹی (RMW) لکھنے کی صورت حال میں، یہ چیکسم کا حساب لگانے کے لیے اضافی اوور ہیڈ کا باعث بنتا ہے، لیکن قابل اعتبار حد تک بڑھ جاتا ہے۔ RAID6 کے لیے، ایسی منطق ابھی تک تیار نہیں ہے، تاہم، RAID6 میں اس طرح کی ناکامی کے لیے ضروری ہے کہ رائٹ ایک ساتھ 2 ڈیوائسز پر فیل ہو جائے، جس کا امکان کم ہے۔
مزید برآں، ہم ڈویلپرز کی جانب سے RAID5/6 کے استعمال سے متعلق سفارشات کو نوٹ کر سکتے ہیں، جس کا خلاصہ یہ ہے کہ Btrfs میں میٹا ڈیٹا اور ڈیٹا کو ذخیرہ کرنے کے لیے پروفائل مختلف ہو سکتے ہیں۔ اس صورت میں، آپ میٹا ڈیٹا کے لیے RAID1 (آئینہ) یا یہاں تک کہ RAID1C3 (3 کاپیاں) پروفائل، اور ڈیٹا کے لیے RAID5 یا RAID6 استعمال کر سکتے ہیں۔ یہ ایک طرف میٹا ڈیٹا کے قابل اعتماد تحفظ اور "رائٹ ہول" کی عدم موجودگی کو یقینی بناتا ہے، اور دوسری طرف RAID5/6 کے لیے مخصوص جگہ کا زیادہ موثر استعمال۔ یہ میٹا ڈیٹا میں بدعنوانی سے بچتا ہے، اور ڈیٹا کی بدعنوانی کو درست کیا جا سکتا ہے۔
یہ بھی نوٹ کیا جا سکتا ہے کہ 6.2 کرنل میں Btrfs میں SSDs کے لیے، "ڈسکارڈ" آپریشن (آزاد بلاکس کو نشان زد کرنا جو کہ اب جسمانی طور پر ذخیرہ نہیں کیا جا سکتا) کا غیر مطابقت پذیر عمل بطور ڈیفالٹ چالو ہو جائے گا۔ اس موڈ کا فائدہ ایک قطار میں "ڈسکارڈ" آپریشنز کی موثر گروپ بندی اور بیک گراؤنڈ ہینڈلر کے ذریعہ قطار کی مزید پروسیسنگ کی وجہ سے اعلی کارکردگی ہے، جس کی وجہ سے عام FS آپریشنز سست نہیں ہوتے، جیسا کہ ہم آہنگی کے ساتھ ہوتا ہے۔ ڈسکارڈ" کے طور پر بلاکس کو آزاد کیا جاتا ہے، اور SSD بہتر فیصلے کر سکتا ہے۔ دوسری طرف، آپ کو اب fstrim جیسی افادیت استعمال کرنے کی ضرورت نہیں ہوگی، کیونکہ تمام دستیاب بلاکس کو FS میں بغیر اضافی اسکیننگ کی ضرورت کے اور کام کو سست کیے بغیر صاف کر دیا جائے گا۔
ماخذ: opennet.ru