Reiser4 فائل سسٽم جي ڊولپر، ايڊورڊ شيشڪن سان ٻيو انٽرويو شايع ڪيو ويو آهي.
شروع ڪرڻ لاءِ، مهرباني ڪري پڙهندڙن کي ياد ڏياريو ته توهان ڪٿي ۽ ڪنهن لاءِ ڪم ڪندا آهيو.
مان Huawei Technologies، جرمن ريسرچ سينٽر ۾ پرنسپل اسٽوريج آرڪيٽيڪٽ طور ڪم ڪريان ٿو. ورچوئلائيزيشن ڊپارٽمينٽ ۾ آئون ڊيٽا اسٽوريج جي مختلف حصن سان معاملو ڪريان ٿو. منهنجون سرگرميون ڪنهن مخصوص آپريٽنگ سسٽم سان لاڳاپيل نه آهن.
ڇا توهان في الحال مکيه ڪنييل شاخ ڏانهن ڪم ڪري رهيا آهيو؟
تمام گھٽ، ۽ صرف جيڪڏھن منھنجي آجر کي ضرورت آھي. آخري وقت اٽڪل ٽي سال اڳ هو، مون 9p پروٽوڪول استعمال ڪندي ميزبانن تي شيئر ڪيل اسٽوريج لاءِ ان پٽ کي وڌائڻ لاءِ پيچ موڪليا (هن ڪاروبار جو ٻيو نالو VirtFS آهي). هتي هڪ اهم نوٽ ڪرڻ گهرجي: جيتوڻيڪ مان لينڪس سان گهڻي عرصي کان ڪم ڪري رهيو آهيان، مان ڪڏهن به ان جو پرستار نه رهيو آهيان، اهو آهي، مان "سانس سان گڏ"، جيئن هر شيء سان. خاص طور تي، جيڪڏهن مون کي ڪا نقص محسوس ٿئي، ته مان ان کي هڪ ڀيرو ئي اشارو ڪري سگهان ٿو. ۽ انهي ڪري ته توهان وري ڪنهن جي پيروي ڪري سگهو ٿا ۽ انهن کي قائل ڪري سگهو ٿا - اهو نه ٿيندو.
مون کي ياد آهي آخري ڀيرو، ڏهه سال اڳ، توهان ڪيني ڊولپمينٽ انداز جي ڪافي تنقيدي هئي. توهان جي (يا شايد ڪارپوريٽ) نقطه نظر کان، ڇا ڪجهه تبديل ٿيو آهي، ڇا ڪميونٽي وڌيڪ جوابدار بڻجي وئي آهي يا نه؟ جيڪڏهن نه، توهان سوچيو ته ڪير ذميوار آهي؟
مون ڪڏهن به بهتر لاءِ ڪا تبديلي نه ڏٺي. سماج جو بنيادي مسئلو سائنس کي سياسي ٽيڪنالاجي، ذاتي رشتن، اڪثريت جي راءِ، پاپولزم، ”اندروني آوازن“ جي صلاحن، سڙيل سمجھوتن، سائنس کان سواءِ هر شيءِ سان تبديل ڪرڻ آهي. ڪمپيوٽر سائنس، جيڪو ڪجهه به چئي سگهي ٿو، سڀ کان پهرين ۽ سڀ کان پهرين هڪ صحيح سائنس آهي. ۽ جيڪڏهن ڪو ماڻهو 2x2 لاءِ پنهنجي قيمت جو اعلان ڪرڻ شروع ڪري ٿو، 4 کان مختلف، ”لينڪس واٽ“ جي پرچم هيٺ، يا ڪنهن ٻئي پرچم هيٺ، ته پوءِ اهو ممڪن ناهي ته نقصان کان سواءِ ٻيو ڪجهه به آڻي.
سڀ مشڪلاتون بنيادي طور تي فيصلا ڪرڻ وارن جي نااهلي ۽ تعليم جي کوٽ سبب آهن. جيڪڏهن مينيجر نااهل آهي، هو هڪ مقصد، مناسب فيصلو ڪرڻ جي قابل ناهي. جيڪڏهن هو غير ثقافتي پڻ آهي، ته هو هڪ قابل ماهر ڳولڻ جي قابل نه آهي جيڪو هن کي صحيح مشورو ڏيندو. هڪ اعلي امڪان سان، چونڊ هڪ اسڪيمر تي ٿيندي، جيڪو چوي ٿو "بظاهر صحيح شيون." هڪ خراب ماحول هميشه نااهل اڪيلو اڳواڻن جي چوڌاري پيدا ٿئي ٿو. ان کان علاوه، تاريخ ان سلسلي ۾ ڪو به استثنا نه ٿو ڄاڻي، ۽ ڪميونٽي ان جي واضح تصديق آهي.
توهان Btrfs جي ترقي ۾ ترقي ڪيئن اندازو لڳايو ٿا؟ ڇا هي ايف ايس ٻارن جي بيمارين کان نجات حاصل ڪئي؟ توهان ان کي پنهنجي لاءِ ڪيئن رکو ٿا - هڪ FS ”گهر لاءِ“ يا ڪارپوريٽ استعمال لاءِ پڻ؟
مون کي ان مان نجات حاصل نه ڪيو. هر شيءِ جنهن جو مون 11 سال اڳ ذڪر ڪيو هو اڄ به لاڳاپيل آهي. Btrfs جي مسئلن مان هڪ آهي جيڪا ان کي سنجيده ضرورتن لاءِ نا مناسب بڻائي ٿي خالي جاءِ جو مسئلو. مان ان حقيقت جي باري ۾ به نه ڳالهائي رهيو آهيان ته صارف کي چيو ويو آهي ته اسٽور ڏانهن هلڻ لاءِ نئين ڊسڪ جي حالتن ۾ جتي ٻيو ڪو FS ڏيکاريندو ورهاڱي تي تمام گهڻي خالي جاءِ. خالي جاءِ جي کوٽ جي ڪري منطقي مقدار تي آپريشن مڪمل ڪرڻ جي ناڪامي به بدترين شيءِ ناهي. بدترين شيء اها آهي ته هڪ غير امتيازي صارف تقريبا هميشه ڪري سگهي ٿو، ڪنهن به ڊسڪ ڪوٽا کي نظرانداز ڪري، هر ڪنهن کي ٿوري وقت ۾ مفت جاء کان محروم ڪري ٿو.
اهو ڏسڻ جهڙو آهي (لينڪس ڪنييل 5.12 لاءِ آزمايل). تازو نصب ٿيل سسٽم تي هڪ اسڪرپٽ شروع ڪئي وئي آهي، جيڪا لوپ ۾ گهر ڊاريڪٽري ۾ ڪجهه نالن سان فائلون ٺاهي ٿي، انهن کي ڊيٽا کي ڪجهه آفسٽس تي لکي ٿو، ۽ پوء انهن فائلن کي حذف ڪري ٿو. هن اسڪرپٽ کي هلائڻ جي هڪ منٽ کان پوء، ڪجھ به غير معمولي نه ٿيندو. پنجن منٽن کان پوء، ورهاڱي تي قبضي واري جاء جو حصو ٿورو وڌي ٿو. ٻن ٽن ڪلاڪن کان پوءِ اهو 50٪ تائين پهچي ٿو (15٪ جي شروعاتي قيمت سان). ۽ پنجن يا ڇهن ڪلاڪن جي ڪم کان پوءِ، اسڪرپٽ غلطي سان حادثو ٿي وڃي ٿو "تقسيم تي ڪابه خالي جاء ناهي." ان کان پوء، توهان هاڻي پنهنجي ورهاڱي تي هڪ 4K فائل به نه لکي سگهندا.
هڪ دلچسپ صورتحال پيدا ٿئي ٿي: توهان ورهاڱي تي ڪجهه به نه لکيو، ۽ سڀ خالي جاء (اٽڪل 85٪) ڪٿي غائب ٿي وئي. اهڙي حملي جي تابع ٿيل حصي جو تجزيو ڪيترن ئي وڻن جي نوڊس کي ظاهر ڪندو جنهن ۾ صرف هڪ شيءِ (هڪ چيزي سان ليس هڪ شئي)، سائيز ۾ ڪيترائي بائيٽ. اهو آهي، اهو مواد جيڪو اڳ ۾ ڊسڪ جي 15٪ تي قبضو ڪيو ويو آهي، سڄي ورهاڱي تي هڪجهڙائي سان "smeared" ڪيو ويو آهي ته جيئن نئين فائل لکڻ لاء ڪٿي به نه هجي، ڇاڪاڻ ته ان جي ڪنجي سڀني موجوده فائلن کان وڏي آهي، ۽ مفت. ورهاڱي تي بلاڪ ختم ٿي ويا آهن.
ان کان علاوه، اهو سڀ ڪجهه اڳ ۾ ئي Btrfs جي بنيادي جوڙجڪ تي ٿئي ٿو (بغير ڪنهن به سنيپ شاٽ، ذيلي حجم، وغيره)، ۽ اهو مسئلو ناهي ته توهان ان FS ۾ فائل باڊيز کي ڪيئن ذخيرو ڪرڻ جو فيصلو ڪيو (جيئن "ٽڪر" وڻ ۾، يا حدن جي طور تي. غير فارميٽ ٿيل بلاڪ) - آخري نتيجو ساڳيو ٿيندو.
توهان ٻين اپ اسٽريم فائل سسٽم کي اهڙي حملي جي تابع نه ڪري سگهندا (ڪجهه به نه اهي توهان کي ٻڌايو). مون ڪافي عرصو اڳ مسئلي جو سبب بيان ڪيو هو: هي Btrfs ۾ B-tree جي تصور جي مڪمل خرابي آهي، جنهن جي ڪري اهو ممڪن ٿي سگهي ٿو ته ان کي خود بخود يا ارادي طور تي زوال پذير ٿئي. خاص طور تي، ڪجهه لوڊن جي تحت، توهان جو فائل سسٽم مسلسل "ٻاهر" ٿيندو، آپريشن دوران، ٻاهران مدد کان سواء. اهو واضح آهي ته سڀني قسمن جي "دٻائڻ" پس منظر جي عملن کي صرف انفرادي ڊيسڪ ٽاپ تي ڏينهن بچائيندو.
اجتماعي سرورن تي، هڪ حملو ڪندڙ هميشه انهن مان "اڳتي حاصل ڪرڻ" جي قابل هوندو. سسٽم ايڊمنسٽريٽر به اهو طئي ڪرڻ جي قابل نه هوندو ته هن کي بلڪل ڪنهن ڌمڪايو. Btrfs ۾ هن مسئلي کي حل ڪرڻ جو تيز ترين طريقو هڪ باقاعده B-وڻ جي جوڙجڪ کي بحال ڪرڻ آهي، يعني. ڊسڪ فارميٽ کي ٻيهر ترتيب ڏيڻ ۽ Btrfs ڪوڊ جي اهم حصن کي ٻيهر لکڻ. ان ۾ 8-10 سال لڳندا، بشمول ڊيبگنگ، بشرطيڪ ته ڊولپر لاڳاپيل الگورتھم ۽ ڊيٽا ڍانچي تي اصل مضمونن تي سختي سان عمل ڪن، ۽ ”ٽٽل فون“ گيم نه کيڏيو، جيئن رواجي (۽ حوصلا افزائي) ”لينڪس“ ۾ آهي. طريقو“.
هتي اسان کي اهو سڀ ڪجهه سمجهڻ لاءِ ڊولپرز لاءِ گهربل وقت به شامل ڪرڻو پوندو. اهو آهي جتي اهو وڌيڪ ڏکيو ٿي ويندو آهي. ڪنهن به صورت ۾، 10 سال انهن کي سمجهڻ لاء ڪافي نه هئا. خير، ان وقت تائين توهان معجزو جي اميد نه ٿا ڪري سگهو. اهو نه ٿيندو هڪ چڙهڻ واري آپشن جي صورت ۾ ”جنهن بابت توهان کي ۽ مون کي خبر نه هئي،“ يا هڪ پيچ جي صورت ۾ جيڪا تيار ڪرڻ لاءِ ”صرف ڪاروبار جو معاملو“ آهي. هر اهڙي جلدبازيءَ لاءِ ”فيڪس“ مان زوال جو هڪ نئون منظر پيش ڪندس. بي-وڻ منهنجي پسنديده موضوعن مان هڪ آهي، ۽ مون کي اهو چوڻ گهرجي ته اهي اڏاوتون پاڻ سان گڏ آزاديء کي برداشت نه ڪندا آهن!
مان پنهنجي لاءِ Btrfs کي ڪيئن پوزيشن ڏيان؟ جيئن ته ڪا شيءِ جيڪا مڪمل طور تي فائيل سسٽم کي نه ٿو چئي سگهجي، اڪيلو استعمال ڪيو وڃي. ڇاڪاڻ ته، تعريف سان، FS هڪ OS سب سسٽم آهي جيڪو "ڊسڪ اسپيس" وسيلن جي مؤثر انتظام لاء ذميوار آهي، جيڪو اسان Btrfs جي صورت ۾ نه ٿا ڏسو. چڱو، تصور ڪريو ته توهان دڪان تي هڪ واچ خريد ڪرڻ آيا آهيو ته جيئن ڪم تي دير نه ٿئي، ۽ هڪ واچ جي بدران انهن توهان کي 30 منٽن تائين ٽائمر سان هڪ برقي گرل وڪرو ڪيو. تنهن ڪري، Btrfs سان صورتحال اڃا به خراب آهي.
ميلنگ لسٽن جي ذريعي ڳولي، مان اڪثر بيان ڪريان ٿو ته مؤثر طريقي سان ڊسڪ اسپيس کي منظم ڪرڻ هاڻي ڊرائيو جي سستي جي ڪري لاڳاپيل ناهي. هي مڪمل بيوقوف آهي. هڪ مؤثر ڊسڪ اسپيس مئنيجر جي بغير، او ايس خطرناڪ ۽ ناقابل استعمال ٿيندو. توهان جي مشين تي ڊسڪ جي گنجائش کان سواء.
مان RHEL ۾ Btrfs سپورٽ جي بندش تي تبصرو ڪرڻ چاهيان ٿو.
هتي تبصرو ڪرڻ لاء ڪجهه خاص ناهي، هر شيء بلڪل واضح آهي. انهن وٽ اهو پڻ هو "ٽيڪنالاجي ڏيک" جي طور تي. تنهن ڪري، مان هن بلڪل ”پريويو“ ذريعي نه ويو آهيان. هن ليبل کي هميشه لاءِ لٽڪڻ نه ڏيو! پر اهي مڪمل سپورٽ سان ناقص ڊزائين ڪيل پراڊڪٽ لانچ نٿا ڪري سگهن. RHEL ھڪڙو ادارو آھي، اھو آھي، مقرر ڪيل ڪموڊٽي-مني لاڳاپن. Red Hat استعمال ڪندڙن کي بدمعاش نٿو ڪري سگھي جيئن اھي Btrfs ميلنگ لسٽ تي ڪندا آھن. رڳو صورتحال جو تصور ڪريو: ھڪڙو گراهڪ جنھن پنھنجي محنت سان ڪمايل پئسا ڊسڪ لاءِ ادا ڪيا ۽ توھان کي سپورٽ لاءِ، اھو سمجھڻ چاھي ٿو ته ھن جي ڊسڪ اسپيس ڪيڏانهن وئي پوءِ ھن ڪجھ به نه لکيو. هن کي ڇا جواب ڏيندو؟
اڳتي. Red Hat جي گراهڪن ۾ مشهور وڏي بئنڪ ۽ ايڪسچينج شامل آهن. تصور ڪريو ته ڇا ٿيندو جيڪڏهن اهي Btrfs ۾ ذڪر ڪيل نقصان جي بنياد تي DoS حملن جي تابع هوندا. توهان جي خيال ۾ ان جو ذميوار ڪير آهي؟ انهن لاءِ جيڪي پنهنجي آڱر کي GPL لائسنس جي لائن ڏانهن اشارو ڪرڻ وارا آهن، جتي اهو لکيل آهي ته ليکڪ ڪنهن به شيءِ جو ذميوار نه آهي، مان فوري طور تي چوندس: "ان کي لڪايو!" Red Hat جواب ڏيندو، ۽ اهڙي طرح ته اهو ڪافي نه ٿيندو! پر مان ڄاڻان ٿو ته ريڊ هيٽ هن قسم جي مسئلي کي منهن نه ڏئي رهيو آهي، انهن جي خاص طور تي QA انجنيئرن جي مضبوط ٽيم ڏني، جن سان مون کي پنهنجي وقت ۾ ويجهي ڪم ڪرڻ جو موقعو مليو.
ڇو ڪجهه ڪمپنيون انهن جي انٽرنيشنل پروڊڪٽس ۾ Btrfs جي حمايت جاري رکندا آهن؟
مهرباني ڪري نوٽ ڪريو ته پروڊڪٽ جي نالي ۾ اڳياڙي “انٽرپرائز” جو گهڻو مطلب نه آهي. انٽرپرائز ذميواري جو هڪ اندازو آهي جيڪو ڪلائنٽ سان معاهدي واري رشتي ۾ شامل آهي. مان ڄاڻان ٿو صرف ھڪڙي ڪمپني جي بنياد تي GNU/Linux - RHEL. باقي سڀ ڪجهه، منهنجي نقطه نظر کان، صرف هڪ ڪاروبار طور پيش ڪيو ويو آهي، پر هڪ ناهي. ۽ آخرڪار، جيڪڏهن ڪا شيء جي گهرج آهي، ته اتي هميشه هڪ فراهمي هوندي (اسان جي صورت ۾، اهو ذڪر ڪيل "سپورٽ" آهي). بلڪل هر شيءِ جي طلب آهي، بشمول. ۽ ناقابل استعمال سافٽ ويئر. اهڙي طلب ڪيئن پيدا ٿئي ٿي ۽ ڪير ان کي باهه ڏئي ٿو اهو هڪ ٻيو موضوع آهي.
تنهن ڪري، مان ڪنهن به نتيجي تي نه پهچندس جڏهن ته فيسبوڪ پنهنجي سرور تي Btrfs کي ترتيب ڏيڻ جي افواهون ڪئي آهي. ان کان علاوه، مان سفارش ڪندس ته احتياط سان انهن سرورن جي ايڊريس کي مٿين سببن لاء ڳجهو رکڻ لاء.
تازو ئي XFS ڪوڊ کي صاف ڪرڻ ۾ ايتري ڪوشش ڇو ڪئي وئي آهي؟ سڀ کان پوء، شروعات ۾ هي هڪ ٽئين پارٽي فائيل سسٽم آهي، ۽ ext4 ڊگهي وقت تائين مستحڪم آهي ۽ اڳئين برابر مستحڪم نسخن کان تسلسل آهي. Red Hat کي XFS ۾ ڪهڙي دلچسپي آهي؟ ڇا اهو سمجھ ۾ اچي ٿو ته فعال طور تي ٻه فائل سسٽم ٺاهيا جيڪي مقصد ۾ هڪجهڙا آهن - ext4 ۽ XFS؟
مون کي ياد نه آهي ته اهو ڪهڙو سبب هو. اهو بلڪل ممڪن آهي ته شروعات Red Hat گراهڪن کان آئي. مون کي ياد آهي ته هن قسم جي تحقيق ڪئي وئي هئي: اپ اسٽريم کان ڪجهه فائل سسٽم تي، نئين نسل جي اعلي-آخر ڊرائيو تي شيون جو هڪ وڏو تعداد ٺاهيو ويو. نتيجن موجب، ايڪس ايف ايس ext4 کان بهتر طريقي سان ڪم ڪيو. تنهن ڪري انهن ان کي سڀ کان وڌيڪ واعدو ڪرڻ شروع ڪيو. ڪنهن به صورت ۾، مان هتي ڪنهن به سنسڪرت جي ڳولا نه ڪندس.
منهنجي لاءِ، اهو ائين آهي جيئن انهن صابن سان هڪ awl کي تبديل ڪيو آهي. ext4 ۽ XFS کي ترقي ڪرڻ ۾ ڪو به مقصد ناهي. ٻئي متوازي ۾ ۽ انهن مان ڪنهن کي چونڊڻ لاء. ان مان ڪجھ به سٺو نه ٿيندو. جيتوڻيڪ، فطرت ۾ اڪثر حالتون آهن جڏهن ترقي جي تمام گهڻي صلاحيت آهي، پر وڌڻ جي ڪا گنجائش ناهي. انهي حالت ۾، مختلف عجيب بدصورت نوان واڌارا پيدا ٿين ٿا، جن ڏانهن هرڪو آڱر اشارو ڪري ٿو ("او، ڏس، توهان هن زندگي ۾ ڇا نه ڏسندا!").
ڇا توهان سوچيو ٿا ته پرت جي خلاف ورزي جو مسئلو حل ٿي ويو آهي (ناڪاري معنيٰ ۾) ext4، F2FS (Btrfs ۾ RAID جو ذڪر نه ڪرڻ) ۾ انڪرپشن افعال جي اچڻ سان؟
عام طور تي، ڪنهن به سطح جو تعارف ۽ انهن جي عدم ڀڃڪڙي بابت فيصلو ڪرڻ عام طور تي پاليسي جو معاملو آهي، ۽ مان هتي ڪنهن به شيء تي تبصرو ڪرڻ جو ارادو نٿو ڪريان. پرت جي خلاف ورزي جا مقصدي پهلو هر ڪنهن لاءِ گهٽ دلچسپيءَ جا هوندا آهن، پر اسان انهن مان ڪجهه تي غور ڪري سگھون ٿا خلاف ورزي جو مثال استعمال ڪندي ”مٿي کان“، يعني، ڪارڪردگيءَ جي FS ۾ عملدرآمد جيڪا اڳ ۾ ئي بلاڪ پرت تي موجود آهي. اهڙي "خلاف ورزی" صرف نادر استثنا سان جائز آهي. هر اهڙي ڪيس لاءِ، توهان کي پهريان ٻه شيون ثابت ڪرڻ گهرجن: اها ته اها واقعي گهربل آهي، ۽ اهو ته سسٽم جي ڊيزائن کي ائين ڪرڻ سان نقصان نه پهچندو.
مثال طور، آئيني، جيڪا روايتي طور تي بلاڪ پرت لاءِ هڪ سرگرمي رهي آهي، فائيل سسٽم جي سطح تي عمل ڪرڻ جو احساس پيدا ڪري ٿي. مختلف سببن جي ڪري. مثال طور، "خاموش" ڊيٽا ڪرپشن (بٽ روٽ) ڊسڪ ڊرائيو تي ٿيندي آهي. اهو تڏهن آهي جڏهن ڊوائيس صحيح طريقي سان ڪم ڪري رهيو آهي، پر بلاڪ ڊيٽا غير متوقع طور تي هڪ سخت گاما ڪوانٽم جي اثر هيٺ خراب ٿي وئي آهي، جيڪو پري ڪوسار وغيره طرفان خارج ڪيو ويو آهي. بدترين شيء اها آهي ته جيڪڏهن هي بلاڪ هڪ FS سسٽم بلاڪ (سپر بلاڪ، بٽ ميپ بلاڪ، اسٽوريج ٽري نوڊ، وغيره) ٿي سگهي ٿو، ڇاڪاڻ ته اهو ضرور ضرور هڪ ڪنييل خوفناڪ کي ڏسندو.
مهرباني ڪري نوٽ ڪريو ته بلاڪ پرت پاران پيش ڪيل آئيني (نام نهاد RAID 1) توهان کي هن مسئلي کان بچائي نه سگهندا. خير، واقعي: ڪنهن کي چيڪ ڪرڻ گهرجي ۽ ناڪامي جي صورت ۾ نقل پڙهڻ گهرجي؟ ان کان علاوه، اهو محسوس ٿئي ٿو ته آئيني کي صرف هر شيء نه، پر صرف ميٽاداٽا. ڪجھ اهم ڊيٽا (مثال طور، نازڪ ايپليڪيشنن جي قابل عمل فائلون) ميٽا ڊيٽا طور محفوظ ڪري سگھجن ٿيون. انهي حالت ۾، انهن کي حفاظت جي ساڳئي ضمانت ملي ٿي. اهو سمجھ ۾ اچي ٿو ته باقي ڊيٽا جي تحفظ کي ٻين سب سسٽم (شايد صارف جي ايپليڪيشنن کي به) جي حوالي ڪرڻ - اسان هن لاء تمام ضروري شرطون مهيا ڪيون آهن.
اهڙن "اقتصادي" آئينن کي موجود هجڻ جو حق آهي، ۽ اهي صرف فائل سسٽم جي سطح تي مؤثر طريقي سان منظم ٿي سگهن ٿيون. ٻي صورت ۾، پرت جي خلاف ورزي ڪجهه خوردبيني فائدن جي خاطر نقل ڪيل ڪوڊ سان هڪ سب سسٽم کي ڇڪيندي آهي. ھن جو ھڪڙو مثالي مثال آھي RAID-5 جو نفاذ FS استعمال ڪندي. اهڙا حل (فائل سسٽم ۾ پنهنجو RAID / LVM) بعد ۾ آرڪيٽيڪچرل اصطلاحن ۾ ماريندا آهن. هتي اهو پڻ ياد رکڻ گهرجي ته پرت جي خلاف ورزي مختلف قسم جي مارڪيٽنگ اسڪيمرز طرفان "اسٽريم تي رکيل" آهي. ڪنهن به خيالن جي غير موجودگيء ۾، ڪارڪردگي جيڪا گهڻي عرصي کان پاڙيسري سطح تي لاڳو ڪئي وئي آهي سب سسٽم ۾ شامل ڪيو ويو آهي، اهو هڪ نئين انتهائي مفيد خصوصيت جي طور تي پيش ڪيو ويو آهي ۽ فعال طور تي زور ڏنو ويو آهي.
Reiser4 "هيٺ کان" جي سطح جي ڀڃڪڙي جو الزام هو. ان حقيقت جي بنياد تي ته فائيل سسٽم monolithic نه آهي، ٻين سڀني وانگر، پر ماڊلر، هڪ غير يقيني مفروضو ڪيو ويو آهي ته اهو اهو ڪري ٿو جيڪو مٿين سطح (VFS) کي ڪرڻ گهرجي.
ڇا اهو ممڪن آهي ته ReiserFS v3.6 جي موت بابت ڳالهائڻ ۽، مثال طور، JFS؟ تازو انهن کي بنيادي طور تي ڪو به ڌيان نه مليو آهي. ڇا اهي ختم ٿي ويا آهن؟
هتي اسان کي وضاحت ڪرڻ جي ضرورت آهي ته سافٽ ويئر پراڊڪٽ جي موت جو مطلب ڇا آهي. هڪ پاسي، اهي ڪاميابيء سان استعمال ڪيا ويا آهن (جيڪو انهن لاء پيدا ڪيو ويو آهي، سڀ کان پوء)، جنهن جو مطلب آهي ته اهي رهن ٿا. ٻئي طرف، مان JFS لاء نه ڳالهائي سگهان ٿو (مون کي گهڻو ڄاڻ ناهي)، پر ReiserFS (v3) تمام ڏکيو آهي نئين رجحانات (عملي طور تي آزمائشي) کي ترتيب ڏيڻ لاء. هن جو مطلب اهو آهي ته مستقبل ۾ ڊولپرز ان تي ڌيان نه ڏيندا، پر انهن ڏانهن جيڪي ترتيب ڏيڻ آسان آهن. هن پاسي کان اهو ظاهر ٿئي ٿو ته، افسوس، اهو فن تعميراتي اصطلاحن ۾ مري ويو آهي. مان هرگز ”اخلاقي طور تي فرسوده“ جي تصور کي هٿي نه ڏيندس. اهو سٺو لاڳو ٿئي ٿو، مثال طور، هڪ الماري تي، پر سافٽ ويئر جي شين تي نه. ڪنهن شيءِ ۾ برتري ۽ برتري جو تصور هوندو آهي. مان بلڪل چئي سگهان ٿو ته ReserFS v3 هاڻي هر شيءِ ۾ Reiser4 کان گهٽ آهي، پر ڪم لوڊ جي ڪجهه قسمن ۾ اهو ٻين سڀني اپ اسٽريم FSs کان بهتر آهي.
ڇا توھان ڄاڻو ٿا FS Tux3 ۽ HAMMER/HAMMER2 (FS for DragonFly BSD) جي ترقيءَ بابت؟
ها، اسان ڄاڻون ٿا. Tux3 ۾ مون کي هڪ دفعو انهن جي تصويرن جي ٽيڪنالاجي ۾ دلچسپي هئي (جنهن کي "ورزن پوائنٽر" سڏيو ويندو آهي)، پر Reiser4 ۾ اسان گهڻو ڪري هڪ مختلف رستو وٺي سگهنداسين. مان هڪ ڊگهي وقت کان سنيپ شاٽ جي حمايت ڪرڻ بابت سوچي رهيو آهيان ۽ اڃا تائين اهو فيصلو نه ڪيو آهي ته انهن کي سادي Reiser4 جلدن لاءِ ڪيئن لاڳو ڪجي. حقيقت اها آهي ته اوهد روڊه پاران تجويز ڪيل نئين "سست" ريفرنس ڪائونٽر ٽيڪنڪ صرف بي وڻن لاءِ ڪم ڪري ٿي. اسان وٽ اهي نه آهن. انهن ڊيٽا جي جوڙجڪ لاءِ جيڪي Reiesr4 ۾ استعمال ڪيا ويا آهن، "سست" ڳڻپيندڙن جي وضاحت نه ڪئي وئي آهي - انهن کي متعارف ڪرائڻ لاءِ، اهو ضروري آهي ته ڪجهه الگورٿمڪ مسئلن کي حل ڪيو وڃي، جن کي اڃا تائين ڪنهن به نه ورتو آهي.
هيمر جي مطابق: مون خالق کان هڪ مضمون پڙهيو. دلچسپي نه آهي. ٻيهر، B-وڻ. هي ڊيٽا جو ڍانچو نا اميديءَ سان پراڻو آهي. گذريل صديءَ ۾ اسان ان کي ڇڏي ڏنو.
توهان ڪيئن اندازو لڳايو ٿا نيٽ ورڪ ڪلسٽر FSs جي وڌندڙ گهرج جهڙوڪ CephFS/GlusterFS/etc؟ ڇا ھن مطالبي جو مطلب آھي ڊولپرز جي ترجيحن ۾ نيٽ ورڪ FS ڏانھن تبديلي ۽ مقامي FS ڏانھن ڪافي ڌيان نه ڏيڻ؟
ها، ترجيحن ۾ اهڙي تبديلي آئي آهي. مقامي فائل سسٽم جي ترقي کي روڪيو ويو آهي. افسوس، مقامي حجم لاءِ ڪجهه اهم ڪم ڪرڻ هاڻي ڪافي ڏکيو آهي ۽ هرڪو اهو نٿو ڪري سگهي. ڪو به ان جي ترقي ۾ سيڙپڪاري ڪرڻ نٿو چاهي. اهو ساڳيو ئي آهي جيئن هڪ تجارتي تنظيم کان پڇڻ لاءِ رقم مختص ڪرڻ لاءِ رياضياتي تحقيق لاءِ - بغير ڪنهن جوش جي اهي توهان کان پڇندا ته توهان نئين ٿيوري تي پئسا ڪيئن ٺاهي سگهو ٿا. ھاڻي ھڪڙو مقامي ايف ايس ڪجھھ آھي جيڪو جادوئي طور تي ظاهر ٿئي ٿو ”باڪس کان ٻاھر“ ۽ ”ھميشه ڪم ڪرڻ گھرجي“ ۽ جيڪڏھن اھو ڪم نٿو ڪري، اھو اڻ ڄاتل گھٻرائڻ جو سبب بڻائيندو آھي جھڙوڪ: ”ھا، اھي ڇا سوچي رھيا آھن!
ان ڪري مقامي ايف ايس تي ڌيان نه ڏيڻ، جيتوڻيڪ اڃا تائين ان علائقي ۾ تمام گهڻو ڪم آهي. ۽ ها، هرڪو ورهايل اسٽوريج ڏانهن رخ ڪيو آهي، جيڪو اڳ ۾ ئي موجود مقامي فائل سسٽم جي بنياد تي ٺهيل آهي. اهو هاڻي تمام فيشن آهي. جملي ”بگ ڊيٽا“ ڪيترن ئي لاءِ ايڊينالائن رش جو سبب بڻجندي آهي ، ان کي ڪانفرنس ، ورڪشاپ ، وڏي تنخواه وغيره سان وابسته ڪندي.
اهو ڪيترو مناسب آهي اصولي طور تي نيٽ ورڪ فائيل سسٽم کي يوزر اسپيس جي بجاءِ ڪرنل اسپيس ۾ لاڳو ڪرڻ؟
هڪ تمام معقول طريقو جيڪو اڃا تائين ڪٿي به لاڳو نه ڪيو ويو آهي. عام طور تي، سوال اهو آهي ته ڪهڙي جاء تي نيٽ ورڪ فائل سسٽم کي لاڳو ڪيو وڃي "ٻه طرفي تلوار" آهي. خير، اچو ته هڪ مثال ڏسو. ڪلائنٽ ريموٽ مشين تي ڊيٽا رڪارڊ ڪيو. اهي گندي صفحن جي صورت ۾ هن جي صفحي جي ڪيش ۾ پئجي ويا. اهو ڪم آهي "پتلي گيٽ وي" نيٽ ورڪ فائيل سسٽم لاءِ ڪنيل اسپيس ۾. پوءِ آپريٽنگ سسٽم جلد يا بعد ۾ توهان کان پڇندو ته انهن صفحن کي ڊسڪ ۾ آزاد ڪرڻ لاءِ. پوءِ IO-فارورڊنگ (موڪلڻ) نيٽ ورڪ FS ماڊل راند ۾ اچي ٿو. اهو طئي ڪري ٿو ته ڪهڙي سرور مشين (سرور نوڊ) اهي صفحا ويندا.
پوء نيٽ ورڪ اسٽيڪ ختم ٿئي ٿو (۽، جيئن اسان ڄاڻون ٿا، اهو ڪنييل اسپيس ۾ لاڳو ٿئي ٿو). اڳيون، سرور نوڊ انهي پيڪٽ کي ڊيٽا يا ميٽا ڊيٽا سان گڏ وصول ڪري ٿو ۽ بيڪ اينڊ اسٽوريج ماڊل کي هدايت ڪري ٿو (يعني، مقامي FS جيڪو ڪنيل اسپيس ۾ هلندو آهي) هن سڀني شين کي رڪارڊ ڪرڻ لاء. تنهن ڪري، اسان سوال کي گهٽايو آهي جتي "موڪلڻ" ۽ "وصول" ماڊل ڪم ڪرڻ گهرجن. جيڪڏهن انهن مان ڪو به ماڊل يوزر اسپيس ۾ هلن ٿا، اهو ناگزير طور تي حوالن جي مٽاسٽا جي طرف وٺي ويندو (ڪيرنل سروسز استعمال ڪرڻ جي ضرورت جي ڪري). اهڙين سوئچن جو تعداد لاڳو ڪرڻ جي تفصيل تي منحصر آهي.
جيڪڏهن اهڙا ڪيترائي سوئچ آهن، ته پوء اسٽوريج throughput (I / O ڪارڪردگي) گهٽجي ويندي. جيڪڏهن توهان جي پس منظر واري اسٽوريج سست ڊسڪ مان ٺهيل آهي، ته پوء توهان هڪ اهم ڊپ نه محسوس ڪندا. پر جيڪڏهن توهان وٽ فاسٽ ڊسڪ (SSD، NVRAM، وغيره) آهن، ته پوءِ ڪنٽينر سوئچنگ اڳ ۾ ئي هڪ ”بٽلينيڪ“ بڻجي وڃي ٿي ۽، سيٽن جي سوئچنگ تي بچت ڪندي، ڪارڪردگيءَ کي وڌائي سگهجي ٿو. پئسا بچائڻ جو معياري طريقو ماڊلز کي ڪنييل اسپيس ۾ منتقل ڪرڻ آهي. مثال طور، اسان ڏٺو ته 9p سرور کي QEMU کان ڪرنل ڏانهن ميزبان مشين تي منتقل ڪري ٿو VirtFS ڪارڪردگي ۾ ٽي ڀيرا واڌارو.
اهو، يقينا، هڪ نيٽ ورڪ FS نه آهي، پر اهو مڪمل طور تي شين جي جوهر کي ظاهر ڪري ٿو. هن اصلاح جو منفي پاسو آهي پورٽبلٽي مسئلا. ڪجھ لاء، بعد ۾ نازڪ ٿي سگھي ٿو. مثال طور، GlusterFS وٽ ڪنييل ۾ ڪو به ماڊل ناهي. انهي جي مهرباني، اهو هاڻي ڪيترن ئي پليٽ فارمن تي ڪم ڪري ٿو، بشمول NetBSD.
ڪهڙا تصور مقامي ايف ايسز نيٽ ورڪ وارن کان قرض وٺي سگھن ٿا ۽ ان جي برعڪس؟
اڄڪلهه، نيٽ ورڪ FSs، ضابطي جي طور تي، مقامي FSs تي اضافو آهن، تنهنڪري مون کي سمجهه ۾ نه ٿو اچي ته توهان بعد ۾ ڪجهه قرض ڪيئن وٺي سگهو ٿا. يقينن، اچو ته 4 ملازمن جي هڪ ڪمپني تي غور ڪريو، جنهن ۾ هرڪو پنهنجو ڪم ڪري ٿو: هڪ ورهائي ٿو، ٻيو موڪلي ٿو، ٽيون وصول ڪري ٿو، چوٿين اسٽور. ۽ سوال، ڇا ڪمپني پنهنجي ملازم کان قرض وٺي سگھي ٿو جيڪو ان کي ذخيرو ڪري ٿو، آواز ڪنهن به طرح غلط آهي (اهو اڳ ۾ ئي آهي جيڪو هن کان گهڻو وقت تائين قرض وٺي سگهي ٿو).
پر مقامي FSs وٽ نيٽ ورڪ وارن کان سکڻ لاءِ گهڻو ڪجهه آهي. پهرين، توهان کي انهن کان سکڻ گهرجي ته ڪيئن منطقي حجم کي اعلي سطح تي گڏ ڪجي. هاڻي سڏيو ويندو آهي "ترقي يافته" لوڪل فائل سسٽم مجموعي طور تي منطقي مقدار کي خاص طور تي استعمال ڪندي "ورچوئل ڊيوائس" ٽيڪنالاجي استعمال ڪندي جيڪا LVM کان قرض ورتي وئي آهي (اها ساڳي انفيڪشن ليئرنگ جي خلاف ورزي جيڪا پهرين ZFS ۾ لاڳو ڪئي وئي هئي). ٻين لفظن ۾، ورچوئل ايڊريس (بلاڪ نمبرن) جو ترجمو حقيقي پتي ۾ ٿئي ٿو ۽ واپس گھٽ سطح تي ٿئي ٿو (يعني، فائل سسٽم کان پوءِ I/O درخواست جاري ڪئي وئي آهي).
مهرباني ڪري نوٽ ڪريو ته بلاڪ پرت تي ترتيب ڏنل منطقي حجم (عڪس نه) ۾ ڊوائيسز کي شامل ڪرڻ ۽ هٽائڻ سان مسئلا پيدا ٿين ٿا ته اهڙين "خصوصيتن" جا سپلائر خاموشيء سان خاموش آهن. مان حقيقي ڊوائيسز تي ٽڪراء جي باري ۾ ڳالهائي رهيو آهيان، جيڪي وڏي قدر تائين پهچي سگهن ٿا، جڏهن ته هڪ مجازي ڊوائيس تي هر شيء ٺيڪ آهي. بهرحال، ٿورا ماڻهو مجازي ڊوائيسز ۾ دلچسپي وٺندا آهن: هرڪو دلچسپي رکي ٿو جيڪو توهان جي حقيقي ڊوائيسز تي ٿي رهيو آهي. پر ZFS-like FS (انهي سان گڏ LVM سان گڏ ڪو به FS) صرف ورچوئل ڊسڪ ڊوائيسز سان ڪم ڪري ٿو (مفت وارن مان ورچوئل ڊسڪ ايڊريس مختص ڪريو، انهن ورچوئل ڊوائيسز کي خراب ڪريو، وغيره). ۽ انهن کي خبر ناهي ته حقيقي ڊوائيسز تي ڇا ٿي رهيو آهي!
ھاڻي تصور ڪريو ته توھان وٽ ورچوئل ڊيوائس تي صفر فريگمينٽيشن آھي (يعني توھان وٽ صرف ھڪڙي وڏي حد تائين رھندڙ آھي)، توھان پنھنجي منطقي حجم ۾ ھڪڙي ڊسڪ شامل ڪريو، ۽ پوء پنھنجي منطقي حجم مان ھڪڙي بي ترتيب واري ڊسڪ کي هٽايو ۽ پوء توازن ڪريو. ۽ ڪيترائي ڀيرا. اهو تصور ڪرڻ ڏکيو ناهي ته مجازي ڊوائيس تي توهان اڃا تائين ساڳئي حد تائين رهندا آهيو، پر حقيقي ڊوائيسز تي توهان ڪجهه به سٺو نه ڏسندا.
بدترين ڳالهه اها آهي ته توهان هن صورتحال کي درست ڪرڻ جي قابل نه آهيو! صرف هڪ شيء توهان هتي ڪري سگهو ٿا فائل سسٽم کان پڇڻ لاء مجازي ڊوائيس کي خراب ڪرڻ لاء. پر هوءَ توهان کي ٻڌائي ٿي ته اتي سڀ ڪجهه عظيم آهي - اتي صرف هڪ حد آهي، ٽڪرا صفر آهي، ۽ اهو بهتر نه ٿي سگهي! تنهن ڪري، بلاڪ جي سطح تي ترتيب ڏنل منطقي حجم ڊوائيسز کي بار بار شامل ڪرڻ / ختم ڪرڻ جو ارادو نه آهي. سٺي طريقي سان، توهان کي صرف هڪ ڀيرو بلاڪ سطح تي هڪ منطقي حجم گڏ ڪرڻ جي ضرورت آهي، ان کي ڏيو فائل سسٽم، ۽ پوء ان سان ٻيو ڪجهه نه ڪريو.
ان کان علاوه، آزاد FS+LVM سبسسٽم جو ميلاپ اجازت نٿو ڏئي ته اڪائونٽ ۾ ڊرائيو جي مختلف نوعيت کي جنهن مان منطقي حجم گڏ ڪيا ويا آهن. درحقيقت، فرض ڪريو ته توهان HDD ۽ سولڊ اسٽيٽ ڊوائيسز مان هڪ منطقي حجم گڏ ڪيو آهي. پر پوءِ اڳئين کي خراب ڪرڻ جي ضرورت پوندي، ۽ بعد ۾ نه. بعد ۾، توهان کي رد ڪرڻ جي درخواست جاري ڪرڻ جي ضرورت آهي، پر اڳوڻي لاء، نه، وغيره. تنهن هوندي به، هن ميلاپ ۾، ان کي ڪافي ڏکيو آهي ته اهڙي چونڊ جو مظاهرو ڪيو.
ياد رهي ته فائيل سسٽم تي توهان جي پنهنجي LVM ٺاهڻ کان پوء، صورتحال وڌيڪ بهتر نه ٿيندي. ان کان علاوه، ائين ڪرڻ سان توهان اصل ۾ مستقبل ۾ ان کي بهتر ڪرڻ جي امڪان کي ختم ڪري ڇڏيو. هي تمام خراب آهي. ڊرائيو جا مختلف قسم ساڳي مشين تي رهن ٿا. ۽ جيڪڏهن فائل سسٽم انهن جي وچ ۾ فرق نه ڪندو، پوء ڪير ڪندو؟
ٻيو مسئلو نام نهاد جي انتظار ۾ آهي. "لکيو- ڪٿي به" فائل سسٽم (ان ۾ پڻ شامل آهي Reiser4، جيڪڏهن توهان ماؤنٽ دوران مناسب ٽرانزيڪشن ماڊل بيان ڪيو آهي). اهڙي فائل سسٽم کي لازمي طور تي خراب ڪرڻ وارا اوزار مهيا ڪرڻ گهرجن جيڪي انهن جي طاقت ۾ بي مثال آهن. ۽ گهٽ-سطح حجم مينيجر هتي مدد نه ڪندو آھي، پر رڳو واٽ ۾ حاصل ڪري. حقيقت اها آهي ته اهڙي مينيجر سان، توهان جو FS صرف هڪ ڊوائيس جي مفت بلاڪ جو نقشو ذخيرو ڪندو - هڪ مجازي. انهي جي مطابق، توهان صرف هڪ مجازي ڊوائيس کي خراب ڪري سگهو ٿا. هن جو مطلب اهو آهي ته توهان جو defragmenter هڪ ڊگهي، ڊگهي وقت لاء ڪم ڪندو مجازي پتي جي هڪ وڏي هڪ جاء تي.
۽ جيڪڏھن توھان وٽ گھڻا صارف آھن بي ترتيب اوور رائٽ ڪري رھيا آھن، ته پوءِ اھڙي ڊيفريجمينٽر جو مفيد اثر صفر تائين گھٽجي ويندو. توھان جو سسٽم ناگزير طور تي سست ٿيڻ شروع ٿي ويندو، ۽ توھان کي صرف پنھنجي ھٿن کي مايوس ڪندڙ تشخيص "ٽڙيل ڊيزائن" جي اڳيان وڌائڻو پوندو. ساڳي ايڊريس اسپيس تي هلندڙ ڪيترائي defragmenters صرف هڪ ٻئي سان مداخلت ڪندا. اهو هڪ مڪمل طور تي مختلف معاملو آهي جيڪڏهن توهان هر حقيقي ڊوائيس لاء مفت بلاڪ جو پنهنجو نقشو برقرار رکون ٿا. اهو مؤثر طور تي defragmentation عمل کي متوازي ڪندو.
پر اهو صرف تڏهن ٿي سگهي ٿو جيڪڏهن توهان وٽ اعليٰ سطحي منطقي حجم مينيجر آهي. مقامي فائل سسٽم اهڙن مينيجرن سان اڳ ۾ موجود نه هئا (گهٽ ۾ گهٽ، مون کي انهن جي باري ۾ خبر ناهي). صرف نيٽ ورڪ فائل سسٽم (مثال طور GlusterFS) اهڙا مينيجر هئا. ٻيو تمام اهم مثال حجم سالميت چيڪ (fsck) افاديت آهي. جيڪڏهن توهان هر ذيلي حجم لاءِ مفت بلاڪن جو پنهنجو آزاد نقشو ذخيرو ڪريو ٿا، ته پوءِ منطقي مقدار کي جانچڻ جو طريقو مؤثر طريقي سان متوازي ٿي سگهي ٿو. ٻين لفظن ۾، اعلي سطحي مينيجرز سان منطقي حجم بهتر انداز ۾.
اضافي طور تي، گهٽ-سطح حجم مينيجرز سان توهان مڪمل ٿيل سنيپ شاٽ منظم ڪرڻ جي قابل نه هوندا. LVM ۽ ZFS-جهڙوڪ فائل سسٽم سان، توهان صرف مقامي سنيپ شاٽ وٺي سگهو ٿا، پر گلوبل سنيپ شاٽ نه. مقامي سنيپ شاٽ توهان کي صرف باقاعده فائل آپريشن کي فوري طور تي واپس آڻڻ جي اجازت ڏين ٿا. ۽ اتي ڪو به ڪو به عمل واپس نه آڻيندو منطقي حجم سان (ڊيوائسز کي شامل ڪرڻ / ختم ڪرڻ). اچو ته ان کي هڪ مثال سان ڏسو. ڪجهه وقت تي، جڏهن توهان وٽ ٻه ڊوائيس A ۽ B جو منطقي حجم 100 فائلن تي مشتمل آهي، توهان سسٽم S جو هڪ سنيپ شاٽ وٺو ۽ پوء ٻيون سئو فائلون ٺاهي.
ان کان پوء، توھان پنھنجي حجم ۾ ڊيوائس سي شامل ڪريو، ۽ آخرڪار پنھنجي سسٽم کي سنيپ شاٽ S ڏانھن واپس آڻيو. سوال: S ڏانھن رول بيڪ ڪرڻ کان پوء توھان جي منطقي حجم ۾ ڪيتريون فائلون ۽ ڊوائيس شامل آھن؟ هتي 100 فائلون هونديون، جيئن توهان اندازو لڳايو هوندو، پر اتي 3 ڊيوائسز هونديون- اهي ساڳيا ڊوائيس A، B ۽ C آهن، جيتوڻيڪ سنيپ شاٽ ٺاهڻ وقت سسٽم ۾ صرف ٻه ڊوائيس هئا (A ۽ B. ). شامل ڪريو ڊيوائس سي آپريشن واپس نه ٿيو، ۽ جيڪڏھن توھان ھاڻي ڪمپيوٽر مان ڊيوائس سي کي ھٽايو، اھو توھان جي ڊيٽا کي خراب ڪري ڇڏيندو، تنھنڪري ڊيليٽ ڪرڻ کان پھريائين توھان کي ھڪڙي قيمتي آپريشن ڪرڻي پوندي ته جيئن ڊيوائس کي ري بيلنس منطقي حجم مان ھٽايو وڃي. ڊوائيس C کان ڊوائيس A ۽ B تائين سڀني ڊيٽا کي اسڪري ڪندو. پر جيڪڏهن توهان جو FS گلوبل سنيپ شاٽ کي سپورٽ ڪري ٿو، اهڙي ريبلانسنگ جي ضرورت نه هوندي، ۽ S ڏانهن هڪ فوري رول بيڪ کان پوء، توهان ڪمپيوٽر مان ڊوائيس سي کي محفوظ طور تي هٽائي سگهو ٿا.
تنهن ڪري، گلوبل سنيپ شاٽ سٺا آهن ڇو ته اهي توهان کي هڪ ڊوائيس جي قيمتي هٽائڻ (شامل ڪرڻ) کان بچڻ جي اجازت ڏين ٿا هڪ منطقي حجم کان (هڪ منطقي حجم تائين) ڊيٽا جي وڏي مقدار سان (يقينا، جيڪڏهن توهان کي ياد آهي ته "سنيپ شاٽ" توهان جي سسٽم کي. صحيح وقت تي). مان توهان کي ياد ڏياران ٿو ته سنيپ شاٽ ٺاهڻ ۽ فائل سسٽم کي واپس آڻڻ انهن کي فوري طور تي عمل آهي. سوال ٿي سگهي ٿو: اهو ڪيئن ممڪن آهي ته فوري طور تي هڪ منطقي حجم تي هڪ آپريشن کي واپس آڻيو جنهن ۾ توهان کي ٽي ڏينهن لڳي ويا؟ پر اهو ممڪن آهي! بشرطيڪ توهان جو فائيل سسٽم صحيح طرح ٺهيل هجي. مون کي ٽي سال اڳ اهڙي ”3D سنيپ شاٽس“ جو خيال آيو، ۽ گذريل سال مون هن ٽيڪنڪ کي پيٽنٽ ڪيو.
ايندڙ شيء جيڪا مقامي FSs کي سکڻ گهرجي نيٽ ورڪ وارن کان ميٽا ڊيٽا کي الڳ ڊوائيسز تي ذخيرو ڪرڻ لاء ساڳئي طريقي سان نيٽ ورڪ FSs انهن کي الڳ الڳ مشينن تي محفوظ ڪن ٿا (نام نهاد ميٽا ڊيٽا سرورز). اهي ايپليڪيشنون آهن جيڪي بنيادي طور تي ميٽا ڊيٽا سان ڪم ڪن ٿيون، ۽ اهي ايپليڪيشنون تمام تيز ٿي سگهن ٿيون ميٽا ڊيٽا کي قيمتي اعلي ڪارڪردگي اسٽوريج ڊوائيسز تي رکڻ سان. FS+LVM ميلاپ سان، توهان اهڙي چونڊيليت کي ظاهر ڪرڻ جي قابل نه هوندا: LVM کي خبر ناهي ته بلاڪ تي ڇا آهي جيڪو توهان ان ڏانهن منتقل ڪيو (ڊيٽا اتي يا ميٽا ڊيٽا).
توهان FS + LVM ميلاپ جي مقابلي ۾ FS ۾ توهان جي پنهنجي گهٽ-سطح واري LVM کي لاڳو ڪرڻ کان گهڻو فائدو حاصل نه ڪندا، پر جيڪو توهان تمام سٺو ڪري سگهو ٿا اهو آهي FS کي بي ترتيب ڪرڻ ته جيئن بعد ۾ ان جي ڪوڊ سان ڪم ڪرڻ ناممڪن ٿي وڃي. ZFS ۽ Btrfs، جيڪي ورچوئل ڊوائيسز سان گڏ هليا ويا، اهي سڀ واضح مثال آهن ته ڪيئن پرت جي ڀڃڪڙي نظام کي تعميراتي اصطلاحن ۾ ماريندو آهي، پوء، مان هي سڀ ڇو آهيان؟ ان کان علاوه، فائل سسٽم ۾ توهان جي پنهنجي گھٽ-سطح LVM کي انسٽال ڪرڻ جي ڪا ضرورت ناهي. ان جي بدران، توهان کي ڊوائيسز کي هڪ اعلي سطح تي منطقي حجم ۾ مجموعي ڪرڻ جي ضرورت آهي، جيئن ڪجهه نيٽ ورڪ فائل سسٽم مختلف مشينن سان ڪندا آهن (اسٽوريج نوڊس). سچ، اهي خراب الگورتھم جي استعمال جي ڪري هي ناپسنديده ڪندا آهن.
بلڪل خوفناڪ الگورتھم جا مثال آھن GlusterFS فائل سسٽم ۾ DHT مترجم ۽ ڪيف فائل سسٽم ۾ نام نہاد CRUSH نقشو. ڪو به الگورتھم جيڪو مون ڏٺو سادگي ۽ سٺي اسپيبلٽي جي لحاظ کان مون کي مطمئن نه ڪيو. تنهنڪري مون کي الجبرا ياد رکڻو هو ۽ هر شيءِ پاڻ ايجاد ڪرڻي هئي. 2015 ۾، هيش ڪمن تي بنڊلن سان تجربا ڪرڻ دوران، مون وٽ آيو ۽ پينٽ ڪيو جيڪو مون کي مناسب آهي. هاڻي مان چئي سگهان ٿو ته اهو سڀ ڪجهه عمل ۾ آڻڻ جي ڪوشش ڪامياب وئي. مون کي نئين انداز ۾ اسپيبلبل سان ڪو به مسئلو نظر نٿو اچي.
ها، هر ذيلي حجم کي الڳ ڍانچي جي ضرورت هوندي، جهڙوڪ ميموري ۾ سپر بلاڪ. ڇا اهو تمام خوفناڪ آهي؟ عام طور تي، مون کي خبر ناهي ته ڪير ”سمنڊ کي ابلڻ“ وارو آهي ۽ هڪ مقامي مشين تي سوين هزارين يا وڌيڪ ڊوائيسز جو منطقي حجم ٺاهي ٿو. جيڪڏهن ڪو مون کي هن جي وضاحت ڪري سگهي ٿو ته مان تمام گهڻو شڪرگذار ٿيندس. ساڳئي وقت ۾، مون لاء هي مارڪيٽنگ بلشٽ آهي.
ڪنيل بلاڪ ڊيوائس سب سسٽم ۾ تبديليون ڪيئن ٿيون (مثال طور، blk-mq جي ظاهر) FS لاڳو ڪرڻ جي گهرج کي متاثر ڪيو؟
انهن جو ڪو به اثر نه ٿيو. مون کي خبر ناهي ته بلاڪ پرت تي ڇا ٿيندو جيڪو اهو ضروري بڻائيندو ته نئين FS کي ڊزائين ڪرڻ. انهن سب سسٽم جي وچ ۾ رابطي جو انٽرفيس تمام خراب آهي. ڊرائيور جي پاسي کان، FS صرف نئين قسم جي ڊرائيوز جي ظاهر ٿيڻ کان متاثر ٿيڻ گهرجي، جنهن ۾ بلاڪ پرت پهرين ترتيب ڏني ويندي، ۽ پوء ايف ايس (ريزر 4 لاء هن جو مطلب آهي نئين پلگ ان جي ظاهر ٿيڻ).
ڇا ميڊيا جي نون قسمن جو اڀرڻ (مثال طور، SMR، يا SSDs جي هر سطح) جو مطلب آهي بنيادي طور تي نئين چيلينج فائل سسٽم ڊيزائن لاءِ؟
ها. ۽ اهي FS جي ترقي لاء عام ترغيب آهن. چئلينج مختلف ٿي سگهن ٿا ۽ مڪمل طور تي غير متوقع. مثال طور، مون ڊرائيو بابت ٻڌو آهي جتي I/O آپريشن جي رفتار تمام گهڻي منحصر آهي ڊيٽا جي هڪ ٽڪري جي سائيز ۽ ان جي آفسيٽ تي. لينڪس ۾، جتي FS بلاڪ جي سائيز صفحي جي سائيز کان وڌيڪ نه ٿي سگھي، اهڙي ڊرائيو ڊفالٽ طور تي مڪمل صلاحيتون نه ڏيکاريندو. بهرحال، جيڪڏهن توهان جو فائيل سسٽم صحيح طرح ٺهيل آهي، ته پوء ان مان گهڻو ڪجهه حاصل ڪرڻ جو هڪ موقعو آهي.
توهان کان سواءِ هن وقت ڪيترا ماڻهو Reiser4 ڪوڊ سان ڪم ڪري رهيا آهن؟
مان چاهيان ٿو ان کان گهٽ، پر مون کي وسيلن جي شديد کوٽ جو تجربو نه آهي. مان Reiser4 جي ترقي جي رفتار کان وڌيڪ مطمئن آهيان. مان نه وڃڻ وارو آهيان ”گهوڙا ڊرائيو“ - هي صحيح علائقو ناهي. هتي، "جيڪڏهن توهان وڌيڪ خاموشيء سان ڊرائيو ڪيو، توهان اڳتي وڌو!" هڪ جديد فائيل سسٽم تمام پيچيده ڪنيل سبسسٽم آهي، جنهن جي غلط ڊيزائن جا فيصلا انساني ڪم جي ايندڙ سالن کي واپس آڻي سگهن ٿا.
رضاڪارن کي ڪنهن شيءِ تي عمل ڪرڻ لاءِ پيش ڪرڻ سان، مان هميشه ضمانت ڏيان ٿو ته ڪوششون يقيني طور تي صحيح نتيجا حاصل ڪنديون، جيڪي سنجيده ضرورتن جي تقاضا ۾ ٿي سگهن ٿيون. جيئن توهان سمجھو ٿا، هڪ ئي وقت ۾ ڪيتريون ئي ضمانتون نه ٿيون ٿي سگهن. ساڳئي وقت، مان "انگن اکرن" کي برداشت نه ٿو ڪري سگهان جيڪي واضح طور تي ناقابل استعمال سافٽ ويئر جي "فيچرز" کي بي شرمي سان فروغ ڏين ٿا، سوين صارفين ۽ ڊولپرز کي ٺڳي، ۽ ساڳئي وقت ڪرنل سمٽ تي ويٺي ۽ مسڪرايو.
ڇا ڪنهن به ڪمپني Reiser4 جي ترقي جي حمايت ڪرڻ لاء رضامندي ظاهر ڪئي آهي؟
ها، اهڙيون تجويزون هيون، بشمول. ۽ هڪ وڏي وڪرو ڪندڙ کان. پر ان لاءِ مون کي ٻئي ملڪ وڃڻو پيو. بدقسمتي سان، مان هاڻي 30 سالن جو ناهيان، مان ڀڄي نه ٿو سگهان ۽ پهرين سيٽي تي ائين ئي ڇڏي سگهان ٿو.
Reiser4 مان في الحال ڪهڙيون خاصيتون غائب آهن؟
سادو حجمن لاءِ ڪو به ”ريسائز“ فنڪشن ناهي، جيڪو ReiserFS (v3) ۾ مليو آهي. ان کان علاوه، DIRECT_IO پرچم سان فائل آپريشنز کي نقصان نه ٿيندو. اڳيون، مان چاهيان ٿو ته هڪ حجم کي ”Semantic subvolumes“ ۾ ورهائي سگھان، جن جي ڪا مقرر سائيز نه آهي، ۽ جنهن کي آزاد حجم طور نصب ڪري سگهجي ٿو. اهي مسئلا شروعات ڪندڙن لاءِ سٺا آهن جيڪي ”حقيقي شيءِ“ تي پنهنجو هٿ آزمائڻ چاهيندا آهن.
۽ آخرڪار، مان چاهيان ٿو نيٽ ورڪ منطقي حجم سادو عمل درآمد ۽ انتظاميه سان (جديد الگورتھم اڳ ۾ ئي اجازت ڏين ٿا). پر ڇا Reiser4 ضرور ڪڏهن به نه هوندو RAID-Z، اسڪربس، مفت اسپيس ڪيچ، 128-بٽ متغير ۽ ٻيون مارڪيٽنگ جون ڳالهيون جيڪي ڪجهه فائل سسٽم جي ڊولپرز جي وچ ۾ خيالن جي گهٽتائي جي پس منظر جي خلاف پيدا ٿيا.
ڇا هر شي جيڪا گهربل هجي پلگ ان ذريعي لاڳو ٿي سگهي ٿي؟
جيڪڏهن اسان صرف انٽرفيس ۽ پلگ ان (ماڊيولز) جي لحاظ سان ڳالهايون ٿا جيڪي انهن کي لاڳو ڪن ٿا، پوء سڀ ڪجهه نه. پر جيڪڏهن توهان انهن انٽرفيس تي لاڳاپا پڻ متعارف ڪرايو ٿا، ته پوءِ، ٻين شين سان گڏ، توهان وٽ اعليٰ پوليمورفيزم جا تصور هوندا، جن سان توهان اڳ ۾ ئي حاصل ڪري سگهو ٿا. تصور ڪريو ته توھان فرضي طور تي ھڪڙي اعتراض تي مبني رن ٽائم سسٽم کي منجمد ڪيو، ھدايت واري پوائنٽر جي قيمت کي تبديل ڪيو ھڪڙي ٻئي پلگ ان ڏانھن اشارو ڪرڻ لاء جيڪو ساڳيو X انٽرفيس کي لاڳو ڪري ٿو، ۽ پوء سسٽم کي انفروز ڪيو ته جيئن اھو جاري رھي.
جيڪڏهن آخري صارف اهڙي "متبادل" کي نوٽيس نٿو ڪري، پوء اسان چئون ٿا ته سسٽم X انٽرفيس ۾ صفر-آرڊر پوليمورفيزم آهي (يا سسٽم ايڪس انٽرفيس ۾ هيٽروجني آهي، جيڪا ساڳي شيء آهي). جيڪڏهن هاڻي توهان وٽ نه صرف انٽرفيس جو هڪ سيٽ آهي، پر انهن تي لاڳاپا پڻ آهن (انٽرفيس گراف)، پوء توهان اعلي آرڊر جي پوليمورفيزم کي متعارف ڪرايو ٿا، جيڪو اڳ ۾ ئي ڪنهن به انٽرفيس جي "پاڙيسري" ۾ سسٽم جي هيٽروجنيٽي جي خاصيت ڪندو. مون هڪ ڊگهو وقت اڳ اهڙي درجه بندي متعارف ڪرايو، پر، بدقسمتي سان، اهو ڪڏهن به نه ٿيو.
تنهن ڪري، پلگ ان ۽ اهڙن اعلي پوليمورفيزم جي مدد سان، توهان ڪنهن به ڄاڻايل خاصيت کي بيان ڪري سگهو ٿا، انهي سان گڏ "پيشگوئي" انهن جو ذڪر ڪيو ويو آهي. مان هن کي سختي سان ثابت ڪرڻ جي قابل نه ٿي سگهيو آهيان، پر مون کي اڃا تائين هڪ جوابي مثال جي خبر ناهي. عام طور تي، هن سوال مون کي ياد ڏياريو فيلڪس ڪلين جي "Erlangen پروگرام". هڪ دفعي هن ڪوشش ڪئي ته سموري جاميٽري کي الجبرا جي شاخ طور پيش ڪيو وڃي (خاص طور تي، گروهه جو نظريو).
ھاڻي اصلي سوال ڏانھن - شيون ڪيئن ٿي رھيون آھن Reiser4 جي واڌاري سان مکيه ڪور ڏانھن؟ ڇا هن فائل سسٽم جي فن تعمير تي ڪا اشاعت هئي جنهن بابت توهان گذريل انٽرويو ۾ ڳالهايو؟ اهو سوال توهان جي نقطه نظر کان ڪيترو لاڳاپيل آهي؟
عام طور تي، اسان ٽن سالن کان مکيه شاخ ۾ شامل ڪرڻ لاء پڇي رهيا آهيون. ريزر جو آخري تبصرو عوامي سلسلي ۾ جتي پل جي درخواست ڪئي وئي هئي جواب نه ڏنو ويو. تنهن ڪري ٻيا سڀ سوال اسان لاءِ نه آهن. مان ذاتي طور تي نه ٿو سمجهان ته اسان کي هڪ مخصوص آپريٽنگ سسٽم ۾ "ضم ڪرڻ" جي ضرورت آهي. لينڪس تي، روشني هڪ پچر وانگر گڏ نه ڪيو. تنهن ڪري، اتي هڪ الڳ مخزن آهي جنهن ۾ مختلف او ايسز لاءِ ڪيترائي برانچ بندرگاهن هوندا. جيڪو به ان جي ضرورت هجي اهو لاڳاپيل بندرگاهن کي ڪلون ڪري سگهي ٿو ۽ جيڪو توهان چاهيو ان سان ڪري سگهو ٿا (لائسنس جي اندر، يقينا). خير، جيڪڏهن ڪنهن کي ضرورت ناهي، ته اهو منهنجو مسئلو ناهي. هن موقعي تي، مان تجويز ڪريان ٿو ته "مين لينڪس ڪنيل ۾ واڌاري" جي سوال تي غور ڪيو وڃي جيئن آباد.
FS آرڪيٽيڪچر تي پبليڪيشن لاڳاپيل آهن، پر هن وقت تائين مون کي صرف پنهنجي نئين نتيجن لاءِ وقت مليو آهي، جنهن کي مان هڪ اعليٰ ترجيح سمجهان ٿو. ٻي ڳالهه اها آهي ته مان هڪ رياضي دان آهيان، ۽ رياضي ۾ ڪا به اشاعت نظريي ۽ انهن جي ثبوتن جو خلاصو آهي. بغير ثبوت جي ڪا به شيءِ شايع ڪرڻ خراب ذوق جي نشاني آهي. جيڪڏهن مان FS جي فن تعمير بابت ڪنهن به ڳالهه کي چڱيءَ طرح ثابت يا غلط ثابت ڪريان ته پوءِ نتيجو اهڙو نڪرندو جو ان مان نڪرڻ ڪافي مشڪل ٿي پوندو. ڪنهن کي ضرورت آهي؟ شايد اهو ئي سبب آهي ته هر شيءِ پنهنجي پراڻي شڪل ۾ رهي ٿي - سورس ڪوڊ ۽ ان تي تبصرا.
گذريل ڪجھ سالن ۾ Reiser4 ۾ نئون ڇا آهي؟
ڊگهي انتظار جي استحڪام آخرڪار مادي ٿي چڪو آهي. ظاهر ٿيڻ لاءِ آخرين مان هڪ هڪ بگ هو جنهن جي ڪري ”ناقابل ختم ٿيڻ واري“ ڊائريڪٽري. ڏکيائي اها هئي ته اهو صرف نالو جي پس منظر جي خلاف ظاهر ٿيو هيش ٽڪرين ۽ ڊاريڪٽري رڪارڊ جي هڪ خاص جڳهه سان هڪ وڻ جي نوڊ ۾. بهرحال، مان اڃا تائين سفارش نٿو ڪري سگهان Reiser4 پيداوار لاءِ: ان لاءِ توهان کي ڪجهه ڪم ڪرڻو پوندو پروڊڪشن سسٽم جي منتظمين سان فعال رابطي سان.
اسان آخرڪار اسان جي ڊگھي بيٺل خيال کي لاڳو ڪرڻ ۾ منظم ڪيو - مختلف ٽرانزيڪشن ماڊل. اڳي، Reiser4 صرف هڪ هارڊ ڪوڊ ٿيل Macdonald-Reiser ماڊل هلائي. اهو ٺاهيل مسئلا پيدا ڪيو. خاص طور تي، اهڙي ٽرانزيڪشن ماڊل ۾ سنيپ شاٽ ممڪن نه آهن - اهي "اوور رائٽ سيٽ" نالي هڪ ايٽمي جزو طرفان خراب ٿي ويندا. Reiser4 هن وقت ٽن ٽرانزيڪشن ماڊل کي سپورٽ ڪري ٿو. انهن مان هڪ ۾ (ڪنهن به لکو)، ايٽمي جزو OVERWRITE SET ۾ صرف سسٽم صفحا شامل آهن (ڊسڪ بٽ ميپس جون تصويرون، وغيره)، جن کي "ڦوٽوگرافي" نٿو ڪري سگهجي (ڪڪڙ ۽ انجڻ جو مسئلو).
تنهنڪري تصويرون هاڻي بهترين طريقي سان محسوس ڪري سگهجن ٿيون. ٻئي ٽرانزيڪشن ماڊل ۾، سڀئي تبديل ٿيل صفحا صرف اوور رائٽ سيٽ ڏانهن ويندا آهن (يعني، اهو بنيادي طور تي خالص جرنلنگ آهي). هي نمونو انهن لاء آهي جيڪي Reiser4 ورهاڱي جي تيزيء سان ٽڪرائڻ بابت شڪايت ڪن ٿا. ھاڻي ھن ماڊل ۾ توھان جو ورهاڱو وڌيڪ تيزيءَ سان ٽڪراءُ نه ٿيندو ReiserFS (v3) سان. سڀ ٽي موجود ماڊل، ڪجھ تحفظات سان، آپريشن جي ايٽمي جي ضمانت ڏين ٿا، پر ماڊل جيڪي ايٽمي جي نقصان سان گڏ آھن ۽ صرف سيڪشن جي سالميت کي محفوظ ڪري سگھن ٿا. اهڙا ماڊل سڀني قسمن جي ايپليڪيشنن (ڊيٽابيس، وغيره) لاء ڪارائتو ٿي سگهن ٿا، جيڪي اڳ ۾ ئي انهن مان ڪجهه ڪمن تي وٺي چڪا آهن. انهن ماڊلز کي Reiser4 ۾ شامل ڪرڻ تمام آسان آهي، پر مون اهو نه ڪيو، ڇاڪاڻ ته مون کان ڪنهن به نه پڇيو، ۽ مون کي ذاتي طور تي ان جي ضرورت ناهي.
Metadata checksums ظاهر ٿيو ۽ مون تازو انهن کي "معاشي" آئيني سان گڏ ڪيو (اڃا تائين غير مستحڪم مواد). جيڪڏهن ڪنهن بلاڪ جي چيڪسم ناڪام ٿئي ٿي، Reiser4 فوري طور تي ساڳئي بلاڪ کي ريپليڪا ڊوائيس مان پڙهي ٿو. نوٽ ڪريو ته ZFS ۽ Btrfs اهو نٿا ڪري سگهن: ڊزائن ان کي اجازت نٿو ڏئي. اتي توهان کي "اسڪريب" نالي هڪ خاص پس منظر جي اسڪيننگ عمل کي هلائڻ گهرجي ۽ ان لاءِ انتظار ڪريو ان لاءِ مشڪلات واري بلاڪ تي. پروگرامر علامتي طور تي اهڙن واقعن کي سڏيندا آهن "بيٺا".
۽ آخرڪار، متضاد منطقي حجم ظاهر ٿي ويا آهن، هر شي پيش ڪري رهيا آهن جيڪي ZFS، Btrfs، بلاڪ پرت، ۽ انهي سان گڏ FS+LVM مجموعا اصولن ۾ مهيا نٿا ڪري سگهن - متوازي اسڪيلنگ، O(1) ڊسڪ ايڊريس مختص ڪندڙ، شفاف ڊيٽا منتقلي جي وچ ۾ ذيلي حجم. بعد ۾ پڻ هڪ صارف انٽرفيس آهي. ھاڻي توھان آساني سان ھٽسٽ ڊيٽا کي پنھنجي حجم تي اعليٰ ترين ڪارڪردگي واري ڊرائيو ڏانھن منتقل ڪري سگھو ٿا.
ان کان علاوه، ممڪن آهي ته فوري طور تي ڪنهن به گندي صفحن کي اهڙي ڊرائيو تي فلش ڪيو وڃي، ان سان خاص طور تي تيز رفتار ايپليڪيشنون جيڪي اڪثر ڪري سڏين ٿيون fsync(2). مان نوٽ ڪريان ٿو ته بلاڪ پرت جي ڪارڪردگي، جنهن کي bcache سڏيو ويندو آهي، اهڙي عمل جي آزادي مهيا نٿو ڪري. نون منطقي حجمن تي ٻڌل آھن منھنجي الگورتھم (اھڙا لاڳاپيل پيٽرن آھن). سافٽ ويئر اڳ ۾ ئي ڪافي مستحڪم آهي، اهو ممڪن آهي ته ان جي ڪوشش ڪرڻ، ڪارڪردگي کي ماپڻ، وغيره. صرف تڪليف اها آهي ته هاڻي توهان کي دستي طور تي حجم جي ترتيب کي اپڊيٽ ڪرڻ ۽ ان کي ڪٿي ذخيرو ڪرڻ جي ضرورت آهي.
هن وقت تائين مان پنهنجي خيالن کي 10 سيڪڙو تائين لاڳو ڪرڻ ۾ ڪامياب ٿي چڪو آهيان، جڏهن ته، مان ان ۾ ڪامياب ٿي چڪو آهيان جنهن کي مون سڀ کان ڏکيو سمجهيو هو- منطقي حجمن کي فليش طريقي سان ڳنڍڻ جيڪو سڀني ملتوي ڪيل عملن کي reiser4 ۾ انجام ڏئي ٿو. اهو سڀ اڃا تائين تجرباتي "فارميٽ 41" شاخ ۾ آهي.
ڇا Reiser4 xfstests پاس ڪري ٿو؟
گهٽ ۾ گهٽ اهو مون لاءِ ڪيو جڏهن مان آخري رليز تيار ڪري رهيو هوس.
ڇا اهو ممڪن آهي اصول ۾ Reiser4 هڪ نيٽ ورڪ (ڪلسٽر) FS پلگ ان استعمال ڪندي؟
اهو ممڪن آهي، ۽ اڃا به ضروري آهي! جيڪڏھن توھان ٺاھيو ھڪڙي نيٽ ورڪ فائل ھڪڙي صحيح طرح سان ٺهيل مقامي فائل سسٽم جي بنياد تي، نتيجو تمام شاندار ٿيندو! جديد نيٽ ورڪ FSs ۾، مان مطمئن نه آهيان هڪ پس منظر اسٽوريج سطح جي موجودگي سان، جيڪو ڪنهن به مقامي FS استعمال ڪندي لاڳو ڪيو ويو آهي. هن سطح جو وجود مڪمل طور تي ناجائز آهي. نيٽ ورڪ FS کي سڌو سنئون بلاڪ پرت سان رابطو ڪرڻ گهرجي، ۽ مقامي FS کان نه پڇڻ گهرجي ته ڪا ٻي سروس فائلون ٺاهي!
عام طور تي، فائيل سسٽم کي مقامي ۽ نيٽ ورڪ ۾ ورهائڻ برائي مان آهي. اهو الورورٿم جي نقص مان پيدا ٿيو جيڪي ٽيهه سال اڳ استعمال ڪيا ويا هئا، ۽ ان جي جاء تي اڃا تائين ڪجھ به تجويز نه ڪيو ويو آهي. اهو پڻ غير ضروري سافٽ ويئر اجزاء (مختلف خدمتون، وغيره) جي وڏي تعداد جي ظاهر ٿيڻ جو سبب آهي. سٺي طريقي سان، هڪ ڪنيل ماڊل جي صورت ۾ صرف هڪ FS هجڻ گهرجي ۽ هر مشين تي نصب ڪيل يوزر يوٽيلٽيز جو هڪ سيٽ - هڪ ڪلستر نوڊ. هي FS ٻنهي مقامي ۽ نيٽ ورڪ آهي. ۽ وڌيڪ ڪجھ به نه!
جيڪڏهن لينڪس تي Reiser4 سان ڪجھ به ڪم نٿو ڪري، آئون پيش ڪرڻ چاهيان ٿو FS for FreeBSD (اڳئين انٽرويو مان اقتباس: "...FreeBSD... علمي جڙ آهي... ۽ ان جو مطلب اهو آهي ته اسان وٽ اعليٰ درجي جي امڪان سان. ڊولپرز سان گڏ هڪ عام ٻولي ڳولي ويندي")؟
تنهن ڪري، جيئن اسان کي معلوم ٿيو، سڀ ڪجهه اڳ ۾ ئي مڪمل طور تي لينڪس سان ڪم ڪيو آهي: اسان جي مخزن جي ماسٽر برانچ جي صورت ۾ ان لاء هڪ الڳ ڪم ڪندڙ Reiser4 بندرگاهه آهي. مون FreeBSD بابت نه وساريو آهي! آڇ! مان انهن سان ويجهڙائي سان ڪم ڪرڻ لاءِ تيار آهيان جيڪي فري بي ايس ڊي جي اندرين کي چڱي طرح knowاڻين ٿا. رستي ۾: مون کي انهن جي ڪميونٽي بابت ڇا پسند آهي اهو آهي ته اتي فيصلا آزاد ماهرن جي هڪ تازه ڪاري ڪائونسل طرفان ڪيا ويا آهن، جن جو هڪ مستقل شخص جي حڪومتي فريب سان ڪو به تعلق ناهي.
اڄ توهان لينڪس صارف ڪميونٽي کي ڪيئن اندازو لڳايو ٿا؟ ڇا اهو وڌيڪ "پاپ" بڻجي ويو آهي؟
منهنجي ڪم جي نوعيت کي نظر ۾ رکندي، مون لاءِ ان جو اندازو لڳائڻ ڪافي مشڪل آهي. اڪثر صارف مون وٽ بگ رپورٽون ۽ سيڪشن کي درست ڪرڻ جي درخواستن سان ايندا آهن. صارفين جي طور تي استعمال ڪندڙ. ڪي وڌيڪ ذهين آهن، ڪي گهٽ. سڀني سان ساڳيو علاج ڪيو وڃي ٿو. خير، جيڪڏهن صارف منهنجي هدايتن کي نظر انداز ڪري ٿو، ته پوء مون کي معاف ڪجو: نظر انداز ڪرڻ جو حڪم منهنجي طرفان پڻ داخل ڪيو ويندو.
ڇا اهو ممڪن آهي ته ايندڙ پنجن کان ڏهن سالن تائين فائل سسٽم جي ترقي جي اڳڪٿي ڪرڻ؟ توهان ڇا ٿا سوچيو ته بنيادي چئلينج جيڪي FS ڊولپرز کي منهن ڏئي سگهن ٿا؟
ها، اهڙي اڳڪٿي ڪرڻ ڏکيو ناهي. گهڻي عرصي کان اپ اسٽريم ۾ فائل سسٽم جي ڪا به ترقي نه ٿي آهي. صرف ظاهري طور تي اهڙي ٺاهي وئي آهي. مقامي فائل سسٽم جا ڊولپر خراب ڊيزائن سان لاڳاپيل مسئلن ۾ ڀڄي ويا. هتي هڪ احتياط ڪرڻ جي ضرورت آهي. مان نه ٿو سمجهان "اسٽوريج"، "چٽڻ" ۽ ڪوڊ جي پورٽنگ کي ترقي ۽ ترقي. ۽ مان "Btrfs" نالي غلط فهمي کي ترقيءَ جي طور تي درجه بندي نه ٿو ڪريان انهن سببن لاءِ جيڪي مون اڳ ۾ ئي بيان ڪيا آهن.
هر پيچ صرف ان جي مسئلن کي وڌيڪ خراب ڪري ٿو. خير. ۽ ھميشه مختلف قسم جا ”مبشر“ آھن جن لاءِ ”سڀ ڪجھ ڪم ڪري ٿو. بنيادي طور تي، اهي اسڪول جا ٻار ۽ شاگرد ليڪچر ڇڏڻ وارا آهن. بس تصور ڪريو: اھو ھن لاءِ ڪم ڪري ٿو، پر پروفيسر نٿو ڪري. هي ڪهڙي ايڊينالائن رش آهي! منهنجي نقطه نظر کان، سڀ کان وڏو نقصان انهن ”ڪارگرن“ جو ٿيو آهي، جن بي ٽي آر ايف جي شاندار خصوصيتن کي هر قسم جي پرت جهڙوڪ سسٽمڊ، ڊاڪر وغيره تي جوش سان ”اسڪرو“ ڪيو. - هي اڳ ۾ ئي metastases وانگر آهي.
اچو ته هاڻي پنجن کان ڏهن سالن جي اڳڪٿي ڪرڻ جي ڪوشش ڪريون. مون اڳ ۾ ئي مختصر طور تي درج ڪيو آهي ته اسان Reiser4 ۾ ڇا ڪنداسين. اپ اسٽريم کان مقامي FS ڊولپرز لاءِ بنيادي چئلينج هوندو (ها، اهو اڳ ۾ ئي ٿي چڪو آهي) تنخواه لاءِ مهذب نوڪري ڪرڻ جي ناڪامي. ڊيٽا اسٽوريج جي ميدان ۾ ڪنهن به خيال کان سواء، اهي انهن بدقسمتي VFS، XFS ۽ ext4 کي پيچ ڪرڻ جي ڪوشش ڪندا رهندا. VFS سان صورتحال خاص طور تي هن پس منظر جي خلاف مزاحيه نظر اچي ٿي، هڪ ريسٽورنٽ جي جديد جديديت جي ياد ڏياريندو آهي جنهن ۾ ڪو به شيف نه آهي، ۽ نه شيف جي توقع آهي.
ھاڻي VFS ڪوڊ، بغير ڪنھن شرط جي، ھڪ ئي وقت ڪيترن ئي ميموري صفحن کي لاڪ ڪري ٿو ۽ ھيٺئين FS کي انھن تي ڪم ڪرڻ جي دعوت ڏئي ٿو. اهو متعارف ڪرايو ويو Ext4 جي ڪارڪردگي کي حذف ڪرڻ جي عملن تي بهتر ڪرڻ لاءِ، پر جيئن سمجهڻ آسان آهي، اهڙي سمورو لاڪنگ مڪمل طور تي ترقي يافته ٽرانزيڪشن ماڊل سان مطابقت نه رکي ٿي. اهو آهي، توهان صرف ڪنييل ۾ ڪجهه سمارٽ فائل سسٽم لاء سپورٽ شامل ڪرڻ جي قابل نه هوندا. مون کي خبر ناهي ته لينڪس جي ٻين علائقن ۾ صورتحال ڇا آهي، پر جيتري قدر فائل سسٽم جو تعلق آهي، هتي ڪا به ترقي ممڪن ناهي ته پاليسي ۾ Torvalds جي پيروي ڪيل پاليسي سان مطابقت هجي (تعليمي منصوبن کي ختم ڪيو ويو آهي، ۽ اسڪيمرز جيڪي ڪابه خبر ناهي ته ڇا هڪ بي-وڻ آهي، اعتماد جا لامحدود قرض جاري ڪيا ويندا آهن). تنهن ڪري، سست خرابي لاء هڪ ڪورس مقرر ڪيو ويو. يقينن، اهي پنهنجي پوري طاقت سان ان کي "ترقي" جي طور تي منظور ڪرڻ جي ڪوشش ڪندا.
ان کان علاوه، فائل سسٽم جا "نگهبان"، اهو سمجهڻ ته توهان اڪيلو "اسٽوريج" مان گهڻو ڪمائي نه ٿا سگهو، وڌيڪ منافعي واري ڪاروبار تي پنهنجو هٿ آزمائيندا. اهي آهن، ضابطي جي طور تي، ورهايل فائل سسٽم ۽ ورچوئلائيزيشن. ٿي سگهي ٿو اهي فيشن واري ZFS کي بندرگاهه ڪندا ڪنهن ٻئي هنڌ جتي اهو اڃا موجود ناهي. پر اهو، سڀني FS وانگر اپ اسٽريم کان، هڪ نئين سال جي وڻ وانگر آهي: جيڪڏهن توهان مٿي تي ڪجهه ٻيون ننڍيون شيون لڪائي سگهو ٿا، ته پوء توهان وڌيڪ اونهي حاصل نه ڪري سگهو. مان سمجهان ٿو ته ZFS جي بنياد تي هڪ سنگين انٽرپرائز سسٽم ٺاهڻ ممڪن آهي، پر جيئن ته اسان هاڻي مستقبل تي بحث ڪري رهيا آهيون، مان صرف افسوس سان چئي سگهان ٿو ته ZFS ان سلسلي ۾ نا اميد آهي: انهن جي مجازي ڊوائيسز سان، ماڻهن کي آڪسيجن ڪٽي ڇڏيو آهي. پنهنجي لاءِ ۽ ايندڙ نسلن جي ترقيءَ لاءِ. ZFS ماضي جي شيء آهي. ۽ ext4 ۽ XFS اڄ به ڪالهه کان اڳ نه آهن.
اهو "اڳيون نسل جي لينڪس فائيل سسٽم" جي حساس تصور بابت الڳ الڳ ذڪر ڪرڻ جي قابل آهي. اهو هڪ مڪمل طور تي سياسي ۽ مارڪيٽنگ پروجيڪٽ آهي موقعو لاءِ پيدا ڪيو ويو آهي، تنهن ڪري ڳالهائڻ لاءِ، ”فائل سسٽم جو مستقبل پنڻ“ لاءِ لينڪس ۾ مخصوص ڪردارن جي پويان. حقيقت اها آهي ته لينڪس استعمال ڪيو ويو "صرف مذاق لاء". پر هاڻي اهو بنيادي طور تي پئسا ٺاهڻ واري مشين آهي. اهي هر ممڪن تي ٺهيل آهن. مثال طور، هڪ سٺي سافٽ ويئر پراڊڪٽ ٺاهڻ تمام ڏکيو آهي، پر سمارٽ ”ڊولپرز“ گهڻي وقت کان اهو محسوس ڪري چڪا آهن ته ڪنهن به قسم جي دٻاءُ جي ضرورت ناهي: توهان ڪاميابيءَ سان غير موجود سافٽ ويئر وڪرو ڪري سگهو ٿا، جنهن جو اعلان ۽ پروموشن هر قسم جي عوام ۾ ڪيو ويو هو. واقعا - بنيادي شيء اها آهي ته پريزنٽيشن سلائڊ وڌيڪ "خصوصيت" تي مشتمل هجڻ گهرجي.
فائل سسٽم هن لاء مڪمل آهن، ڇاڪاڻ ته توهان نتيجن تي ڏهن سالن تائين محفوظ طور تي واپار ڪري سگهو ٿا. يقينن، جيڪڏهن ڪو ماڻهو بعد ۾ شڪايت ڪري ٿو ته هن نتيجن جي کوٽ جي باري ۾، پوء هو صرف فائل سسٽم بابت ڪجهه به نه سمجهي! هي هڪ مالي پرامڊ جي ياد ڏياريندو آهي: چوٽي تي اهي سياح آهن جن هن گندگي کي شروع ڪيو، ۽ اهي ٿورڙا جيڪي "خوش قسمت" هئا: انهن "تقسيم واپس ورتو،" يعني. ترقي لاءِ پئسا مليا، مئنيجر جي حيثيت سان سٺي ادا ڪيل نوڪري ملي، ڪانفرنسن ۾ ”ظاهر ٿيل“ وغيره.
اڳتي اچن اهي آهن جيڪي ”بدقسمتي“ آهن: اهي نقصان ڳڻندا، هڪ ناقابل استعمال سافٽ ويئر پراڊڪٽ کي پيداوار ۾ آڻڻ جي نتيجن سان ڊيل ڪندا، ”وغيره. انهن مان ڪيترائي گهڻا آهن. خير، پرامڊ جي بنياد تي ڊولپرز جو هڪ وڏو ميڙ آهي "ڏسڻ" بيڪار ڪوڊ. اهي سڀ کان وڏي نقصان وارا آهن، ڇاڪاڻ ته ضايع ٿيل وقت واپس نه ٿو ڪري سگهجي. اهڙا پرامڊ Torvalds ۽ سندس ساٿين لاءِ انتهائي فائديمند آهن. ۽ انهن پرامڊن مان وڌيڪ، انهن لاءِ بهتر. اهڙين pyramids کي کارائڻ لاء، ڪا به شيء بنيادي ۾ وٺي سگهجي ٿو. يقينن، عوام ۾ اهي سامهون چوندا آهن. پر مان لفظن سان نه پر عمل سان فيصلو ڪريان ٿو.
تنهن ڪري، "لينڪس ۾ فائيل سسٽم جو مستقبل" اڃا تائين هڪ ٻيو انتهائي ترقي يافته آهي، پر مشڪل طور تي استعمال لائق سافٽ ويئر. Btrfs کان پوء، وڏي امڪان سان، اهڙي "مستقبل" جي جڳهه Bcachefs طرفان ورتو ويندو، جيڪو هڪ ٻي ڪوشش آهي لينڪس بلاڪ پرت کي فائيل سسٽم سان پار ڪرڻ جي (هڪ خراب مثال متضاد آهي). ۽ ڇا عام آهي: اتي ساڳيا مسئلا آهن جيئن Btrfs ۾. مون کي هڪ ڊگهي وقت تائين شڪ ٿيو، ۽ پوء ڪنهن به طرح مون کي مزاحمت نه ٿي سگهي ۽ ڪوڊ ۾ ڏٺو - اهو سچ آهي!
Bcachefs ۽ Btrfs جا ليکڪ، جڏهن انهن جي FS ٺاهي، فعال طور تي ٻين ماڻهن جي ذريعن کي استعمال ڪيو، انهن بابت ٿورو سمجهي. صورتحال ٻارن جي راند "ٽڙيل فون" جي تمام گهڻو ياد ڏياريندڙ آهي. ۽ مان تقريبن تصور ڪري سگهان ٿو ته هي ڪوڊ ڪتن ۾ ڪيئن شامل ڪيو ويندو. دراصل، ڪو به نه ڏسندو "ريڪس" (هرڪو بعد ۾ انهن تي قدم رکندو). ڪوڊ جي انداز جي باري ۾ ڪيترن ئي quibbles کان پوء، غير موجود خلاف ورزين جي الزامن وغيره، ليکڪ جي "وفاداري" جي باري ۾ هڪ نتيجو ڪڍيو ويندو، هو ٻين ڊولپرز سان ڪيترو سٺو "تعلق" ڪري ٿو، ۽ اهو سڀ ڪجهه ڪاميابيء سان ڪيئن ٿي سگهي ٿو. پوء ڪارپوريشن کي وڪرو ڪيو وڃي.
آخر نتيجو ڪنهن کي به دلچسپي نه ڏيندو. ويهه سال اڳ، شايد، مون کي دلچسپي هجي ها، پر هاڻي سوال مختلف انداز ۾ اٿاريا ويا آهن: ڇا اهو ممڪن ٿيندو ته ان کي فروغ ڏنو وڃي ته ايندڙ ڏهن سالن ۾ ڪجهه خاص ماڻهن کي ملازمت ڏني ويندي. ۽، افسوس، اهو آخري نتيجو بابت تعجب ڪرڻ جو رواج ناهي.
عام طور تي، مان سختي سان سفارش نه ڪندس ته شروع کان توهان جي فائيل سسٽم کي ايجاد ڪرڻ شروع ڪريو. ڇو ته ڏهن سالن ۾ مقابلي ۾ ڪجهه حاصل ڪرڻ لاءِ به اهم مالي سيڙپڪاري ڪافي نه هوندي. يقينن، مان سنجيده منصوبن جي باري ۾ ڳالهائي رهيو آهيان، ۽ انهن بابت نه جن جو ارادو ڪيو وڃي ٿو "دٻايو" ڪني ۾. تنهن ڪري، پنهنجو پاڻ کي ظاهر ڪرڻ جو هڪ وڌيڪ مؤثر طريقو آهي حقيقي ترقي ۾ شامل ٿيڻ، اسان وانگر. اهو، يقينا، ڪرڻ آسان ناهي - پر اهو معاملو ڪنهن به اعلي سطحي منصوبي سان آهي.
پهرين، توهان کي آزاديء سان ان مسئلي کي حل ڪرڻ جي ضرورت پوندي جيڪا آئون پيش ڪندس. جنهن کان پوءِ اوهان جي ارادن جي سنجيدگيءَ جو قائل ٿي، مان مدد ڪرڻ لڳندس. روايتي طور تي، اسان صرف اسان جي پنهنجي ترقي کي استعمال ڪندا آهيون. استثنا آهن کمپريشن الگورتھم ۽ ڪجهه هيش افعال. اسان ڊولپرز کي ڪانفرنسن ڏانهن سفر ڪرڻ لاءِ نه موڪليندا آهيون، ۽ پوءِ اسان نه ويهندا آهيون ۽ ٻين ماڻهن جي خيالن کي گڏ ڪندا آهيون ("شايد ڇا ٿيندو")، جيئن اڪثر شروعاتن ۾ رواج آهي.
اسان سڀ الگورتھم پاڻ کي ترقي ڪريون ٿا. مان هن وقت ڊيٽا اسٽوريج سائنس جي الجبري ۽ گڏيل پهلوئن ۾ دلچسپي وٺان ٿو. خاص طور تي، محدود شعبن، asymptotics، عدم مساوات جو ثبوت. عام پروگرامرز لاءِ پڻ ڪم آهي، پر مون کي توهان کي فوري طور تي ڊيڄارڻ گهرجي: سڀني تجويزن کي "ٻيو FS ڏسو ۽ ساڳيو ڪريو" کي نظرانداز ڪيو ويو آهي. وي ايف ايس ذريعي لينڪس سان ويجهي انضمام جو مقصد پڻ اتي ويندا.
تنهن ڪري، اسان وٽ هڪ ريڪ ناهي، پر اسان کي اها ڄاڻ آهي ته اسان کي ڪٿي وڃڻ جي ضرورت آهي، ۽ اسان کي يقين آهي ته هي هدايت صحيح آهي. اها سمجھ آسمان مان من جي صورت ۾ نه آئي. مان توهان کي ياد ڏياران ٿو ته اسان جي پويان 29 سالن جو ترقياتي تجربو آهي، ٻه فائل سسٽم شروع کان لکيل آهن. ۽ ڊيٽا واپس آڻڻ جي افاديت جو ساڳيو تعداد. ۽ هي تمام گهڻو آهي!
جو ذريعو: opennet.ru