د Reiser4 فایل سیسټم جوړونکي، اډوارډ ششکین سره دویمه مرکه خپره شوې.
د پیل کولو لپاره، مهرباني وکړئ لوستونکو ته یادونه وکړئ چې چیرته او د چا لپاره کار کوئ.
زه د آلمان د څیړنیز مرکز Huawei ټیکنالوژۍ کې د اصلي ذخیره کولو معمار په توګه کار کوم. د مجازی کولو څانګه کې زه د ډیټا ذخیره کولو مختلف اړخونو سره معامله کوم. زما فعالیتونه په ځانګړي عملیاتي سیسټم پورې تړاو نلري.
ایا تاسو اوس مهال د کرنل اصلي څانګې ته ژمن یاست؟
په ندرت سره، او یوازې که زما کارمند ورته اړتیا ولري. وروستی ځل شاوخوا درې کاله دمخه و ، ما د 9p پروتوکول په کارولو سره په کوربه کې شریک شوي ذخیره کولو لپاره د ټرپټ زیاتولو لپاره پیچونه واستول (د دې سوداګرۍ بل نوم VirtFS دی). یو مهم یادونه باید دلته وشي: که څه هم زه د اوږدې مودې راهیسې د لینکس سره کار کوم ، زه هیڅکله د دې مینه وال نه یم ، دا دی ، زه "په مساوي ډول تنفس کوم" لکه د نورو هرڅه سره. په ځانګړې توګه، که زه یو نیمګړتیا وګورم، زه کولی شم په یو ځل یې په ګوته کړم. او د دې لپاره چې تاسو کولی شئ یو څوک تعقیب کړئ او هغوی قانع کړئ - دا به پیښ نشي.
زه وروستی ځل په یاد لرم، لس کاله دمخه، تاسو د کرنل پراختیا سټایل خورا مهم و. ستاسو (یا شاید کارپوریټ) له نظره، ایا کوم بدلون راغلی، آیا ټولنه ډیره ځواب ورکوونکې شوې که نه؟ که نه، ستاسو په اند څوک ملامت دی؟
ما هیڅکله د ښه لپاره کوم بدلون نه دی لیدلی. د ټولنې اصلي ستونزه د سیاسي ټیکنالوژۍ سره د ساینس ځای په ځای کول، شخصي اړیکې، د اکثریت نظر، پاپولزم، د "داخلي غږونو" مشورې، سړې موافقتنامې، د ساینس پرته بل څه. د کمپیوټر ساینس، هر هغه څه چې ویل کیدی شي، لومړی او تر ټولو مهم یو دقیق ساینس دی. او که څوک د 2x2 لپاره د خپل ارزښت اعلان پیل کړي، د 4 څخه توپیر لري، د "لینکس لارې" بیرغ لاندې، یا د کوم بل بیرغ لاندې، نو دا امکان نلري چې له زیان پرته بل څه راوړي.
ټولې ستونزې په اصل کې د هغو کسانو د بې کفایتۍ او د زده کړې نشتوالي له امله دي چې پریکړې کوي. که یو مدیر بې کفایته وي، هغه نشي کولی یو هدف، مناسب پریکړه وکړي. که هغه هم بې فرهنګه وي، هغه د دې توان نلري چې یو وړ متخصص پیدا کړي چې ورته سمه مشوره ورکړي. د لوړ احتمال سره، انتخاب به په یو سکیمر باندې راټیټ شي څوک چې وايي "په ښکاره ډول سم شیان." یو فاسد چاپیریال تل د بې کفایته رهبرانو شاوخوا وده کوي. سربېره پر دې، تاریخ په دې برخه کې هیڅ استثنا نه پیژني، او ټولنه د دې روښانه تصدیق کوي.
تاسو د Btrfs پراختیا کې پرمختګ څنګه ارزوئ؟ ایا دا FS د ماشومتوب ناروغیو څخه خلاص شوی؟ تاسو دا څنګه د ځان لپاره ځای په ځای کوئ - د FS په توګه "د کور لپاره" یا د کارپوریټ کارونې لپاره؟
زه له دې څخه خلاص نه شوم. هر هغه څه چې ما 11 کاله دمخه یادونه وکړه نن ورځ هم اړونده دي. د Btrfs سره یو له ستونزو څخه چې دا د جدي اړتیاو لپاره مناسب نه کوي د خالي ځای ستونزه ده. زه حتی د دې حقیقت په اړه خبرې نه کوم چې له کارونکي څخه غوښتنه کیږي چې د نوي ډیسک لپاره پلورنځي ته په داسې شرایطو کې وګرځي چیرې چې کوم بل FS به په ویش کې ډیر خالي ځای وښیې. د خالي ځای نشتوالي له امله په منطقي حجم کې د عملیاتو بشپړولو کې پاتې راتلل هم ترټولو بد شی ندی. تر ټولو بد شی دا دی چې یو بې ګټې کاروونکي کولی شي نږدې تل، د ډیسک هرې کوټې څخه تیریږي، هرڅوک په کافي لنډ وخت کې د وړیا ځای څخه محروم کړي.
دا داسې ښکاري (د لینکس کرنل 5.12 لپاره ازمول شوی). یو سکریپټ په تازه نصب شوي سیسټم کې پیل شوی، کوم چې په لوپ کې د کور ډایرکټر کې د ځانګړو نومونو سره فایلونه رامینځته کوي، دوی ته په ځینو آفسیټونو کې ډاټا لیکي، او بیا دا فایلونه حذف کوي. د دې سکریپټ چلولو یوه دقیقه وروسته، هیڅ غیر معمولي نه پیښیږي. د پنځو دقیقو وروسته، په ویش کې د اشغال شوي ځای برخه یو څه زیاتیږي. د دوو څخه تر دریو ساعتونو وروسته دا 50٪ ته رسیږي (د ابتدايي ارزښت 15٪ سره). او د پنځه یا شپږ ساعتونو کار وروسته ، سکریپټ د خطا سره ټکر کیږي "په تقسیم کې هیڅ خالي ځای شتون نلري." له دې وروسته، تاسو نور نشئ کولی حتی د 4K فایل خپل برخې ته ولیکئ.
یو په زړه پوری وضعیت پیښیږي: تاسو د برخې برخې ته هیڅ نه و لیکلی، او ټول خالي ځای (شاوخوا 85٪) یو ځای ورک شوی. د یوې برخې تحلیل چې د ورته برید تابع وي د ونې ډیری نوډونه به په ګوته کړي چې یوازې یو توکي لري (یو څیز چې په کیلي سمبال شوی) ، څو بایټس اندازه لري. دا دی، هغه مینځپانګه چې دمخه یې د ډیسک 15٪ ځای نیولی و په مساوي ډول په ټوله برخه کې "خراب شوی" وګرځید ترڅو د نوي فایل لیکلو لپاره هیڅ ځای شتون ونلري ، ځکه چې کیلي یې د ټولو موجوده فایلونو څخه لوی دی ، او وړیا. په تقسیم کې بلاکونه ختم شوي دي.
سربیره پردې ، دا ټول دمخه د Btrfs په لومړني ترتیب کې پیښیږي (پرته له کوم عکس شاټونو ، فرعي حجمونو ، او داسې نور) ، او دا مهمه نده چې تاسو څنګه پریکړه کوئ چې په FS کې د فایل بدن ذخیره کړئ (په ونه کې د "ټوکو" په توګه ، یا د حد په توګه. د غیر فارمیټ شوي بلاکونو) - پای پایله به ورته وي.
تاسو به نشئ کولی د نورو اپ سټریم فایل سیسټم داسې برید ته تابع کړئ (هیڅ اهمیت نلري چې دوی تاسو ته څه وايي). ما د ستونزې لامل ډیر وخت وړاندې تشریح کړی و: دا په Btrfs کې د B-tree مفهوم بشپړ انحراف دی، کوم چې دا په ناڅاپي یا قصدي توګه د تخریب امکان رامینځته کوي. په ځانګړې توګه، د ځانګړو بارونو الندې، ستاسو د فایل سیسټم به په دوامداره توګه د بهرنۍ مرستې پرته، پخپله د عملیاتو په جریان کې "جلا راوتلی" وي. دا روښانه ده چې هر ډول "د فشار" شالید پروسې به ورځ یوازې په انفرادي ډیسټاپونو کې خوندي کړي.
په ډله ایزو سرورونو کې، یو برید کونکی به تل د دې توان ولري چې د دوی څخه "مخکې" شي. د سیسټم مدیر به حتی د دې توان ونلري چې دا معلومه کړي چې چا په ریښتیا هغه ځوروي. په Btrfs کې د دې ستونزې د حل کولو ترټولو ګړندۍ لاره د منظم B ونې جوړښت بحالول دي، د بیلګې په توګه. د ډیسک فارمیټ بیا ډیزاین کول او د Btrfs کوډ د پام وړ برخې بیا لیکل. دا به 8-10 کاله وخت ونیسي، د ډیبګ کولو په شمول، په دې شرط چې پراختیا کونکي د اړونده الګوریتمونو او ډیټا جوړښتونو اصلي مقالې په کلکه تعقیب کړي، او د "مات شوي تلیفون" لوبه ونه کړي، لکه څنګه چې په "لینکس" کې دودیز (او هڅول شوي) دي. لاره".
دلته موږ د پراختیا کونکو لپاره د دې ټولو پوهیدو لپاره اړین وخت اضافه کولو ته هم اړتیا لرو. دا هغه ځای دی چې دا ډیر ستونزمن کیږي. په هرصورت، 10 کاله د دوی د پوهیدو لپاره کافي نه وو. ښه، تر هغه وخته پورې تاسو د معجزې تمه نشئ کولی. دا به د نصب کولو اختیار په بڼه نه پیښ شي "چې تاسو او زه یې په اړه نه پوهیږو،" یا د پیچ په بڼه چې چمتو کول "یوازې د سوداګرۍ مسله" ده. د هر ډول ګړندي "اصلاح" لپاره زه به د تخریب نوې سناریو وړاندې کړم. بی ونې زما د خوښې وړ موضوعاتو څخه دي، او زه باید ووایم چې دا جوړښتونه له ځانه سره د ازادۍ زغم نه لري!
زه څنګه د خپل ځان لپاره Btrfs ځای په ځای کړم؟ د یو څه په توګه چې په بشپړ ډول نشي کولی د فایل سیسټم په نوم یاد شي، اجازه راکړئ چې کارول شي. ځکه چې، د تعریف له مخې، FS د OS فرعي سیسټم دی چې د "ډیسک ځای" سرچینې اغیزمن مدیریت لپاره مسؤل دی، کوم چې موږ د Btrfs په قضیه کې نه ګورو. ښه ، تصور وکړئ چې تاسو پلورنځي ته د ساعت پیرودلو لپاره راغلی یاست ترڅو کار ته ناوخته نه شئ ، او دوی د ساعت پرځای تاسو ته د 30 دقیقو لپاره د ټایمر سره بریښنایی گرل وپلورل. نو، د Btrfs وضعیت نور هم خراب دی.
د میلینګ لیستونو په لټه کې ، زه ډیری وختونه په دې بیان کې راځي چې په مؤثره توګه د ډیسک ځای اداره کول د ډرایو ارزانه کیدو له امله نور اړوند ندي. دا په بشپړه توګه احمقانه ده. د مؤثره ډیسک ځای مدیر پرته ، OS به زیان منونکي او د کارولو وړ نه وي. ستاسو په ماشین کې د ډیسکونو ظرفیت ته په پام سره.
زه غواړم په RHEL کې د Btrfs ملاتړ بندولو په اړه د نظر غوښتنه وکړم.
دلته د تبصرې لپاره کوم ځانګړی ندی، هرڅه خورا روښانه دي. دوی دا د "ټیکنالوژۍ لید" په توګه هم درلود. نو ، زه د دې خورا "مخکیني" څخه نه یم تللی. اجازه مه ورکوئ چې دا لیبل د تل لپاره ځړول شي! مګر دوی نشي کولی د بشپړ ملاتړ سره نیمګړی ډیزاین محصول پیل کړي. RHEL یوه تصدۍ ده، یعني د اجناسو او پیسو ټاکل شوې اړیکې. Red Hat نشي کولی کاروونکي ځوروي لکه څنګه چې دوی د Btrfs میلینګ لیست کې کوي. یوازې د وضعیت تصور وکړئ: یو پیرودونکی چې د ډیسک لپاره یې خپلې سختې لاسته راوړنې پیسې ورکړې او تاسو یې هم د ملاتړ لپاره ، غواړي پوه شي چې د هغه د ډیسک ځای چیرته تللی وروسته له هغه چې هغه څه ونه لیکل. دې ته به څه ځواب ورکوې؟
نور. د Red Hat په پیرودونکو کې مشهور لوی بانکونه او تبادلې شامل دي. تصور وکړئ چې څه به پیښ شي که چیرې دوی په Btrfs کې د ذکر شوي زیان مننې پراساس د DoS بریدونو تابع وي. ستاسو په اند څوک د دې مسؤول دي؟ هغو کسانو ته چې د GPL جواز لیکې ته ګوته نیسي ، چیرې چې لیکل شوي چې لیکوال د هیڅ شی لپاره مسؤل ندي ، زه به سمدلاسه ووایم: "دا پټ کړئ!" ریډ هیټ به ځواب ووایی ، او په داسې ډول چې دا به کافي نه ښکاري! مګر زه پوهیږم چې ریډ هیټ د دې ډول ستونزې سره مخ نه دی، د دوی په ځانګړي ډول د QA انجنیرانو قوي ټیم ته په پام سره چې ما په خپل وخت کې د نږدې کار کولو فرصت درلود.
ولې ځینې شرکتونه په خپلو تصدیو محصولاتو کې د Btrfs ملاتړ ته دوام ورکوي؟
مهرباني وکړئ په یاد ولرئ چې د محصول په نوم کې د "شرکت" مختګ ډیر معنی نلري. تصدۍ د مسؤلیت اندازه ده چې د پیرودونکي سره د تړون په اړیکه کې ځای په ځای شوي. زه یوازې د GNU/Linux - RHEL پر بنسټ یو شرکت پیژنم. نور هرڅه، زما له نظره، یوازې د یوې تصدۍ په توګه وړاندې کیږي، مګر یو نه دی. او په نهایت کې ، که چیرې د یو څه غوښتنه وي ، نو تل به عرضه وي (زموږ په قضیه کې ، دا ذکر شوی "ملاتړ" دی). د هر څه لپاره غوښتنه شتون لري، په شمول. او بې کاره سافټویر. دا ډول غوښتنې څنګه رامینځته کیږي او څوک یې غوړوي بله موضوع ده.
نو، زه به کومې پایلې ته ورسیږم وروسته له دې چې فیسبوک په خپلو سرورونو کې د Btrfs ځای په ځای کولو افواه کوي. سربیره پردې ، زه به د پورتنیو دلایلو لپاره د دې سرورونو پتې په احتیاط سره پټ ساتلو وړاندیز وکړم.
ولې پدې وروستیو کې د XFS کوډ پاکولو کې دومره هڅې شوي؟ په هرصورت ، په پیل کې دا د دریمې ډلې فایل سیسټم دی ، او ext4 د اوږدې مودې لپاره باثباته دی او د تیرو مساوي مستحکم نسخو څخه دوام لري. Red Hat په XFS کې کومه علاقه لري؟ ایا دا معنی لري چې په فعاله توګه دوه فایل سیسټمونه په ورته هدف کې رامینځته کړي - ext4 او XFS؟
زه په یاد نه یم چې دا څه هڅولي. دا خورا ممکنه ده چې نوښت د Red Hat مراجعینو څخه راغلی وي. زما په یاد دي چې دا ډول څیړنه ترسره شوې وه: د پورته څخه ځینې فایل سیسټمونو کې، د نوي نسل په لوړ پای ډرایو کې یو لوی شمیر توکي رامینځته شوي. د پایلو په وینا، XFS د ext4 څخه ښه چلند وکړ. نو دوی دا د خورا ژمنې په توګه هڅول پیل کړل. په هر حالت کې، زه به دلته کوم حساس شی ونه ګورم.
زما لپاره، دا داسې دی لکه دوی د صابون سره awl بدل کړی. د ext4 او XFS په پراختیا کې هیڅ معنی نشته. دواړه په موازي ډول او هر یو یې د غوره کولو لپاره. له دې څخه هیڅ ښه نه راځي. که څه هم، په طبیعت کې ډیری وختونه داسې شرایط شتون لري کله چې د ودې لپاره ډیر امکانات شتون ولري، مګر د ودې لپاره هیڅ ځای شتون نلري. په دې حالت کې، مختلف عجیب بدمرغه نوې وده رامنځته کیږي، کوم چې هرڅوک ګوتې په ګوته کوي ("او، وګورئ، هغه څه چې تاسو به پدې ژوند کې ونه ګورئ!").
ایا تاسو فکر کوئ چې د پرت سرغړونې مسله په ext4، F2FS کې د کوډ کولو افعالونو په راتګ سره حل شوې (په منفي معنی کې) (په Btrfs کې د RAID یادونه نه کول)؟
په عموم کې، د هرې کچې معرفي کول او د دوی د نه سرغړونې په اړه پریکړه کول معمولا د پالیسۍ مسله ده، او زه دلته د هیڅ شی په اړه تبصره نه کوم. د پرت سرغړونې هدف اړخونه د هرچا لپاره لږ علاقه لري، مګر موږ کولی شو د سرغړونې مثال په کارولو سره ځینې یې په پام کې ونیسو "له پورته څخه"، د بیلګې په توګه، د فعالیت په FS کې پلي کول چې دمخه د بلاک پرت کې شتون لري. دا ډول "سرغړونې" یوازې د نادر استثنا سره توجیه کیږي. د داسې هرې قضیې لپاره، تاسو باید لومړی دوه شیان ثابت کړئ: دا واقعیا اړتیا لري، او دا چې د سیسټم ډیزاین به د دې کولو سره زیان ونه رسوي.
د مثال په توګه، عکس اخیستل، چې په دودیز ډول د بلاک پرت لپاره یو فعالیت دی، د فایل سیسټم په کچه پلي کولو لپاره معنی لري. د مختلفو دلیلونو لپاره. د مثال په توګه، "خاموش" ډیټا فساد (بټ روټ) په ډیسک ډرایو کې پیښیږي. دا هغه وخت دی چې وسیله په سمه توګه کار کوي، مګر د بلاک ډیټا په غیر متوقع ډول د سخت ګاما کوانټم تر اغیز لاندې زیانمن کیږي چې د لرې کواسار لخوا خارج کیږي. ترټولو بد شی دا دی که چیرې دا بلاک د FS سیسټم بلاک شي (سوپر بلاک ، بټ میپ بلاک ، د ذخیره کولو ونې نوډ ، او داسې نور) ، ځکه چې دا به یقینا د کرنل ویره رامینځته کړي.
مهرباني وکړئ په یاد ولرئ چې د بلاک پرت لخوا وړاندیز شوي عکسونه (د RAID 1 په نوم یادیږي) به تاسو له دې ستونزې نه وژغوري. ښه، واقعیا: یو څوک باید چکسمونه وګوري او د ناکامۍ په صورت کې نقل ولولي؟ سربیره پردې ، دا معنی لري چې نه یوازې د هرڅه عکس کول ، مګر یوازې میټاډاټا. ځینې مهم معلومات (د بیلګې په توګه، د مهمو غوښتنلیکونو د اجرا وړ فایلونه) د میټاډاټا په توګه زیرمه کیدی شي. په دې حالت کې، دوی د خوندیتوب ورته تضمین ترلاسه کوي. دا معنی لري چې د پاتې معلوماتو ساتنه نورو فرعي سیسټمونو ته وسپاري (شاید حتی د کارونکي غوښتنلیکونه) - موږ د دې لپاره ټول اړین شرایط چمتو کړي دي.
دا ډول "اقتصادي" عکسونه د شتون حق لري، او دوی یوازې د فایل سیسټم په کچه په مؤثره توګه تنظیم کیدی شي. که نه نو، د پرت کولو سرغړونه د ځینې مایکروسکوپی ګټو لپاره د نقل شوي کوډ سره د فرعي سیسټم ګډوډ کول دي. د دې یوه ښه بیلګه د FS په کارولو سره د RAID-5 پلي کول دي. دا ډول حلونه (په فایل سیسټم کې خپل RAID / LVM) وروستی په معماري شرایطو کې وژني. دلته دا هم باید په پام کې ونیول شي چې د پرتې سرغړونې د مختلف ډوله بازار موندنې سکیمرانو لخوا "په جریان کې اچول" کیږي. د کوم نظرونو په نشتوالي کې، فعالیت چې د اوږدې مودې لپاره په ګاونډیو کچو کې پلي شوی په فرعي سیسټمونو کې اضافه کیږي، دا د نوي خورا ګټور خصوصیت په توګه وړاندې کیږي او په فعاله توګه هڅول کیږي.
Reiser4 د "لاندې څخه" د کچې په سرغړونې تورن و. د دې حقیقت پراساس چې د فایل سیسټم واحد نه دی ، لکه د نورو ټولو په څیر ، مګر ماډلر ، یو غیر ثابت انګیرنه رامینځته شوې چې دا هغه څه کوي چې پورته کچه (VFS) باید وکړي.
ایا دا ممکنه ده چې د ReiserFS v3.6 مړینې په اړه خبرې وکړئ او د مثال په توګه، JFS؟ په دې وروستیو کې دوی په اصلي برخه کې نږدې هیڅ پاملرنه نه ده کړې. ایا دوی ناپاک دي؟
دلته موږ باید دا تعریف کړو چې د سافټویر محصول مړینه څه معنی لري. له یوې خوا، دوی په بریالیتوب سره کارول کیږي (دا هغه څه دي چې دوی د دې لپاره رامینځته شوي، وروسته له دې)، پدې معنی چې دوی ژوند کوي. له بلې خوا، زه د JFS لپاره خبرې نشم کولی (زه ډیر نه پوهیږم)، مګر ReiserFS (v3) د نوي رجحاناتو سره سمون کول خورا ستونزمن دي (په عمل کې ازمول شوي). دا پدې مانا ده چې په راتلونکي کې پراختیا کونکي به دې ته پام نه کوي ، مګر هغه ته چې د تطبیق لپاره اسانه دي. له دې اړخه دا معلومه شوه چې افسوس، دا د معمارۍ شرایطو کې مړ دی. زه به په هیڅ ډول د "اخلاقي متروک" مفکوره له مینځه یوسم. دا ښه تطبیق کیږي، د بیلګې په توګه، په المارۍ کې، مګر د سافټویر محصولاتو لپاره نه. په یو څه کې د کموالي او غوره والي مفهوم شتون لري. زه په بشپړ ډول ویلای شم چې ReserFS v3 اوس په هرڅه کې د Reiser4 څخه ټیټ دی ، مګر د کار بار ځینې ډولونو کې دا د نورو ټولو اپ سټریم FSs څخه غوره دی.
ایا تاسو د FS Tux3 او HAMMER/HAMMER2 (FS for DragonFly BSD) د پراختیا په اړه پوهیږئ؟
هو، موږ پوهیږو. په Tux3 کې زه یوځل د دوی د سنیپ شاټونو ټیکنالوژۍ سره علاقه درلوده (د "نسخه پوائنټرز" په نوم یادیږي) ، مګر په ریزر 4 کې به موږ ډیری احتمال یو بل لارې ته ځو. زه د اوږدې مودې لپاره د سنیپ شاټونو ملاتړ کولو په اړه فکر کوم او تراوسه یې پریکړه نه ده کړې چې څنګه یې د ساده Reiser4 حجمونو لپاره پلي کړم. حقیقت دا دی چې د اوهد روده لخوا وړاندیز شوی د "سست" حوالې ضد تخنیک یوازې د B ونو لپاره کار کوي. موږ دوی نه لرو. د هغو ډیټا جوړښتونو لپاره چې په Reiesr4 کې کارول کیږي، "سست" کاونټرونه ندي تعریف شوي - د دوی معرفي کولو لپاره، دا اړینه ده چې ځینې الګوریتمیک ستونزې حل کړي، کوم چې تر اوسه چا ندي اخیستي.
د هامر په وینا: ما د جوړونکي څخه یوه مقاله ولوستله. علاقه نه لري. بیا بیا، بی ونې. د دې معلوماتو جوړښت په نا امیدۍ سره زوړ دی. موږ دا په تیره پیړۍ کې پریښوده.
تاسو څنګه د شبکې کلستر FSs لکه CephFS/GlusterFS/etc لپاره مخ په زیاتیدونکي غوښتنې ارزونه کوئ؟ ایا دا غوښتنه د شبکې FS په لور د پراختیا کونکو لومړیتوبونو کې بدلون او محلي FS ته ناکافي پاملرنه معنی لري؟
هو، په لومړیتوبونو کې دا ډول بدلون رامنځ ته شوی دی. د محلي فایل سیسټمونو پراختیا په ټپه ولاړه ده. افسوس، د محلي حجمونو لپاره د پام وړ یو څه کول اوس خورا ستونزمن دي او هرڅوک یې نشي کولی. هیڅوک نه غواړي د دوی په پراختیا کې پانګونه وکړي. دا د یو سوداګریز سازمان څخه د ریاضیاتي څیړنو لپاره د پیسو تخصیص کولو په څیر دی - پرته له کوم لیوالتیا څخه به دوی پوښتنه وکړي چې تاسو څنګه کولی شئ په نوي تیورم کې پیسې وګټئ. اوس ځایی FS هغه څه دي چې په جادویی ډول د "بکس څخه بهر" ښکاري او "تل باید کار وکړي" او که دا کار ونکړي ، نو دا د بې پامه ګنګوسې لامل کیږي لکه: "هو ، دوی څه فکر کوي!"
له همدې امله محلي FS ته د پاملرنې نشتوالی، که څه هم په دې سیمه کې لاهم ډیر کار شتون لري. او هو ، هرڅوک د توزیع شوي ذخیره کولو ته مخه کړې ، کوم چې د دمخه موجود ځایی فایل سیسټمونو پراساس جوړ شوی. دا اوس خورا فیشن دی. د "لوی ډیټا" جمله د ډیری لپاره د اډرینالین رش لامل کیږي ، دا د کنفرانسونو ، ورکشاپونو ، لوی معاشونو او نورو سره تړاو لري.
په اصولو کې دا څومره معقول دی چې د شبکې فایل سیسټم د کارن ځای پرځای د کرنل په ځای کې پلي کړئ؟
یوه ډیره معقوله طریقه چې تر اوسه په هیڅ ځای کې نه ده پلي شوې. په عموم کې، دا پوښتنه چې په کوم ځای کې د شبکې فایل سیسټم باید پلي شي "دوه اړخیزه توره" ده. ښه، راځئ چې یو مثال وګورو. پیرودونکي په ریموټ ماشین کې ډاټا ثبتوي. دوی د خندا پاڼو په بڼه د هغې پاڼې کیچ کې راوتلي. دا د کرنل په ځای کې د "پتلي دروازې" شبکې فایل سیسټم لپاره دنده ده. بیا به عملیاتي سیسټم ژر یا وروسته له تاسو څخه وغواړي چې دا پاڼې په ډیسک کې ولیکئ ترڅو دوی خلاص کړي. بیا د IO- فارورډینګ (لیږل) شبکه FS ماډل پلی کیږي. دا ټاکي چې کوم سرور ماشین (سرور نوډ) دا پاڼې به لاړ شي.
بیا د شبکې سټیک په غاړه اخلي (او لکه څنګه چې موږ پوهیږو ، دا د کرنل ځای کې پلي کیږي). بیا، د سرور نوډ دا کڅوړه د ډیټا یا میټاډاټا سره ترلاسه کوي او د بیک انډ ذخیره کولو ماډل ته لارښوونه کوي (د مثال په توګه، محلي FS چې د کرنل په ځای کې کار کوي) دا ټول توکي ثبت کړي. نو، موږ دا پوښتنه راټیټه کړې چې چیرته د "لیږل" او "ترلاسه کولو" ماډلونه باید کار وکړي. که چیرې د دې ماډلونو څخه کوم یو د کارونکي ځای کې تیریږي ، نو دا به په لازمي ډول د شرایطو بدلولو لامل شي (د کرنل خدماتو کارولو اړتیا له امله). د دې ډول سویچونو شمیر د پلي کولو توضیحاتو پورې اړه لري.
که چیرې ډیری داسې سویچونه شتون ولري، نو د ذخیره کولو وسیله (I/O فعالیت) به کم شي. که ستاسو د شالید ذخیره د سست ډیسکونو څخه جوړه شوې وي ، نو تاسو به د پام وړ کمښت ونه ګورئ. مګر که تاسو ګړندي ډیسکونه لرئ (SSD ، NVRAM ، او داسې نور) ، نو د شرایطو سویچ کول دمخه یو "خنډ" کیږي او ، د شرایطو سویچ کولو خوندي کولو سره ، فعالیت د پام وړ لوړ کیدی شي. د پیسو خوندي کولو معیاري لاره د کرنل ځای ته ماډلونه لیږدول دي. د مثال په توګه ، موږ وموندله چې د 9p سرور له QEMU څخه په کوربه ماشین کې کرنل ته حرکت کول د VirtFS فعالیت کې درې چنده زیاتوالي لامل کیږي.
دا، البته، د FS شبکه نه ده، مګر دا په بشپړه توګه د شیانو جوهر منعکس کوي. د دې اصلاح کولو نیمګړتیا د پورټ وړتیا مسلې دي. د ځینو لپاره، وروستی ممکن مهم وي. د مثال په توګه، GlusterFS په هیڅ ډول په دانا کې هیڅ ماډل نلري. د دې څخه مننه ، دا اوس په ډیری پلیټ فارمونو کې کار کوي ، پشمول د NetBSD.
سیمه ایز FSs کوم مفکورې کولی شي د شبکې څخه پور واخلي او برعکس؟
نن ورځ، د شبکې FSs، د یوې قاعدې په توګه، په محلي FSs کې اضافه لري، نو زه نه پوهیږم چې تاسو څنګه د وروستي څخه یو څه پور کولی شئ. ښه، په حقیقت کې، راځئ چې د 4 کارمندانو شرکت په پام کې ونیسو، په کوم کې چې هرڅوک خپل کار کوي: یو یې توزیع کوي، بل یې استوي، دریم یې ترلاسه کوي، څلورم پلورنځي. او پوښتنه، کوم شرکت کولی شي د خپل کارمند څخه پور واخلي چې دا ذخیره کوي، یو څه غلط ښکاري (دا دمخه هغه څه لري چې د اوږدې مودې لپاره یې له هغه څخه پور اخیستی وي).
مګر محلي FSs د شبکې څخه د زده کړې لپاره ډیر څه لري. لومړی، تاسو باید له دوی څخه زده کړئ چې څنګه په لوړه کچه منطقي حجمونه راټول کړئ. اوس تش په نامه "پرمختللي" محلي فایل سیسټمونه په ځانګړي ډول د "مجازی وسیلې" ټیکنالوژۍ په کارولو سره د LVM څخه پور اخیستل شوي منطقي حجمونه راټولوي (هغه ورته ساري پرتینګ سرغړونه چې لومړی په ZFS کې پلي شوې وه). په بل عبارت، د مجازی ادرسونو (د بلاک شمیرو) ژباړه په ریښتیا او بیرته په ټیټه کچه واقع کیږي (د بیلګې په توګه، وروسته له دې چې د فایل سیسټم د I/O غوښتنه خپره کړه).
مهرباني وکړئ په یاد ولرئ چې د بلاک پرت کې ترتیب شوي منطقي حجمونو (نه عکسونو) ته د وسیلو اضافه کول او لرې کول د ستونزو لامل کیږي چې د ورته "ځانګړو" عرضه کونکي په دې اړه خاموش دي. زه په ریښتیني وسیلو کې د ټوټې کیدو په اړه خبرې کوم ، کوم چې کولی شي شیطاني ارزښتونو ته ورسیږي ، پداسې حال کې چې په مجازی وسیله کې هرڅه سم دي. په هرصورت، لږ خلک د مجازی وسیلو سره علاقه لري: هرڅوک علاقه لري چې ستاسو په اصلي وسیلو کې څه پیښیږي. مګر د ZFS په څیر FS (په بیله بیا د LVM سره په ترکیب کې کوم FS) یوازې د مجازی ډیسک وسیلو سره کار کوي (د وړیا څخه د مجازی ډیسک پتې تخصیص کړئ ، دا مجازی وسیلې خراب کړئ ، او داسې نور). او دوی نه پوهیږي چې په ریښتیني وسیلو کې څه پیښیږي!
اوس تصور وکړئ چې تاسو په مجازی وسیلې کې صفر ټوټې لرئ (دا چې تاسو یوازې یو لوی حد هلته ژوند کوئ) ، تاسو خپل منطقي حجم کې ډیسک اضافه کړئ ، او بیا له خپل منطقي حجم څخه بل تصادفي ډیسک لرې کړئ او بیا توازن وکړئ. او داسې څو ځله. دا تصور کول ګران ندي چې په مجازی وسیله کې به تاسو لاهم په ورته حد کې ژوند ولرئ ، مګر په ریښتیني وسیلو کې به تاسو هیڅ ښه ونه ګورئ.
تر ټولو بده دا ده چې تاسو د دې حالت د سمولو توان هم نه لرئ! یوازینی شی چې تاسو یې دلته کولی شئ د فایل سیسټم څخه وغواړئ چې د مجازی وسیله ډیفراګمینټ کړي. مګر هغه به تاسو ته ووایي چې دلته هرڅه عالي دي - یوازې یو حد شتون لري ، ټوټه کول صفر دی ، او دا غوره کیدی نشي! نو، د بلاک په کچه ترتیب شوي منطقي حجمونه د بار بار اضافه کولو/د وسیلو لرې کولو لپاره ندي. په ښه توګه، تاسو اړتیا لرئ چې یوازې یو ځل د بلاک په کچه منطقي حجم راټول کړئ، د فایل سیسټم ته یې ورکړئ، او بیا یې نور څه مه کوئ.
برسېره پردې، د خپلواک FS+LVM فرعي سیسټمونو ترکیب اجازه نه ورکوي چې د ډرایو مختلف نوعیت په پام کې ونیسي چې له هغې څخه منطقي حجمونه راټول شوي. په حقیقت کې ، فرض کړئ چې تاسو د HDD او سالډ ریاست وسیلو څخه منطقي حجم راټول کړی. مګر بیا به پخوانی د تخریب کولو ته اړتیا ولري، او وروستی به نه. د وروستي لپاره، تاسو اړتیا لرئ چې د رد کولو غوښتنې صادر کړئ، مګر د پخوانیو لپاره، نه، او داسې نور. په هرصورت، په دې ترکیب کې دا خورا ستونزمن کار دی چې دا ډول انتخاب وښيي.
په یاد ولرئ چې د فایل سیسټم کې خپل LVM رامینځته کولو وروسته ، وضعیت ډیر ښه نه کیږي. سربیره پردې ، د دې په کولو سره تاسو واقعیا په راتلونکي کې د دې د ښه کیدو احتمال ته د پای ټکی کیږدئ. دا ډیر بد دی. د ډرایو مختلف ډولونه کولی شي په ورته ماشین کې ژوند وکړي. او که د فایل سیسټم د دوی ترمنځ توپیر ونه کړي، نو څوک به؟
بله ستونزه د تش په نامه په انتظار کې ده. "په هر ځای کې ولیکئ" فایل سیسټمونه (په دې کې Reiser4 هم شامل دی، که تاسو د نصب کولو په وخت کې مناسب لیږد ماډل مشخص کړی وي). دا ډول فایل سیسټمونه باید د ډیفراګمینټ وسیلې چمتو کړي چې د دوی په ځواک کې بې ساري دي. او د ټیټې کچې حجم مدیر دلته مرسته نه کوي، مګر یوازې په لاره کې راځي. حقیقت دا دی چې د داسې مدیر سره، ستاسو FS به یوازې د یوې وسیلې وړیا بلاکونو نقشه ذخیره کړي - یو مجازی. په دې اساس، تاسو کولی شئ یوازې یو مجازی وسیله کم کړئ. دا پدې مانا ده چې ستاسو ډیفراګمینټر به د اوږدې مودې لپاره د مجازی ادرسونو لوی واحد ځای کې کار وکړي.
او که تاسو ډیری کاروونکي لرئ چې په تصادفي ډول لیکل کوي، نو د داسې ډیفراګمینټر ګټور اغیزه به صفر ته راټیټ شي. ستاسو سیسټم به حتما ورو ورو پیل کړي ، او تاسو به یوازې د مایوسونکي تشخیص "مات شوي ډیزاین" مخې ته خپل لاسونه وتړئ. په ورته پته ځای کې ډیری ډیفراګمینټرونه به یوازې د یو بل سره مداخله وکړي. دا یو بشپړ توپیر دی که تاسو د هر اصلي وسیلې لپاره د وړیا بلاکونو خپله نقشه وساتئ. دا به په مؤثره توګه د defragmentation پروسه موازي کړي.
مګر دا یوازې هغه وخت ترسره کیدی شي که تاسو د لوړې کچې منطقي حجم مدیر ولرئ. د داسې مدیرانو سره محلي فایل سیسټمونه مخکې شتون نه درلود (لږترلږه، زه د دوی په اړه نه پوهیږم). یوازې د شبکې فایل سیسټمونه (د مثال په توګه GlusterFS) داسې مدیران درلودل. بل خورا مهم مثال د حجم بشپړتیا چیک (fsck) یوټیلیټ دی. که تاسو د هر فرعي حجم لپاره د وړیا بلاکونو خپله خپلواکه نقشه ذخیره کړئ ، نو د منطقي حجم چیک کولو پروسه په مؤثره توګه موازي کیدی شي. په بل عبارت، منطقي حجم د لوړې کچې مدیرانو سره ښه اندازه کوي.
سربیره پردې ، د ټیټ کچې حجم مدیرانو سره به تاسو نشئ کولی بشپړ عکسونه تنظیم کړئ. د LVM او ZFS په څیر فایل سیسټمونو سره، تاسو کولی شئ یوازې محلي سنیپ شاټونه واخلئ، مګر نړیوال سنیپ شاټونه نه. ځایی سنیپ شاټونه تاسو ته اجازه درکوي په سمدستي توګه یوازې د منظم فایل عملیات بیرته راوباسئ. او هیڅوک به هلته د منطقي حجمونو سره عملیات بیرته راوباسي (د وسایطو اضافه کول / لرې کول). راځئ چې دا د مثال په توګه وګورو. په ځینو وختونو کې، کله چې تاسو د دوو وسیلو A او B منطقي حجم لرئ چې 100 فایلونه لري، تاسو د سیسټم S سنیپ شاټ واخلئ او بیا نور سل فایلونه جوړ کړئ.
له هغې وروسته، تاسو په خپل حجم کې C وسیله اضافه کړئ، او په پای کې خپل سیسټم S سنیپ شاټ ته واړوئ. پوښتنه: S ته د رول بیک وروسته ستاسو منطقي حجم څومره فایلونه او وسایل لري؟ 100 فایلونه به وي، لکه څنګه چې تاسو اټکل کړی وي، مګر دلته به 3 وسایل وي - دا ورته وسایل A، B او C دي، که څه هم د سنیپ شاټ په وخت کې په سیسټم کې یوازې دوه وسایل شتون درلود (A او B) ). د اضافې وسیلې C عملیات بیرته نه وګرځیدلي ، او که تاسو اوس له کمپیوټر څخه وسیله C لرې کړئ ، نو دا به ستاسو ډیټا فاسد کړي ، نو د حذف کولو دمخه تاسو اړتیا لرئ لومړی یو ګران عملیات ترسره کړئ ترڅو وسیله د توازن منطقي حجم څخه لرې کړئ ، کوم چې ټول معلومات به د وسیلې C څخه وسیلو A او B ته توزیع کړي. مګر که ستاسو FS د نړیوال سنیپ شاټونو ملاتړ وکړي ، نو دا ډول توازن ته اړتیا نشته ، او S ته د سمدستي رول بیک وروسته ، تاسو کولی شئ په خوندي ډول له کمپیوټر څخه وسیله C لرې کړئ.
نو ، نړیوال سنیپ شاټونه ښه دي ځکه چې دوی تاسو ته اجازه درکوي د لوی مقدار ډیټا سره د منطقي حجم (منطقي حجم ته) څخه د وسیلې د قیمتي لرې کولو (اضافه کولو) څخه مخنیوی وکړئ (البته ، که تاسو په یاد ولرئ خپل سیسټم "سنیپ شاټ" کړئ. په مناسب وخت کې). اجازه راکړئ تاسو ته یادونه وکړم چې د سنیپ شاټونو رامینځته کول او دوی ته د فایل سیسټم بیرته راګرځول سمدستي عملیات دي. پوښتنه راپورته کیدی شي: دا څنګه ممکنه ده چې په سمدستي توګه په منطقي حجم کې یو عملیات بیرته راوباسئ چې تاسو یې درې ورځې وخت نیولی و؟ مګر دا ممکنه ده! په دې شرط چې ستاسو د فایل سیسټم په سمه توګه ډیزاین شوی وي. زه درې کاله دمخه د ورته "3D سنیپ شاټونو" نظر سره راغلم، او تیر کال ما دا تخنیک پیټ کړ.
بل شی چې محلي FSs باید د شبکې څخه زده کړي هغه په جلا وسیلو کې د میټاډاټا ذخیره کول دي په ورته ډول چې د شبکې FSs دوی په جلا ماشینونو (د میټاډاټا سرورونو په نوم یادیږي) ذخیره کوي. داسې غوښتنلیکونه شتون لري چې په ابتدايي توګه د میټاډاټا سره کار کوي، او دا غوښتنلیکونه په ګران لوړ فعالیت ذخیره کولو وسیلو کې د میټاډاټا په ځای کولو سره خورا ګړندي کیدی شي. د FS+LVM ترکیب سره، تاسو به نشئ کولی دا ډول انتخاب وښایئ: LVM نه پوهیږي چې په هغه بلاک کې څه دي چې تاسو ورته لیږدولي دي (ډیټا هلته یا میټاډاټا).
تاسو به د FS + LVM ترکیب په پرتله په FS کې د خپل ټیټ کچې LVM پلي کولو څخه ډیره ګټه ترلاسه نه کړئ ، مګر هغه څه چې تاسو یې خورا ښه کولی شئ د FS ګډوډ کول دي ترڅو وروسته د دې کوډ سره کار کول ناممکن شي. ZFS او Btrfs، کوم چې د مجازی وسیلو سره راوتلی، دا ټول روښانه مثالونه دي چې څنګه د جوړښت سرغړونې سیسټم وژني، نو زه دا ټول ولې یم؟ سربیره پردې ، د فایل سیسټم کې ستاسو د ټیټ کچې LVM نصبولو ته اړتیا نشته. پرځای یې، تاسو اړتیا لرئ چې وسایل په لوړه کچه منطقي حجمونو کې راټول کړئ، لکه څنګه چې د شبکې ځینې فایل سیسټمونه د مختلف ماشینونو (د ذخیره کولو نوډونو) سره ترسره کوي. ریښتیا، دوی دا د بد الګوریتم کارولو له امله په کرکه توګه ترسره کوي.
د بشپړ ډارونکي الګوریتم مثالونه د ګلسټر ایف ایس فایل سیسټم کې د DHT ژباړونکي او د Ceph فایل سیسټم کې د CRUSH نقشه په نوم یادیږي. هیڅ یو الګوریتم چې ما ولیدل ما د سادگي او ښه پیمانه کولو له مخې راضي نه کړ. نو زه باید الجبرا په یاد ولرم او هرڅه پخپله اختراع کړم. په 2015 کې، پداسې حال کې چې د هش افعالونو په اړه د بنډلونو سره تجربه کول، زه د هغه څه سره راغلم او پیټ کړم چې زما سره مناسب وي. اوس زه ویلای شم چې د دې ټولو د عملي کولو هڅه بریالۍ وه. زه په نوې طریقه کې د توزیع کولو سره کومه ستونزه نه وینم.
هو، هر فرعي حجم به جلا جوړښت ته اړتیا ولري لکه په حافظه کې سوپر بلاک. ایا دا ډیر ډارونکی دی؟ په عموم کې، زه نه پوهیږم چې څوک به "سمندر جوش" کړي او په یوه محلي ماشین کې د سلګونو زرو یا ډیرو وسیلو منطقي حجم رامینځته کړي. که څوک ماته دا تشریح کړي، زه به ډیره مننه وکړم. په ورته وخت کې، زما لپاره دا د بازار موندنې بدمرغه ده.
د کرنل بلاک وسیلې فرعي سیسټم کې بدلونونه (د مثال په توګه د blk-mq ظاهري) د FS پلي کولو اړتیاو باندې اغیزه وکړه؟
دوی هیڅ اغیزه نه درلوده. زه نه پوهیږم چې د بلاک پرت کې به څه پیښ شي چې دا به د نوي FS ډیزاین کولو لپاره اړین کړي. د دې فرعي سیسټمونو تعامل انٹرفیس خورا ضعیف دی. د ډرایور اړخ څخه، FS باید یوازې د نوي ډول ډرایو په بڼه اغیزه وکړي، کوم چې د بلاک پرت به لومړی تنظیم شي، او بیا FS (د ریزر 4 لپاره دا به د نوي پلگ انونو ظهور معنی ولري).
ایا د رسنیو د نوو ډولونو راڅرګندېدل (د بیلګې په توګه، SMR، یا د SSDs هر اړخیزه) د فایل سیسټم ډیزاین لپاره بنسټیز نوي ننګونې معنی لري؟
هو. او دا د FS پراختیا لپاره عادي هڅونې دي. ننګونې کیدای شي مختلف او په بشپړه توګه غیر متوقع وي. د مثال په توګه، ما د ډرایو په اړه اوریدلي دي چیرې چې د I/O عملیاتو سرعت د ډیټا د یوې ټوټې اندازې او د هغې آفسیټ پورې خورا ډیر تړاو لري. په لینکس کې، چیرې چې د FS بلاک اندازه نشي کولی د پاڼې اندازې څخه زیات شي، دا ډول ډرایو به د ډیفالټ په واسطه خپل بشپړ وړتیا ونه ښیې. په هرصورت، که ستاسو د فایل سیسټم په سمه توګه ډیزاین شوی وي، نو بیا د دې څخه ډیر څه ترلاسه کولو چانس شتون لري.
ستاسو تر څنګ اوس مهال څومره خلک د Reiser4 کوډ سره کار کوي؟
له هغه څخه لږ چې زه یې غواړم، مګر زه هم د سرچینو شدید کمښت تجربه نه کوم. زه د Reiser4 د پراختیا له سرعت څخه ډیر خوښ یم. زه "اسونه چلولو" ته نه ځم - دا سمه سیمه نه ده. دلته، "که تاسو ډیر په خاموشۍ سره موټر چلوئ، نو تاسو به لاړ شئ!" د عصري فایل سیسټم خورا پیچلی د کرنل فرعي سیسټم دی، د غلط ډیزاین پریکړې چې کولی شي د راتلونکو کلونو بشري کار بیرته راولي.
د یو څه پلي کولو لپاره داوطلبانو وړاندیز کولو سره، زه تل تضمین کوم چې هڅې به خامخا د سمې پایلې لامل شي، کوم چې د جدي اړتیاو غوښتنه کیدی شي. لکه څنګه چې تاسو پوهیږئ، په یوځل کې ډیری داسې تضمین نشي کیدی. په ورته وخت کې ، زه نشم کولی هغه "شمیرې" ودروم چې په بې شرمۍ سره د څرګند نه کارول شوي سافټویر "خصوصیات" ته وده ورکوي ، په سلګونو کاروونکي او پراختیا کونکي غولوي ، او په ورته وخت کې د کرنل غونډو کې ناست او مسکا کوي.
ایا کوم شرکت د Reiser4 پراختیا ملاتړ کولو لپاره لیوالتیا ښودلې؟
هو، داسې وړاندیزونه شتون درلود، په شمول. او د یو لوی پلورونکي څخه. مګر د دې لپاره زه باید بل هیواد ته لاړ شم. له بده مرغه، زه نور د 30 کلن نه یم، زه نشم کولی مات کړم او په لومړي سیټ کې ورته پریږدم.
کوم ځانګړتیاوې اوس مهال د Reiser4 څخه ورک دي؟
د ساده حجمونو لپاره د "بدلولو" فعالیت شتون نلري، ورته ورته چې په ReiserFS (v3) کې موندل کیږي. سربیره پردې، د DIRECT_IO بیرغ سره د فایل عملیات به زیان ونه رسوي. بیا، زه غواړم د دې وړتیا ولرم چې یو حجم په "سیمنټیک فرعي حجمونو" کې جلا کړم، کوم چې ثابت اندازه نلري، او کوم چې د خپلواک حجمونو په توګه نصب کیدی شي. دا ستونزې د پیل کونکو لپاره ښه دي څوک چې غواړي خپل لاس په "اصلي شی" کې هڅه وکړي.
او په نهایت کې، زه غواړم د ساده پلي کولو او ادارې سره د شبکې منطقي حجم ولرم (عصری الګوریتمونه دمخه دا اجازه ورکوي). مګر هغه څه چې Reiser4 به یقینا هیڅکله ونه لري RAID-Z، سکربونه، د خالي ځای کیچونه، 128-bit متغیرات او نور د بازار موندنې بې بنسټه خبرې دي چې د ځینې فایل سیسټمونو پراختیا کونکو ترمنځ د نظرونو کمښت پس منظر کې راپورته شوي.
ایا هرڅه چې اړتیا ورته وي د پلگ انونو لخوا پلي کیدی شي؟
که موږ یوازې د انٹرفیسونو او پلگ انونو (ماډولونو) شرایطو کې خبرې وکړو چې دوی پلي کوي ، نو هرڅه ندي. مګر که تاسو پدې انٹرفیسونو کې اړیکې هم معرفي کړئ ، نو د نورو شیانو په مینځ کې به تاسو د لوړ پولیمورفیزم مفکورې ولرئ ، کوم چې تاسو دمخه یې ترلاسه کولی شئ. تصور وکړئ چې تاسو په فرضي ډول د اعتراض پر بنسټ د چلولو سیسټم کنګل کړی، د لارښوونې پوائنټر ارزښت یې بدل کړی ترڅو بل پلگ ان ته اشاره وکړي چې ورته X انٹرفیس پلي کوي، او بیا سیسټم غیر منجمد کړی ترڅو اجرا کولو ته دوام ورکړي.
که چیرې وروستی کارونکي داسې "بدیل" ته پام ونه کړي، نو موږ وایو چې سیسټم په X انٹرفیس کې د صفر ترتیب پولیمورفیزم لري (یا سیسټم په X انٹرفیس کې متضاد دی، کوم چې ورته شی دی). که اوس تاسو نه یوازې د انٹرفیسونو سیټ لرئ ، بلکه په دوی باندې اړیکې هم لرئ (انټرفیس ګراف) ، نو تاسو کولی شئ د لوړ امرونو پولیمورفیزمونه معرفي کړئ ، کوم چې به دمخه د کوم انٹرفیس "ګاونډي" کې د سیسټم توپیر مشخص کړي. ما دا ډول طبقه بندي ډیر وخت وړاندې معرفي کړه، مګر، له بده مرغه، دا هیڅکله پیښ نه شو.
نو، د پلگ انونو او داسې لوړو پولیمورفیزمونو په مرسته، تاسو کولی شئ هر پیژندل شوی ځانګړتیا تشریح کړئ، په بیله بیا هغه "پوښتنه" وکړئ چې هیڅکله یې یادونه نه ده شوې. زه نشم کولی دا په کلکه ثابت کړم، مګر زه تر اوسه د یو مثال په اړه هم نه پوهیږم. په عموم کې، دې پوښتنې ما ته د فیلکس کلین "ارلینګین پروګرام" یادونه وکړه. په یو وخت کې هغه هڅه وکړه چې ټول جیومیټري د الجبرا د یوې څانګې په توګه وړاندې کړي (په ځانګړې توګه د ګروپ تیوري).
اوس اصلي پوښتنې ته - شیان څنګه اصلي اصلي ته د Reiser4 ترویج سره پرمخ ځي؟ ایا د دې فایل سیسټم د جوړښت په اړه کومې خپرونې شتون درلود چې تاسو یې په وروستۍ مرکه کې خبرې کړې وې؟ دا پوښتنه ستاسو له نظره څومره معقوله ده؟
په عموم کې، موږ د دریو کلونو لپاره په اصلي څانګه کې د شاملولو غوښتنه کوو. په عامه موضوع کې د ریسر وروستۍ تبصره چیرې چې د پلې کولو غوښتنه شوې وه بې ځوابه پاتې شوه. نو نورې ټولې پوښتنې زموږ لپاره ندي. زه په شخصي توګه نه پوهیږم چې ولې موږ اړتیا لرو په ځانګړي عملیاتي سیسټم کې "ضم" کړو. په لینکس کې ، ر lightا د ویج په څیر نه بدلیږي. نو، دلته یو جلا ذخیره شتون لري چې پکې به د مختلف OS لپاره ډیری څانګې بندرونه وي. څوک چې ورته اړتیا لري کولی شي اړوند بندر کلون کړي او هر هغه څه چې تاسو یې غواړئ ترسره کړئ (البته د جواز دننه). ښه، که څوک ورته اړتیا نلري، نو دا زما ستونزه نه ده. پدې مرحله کې ، زه وړاندیز کوم چې د "اصلي لینکس کرنل ته د ترویج" پوښتنې په پام کې ونیسئ لکه څنګه چې حل شوي.
د FS جوړښت په اړه خپرونې اړونده دي، مګر تر اوسه پورې ما یوازې زما د نوي پایلو لپاره وخت موندلی، کوم چې زه یې لوړ لومړیتوب ګڼم. بله خبره دا ده چې زه ریاضی پوه یم او په ریاضیاتو کې هره خپرونه د تیورمونو لنډیز او د هغوی ثبوت دی. هلته له ثبوت پرته د هر څه خپرول د بد خوند نښه ده. که زه د FS د جوړښت په اړه کوم بیان په بشپړ ډول ثابت یا رد کړم، نو پایله به یې داسې انبار وي چې له لارې به یې ترلاسه کول خورا ستونزمن وي. څوک ورته اړتیا لري؟ له همدې امله شاید هرڅه په خپل زاړه شکل کې پاتې شي - د سرچینې کوډ او تبصرې دې ته.
په تیرو څو کلونو کې په Reiser4 کې څه نوي دي؟
د اوږدې مودې انتظار ثبات په پای کې عملي شو. یو له وروستي څرګندیدو څخه یوه بګ وه چې د "نه حذف کیدو" لارښودونو لامل شو. مشکل دا و چې دا یوازې د نوم هش ټکرونو شالید او د ونې نوډ کې د لارښود ریکارډونو ځانګړي موقعیت سره څرګند شو. په هرصورت، زه لاهم د تولید لپاره Reiser4 وړاندیز نشم کولی: د دې لپاره تاسو اړتیا لرئ د تولید سیسټم مدیرانو سره د فعال تعامل سره یو څه کار وکړئ.
موږ په پای کې د خپل اوږدمهاله مفکورې پلي کولو توان درلود - د لیږد مختلف ماډلونه. پخوا، Reiser4 یوازې یو هارډ کوډ شوی Macdonald-Reiser ماډل چلاوه. دا د ډیزاین ستونزې رامینځته کړې. په ځانګړې توګه، د داسې لیږد ماډل کې سنیپ شاټونه ممکن ندي - دوی به د "اوور رائټ سیټ" په نوم د اټومي برخې لخوا فاسد شي. Reiser4 اوس مهال د درې لیږد ماډلونو ملاتړ کوي. د دوی په یوه کې (په هر ځای کې ولیکئ)، د اټومي برخې OVERWRITE SET کې یوازې د سیسټم پاڼې شاملې دي (د ډیسک بټ میپ انځورونه، او نور)، کوم چې "انځور" نشي اخیستل کیدی (د چرګ او هګۍ ستونزه).
نو انځورونه اوس په غوره ممکنه طریقه احساس کیدی شي. په بل لیږد موډل کې، ټول تعدیل شوي پاڼې یوازې د OVERWRITE SET ته ځي (دا په اصل کې خالص ژورنالینګ دی). دا ماډل د هغو کسانو لپاره دی چې د Reiser4 برخې ګړندۍ ټوټې کولو په اړه شکایت کوي. اوس پدې ماډل کې ستاسو ویش به د ReiserFS (v3) په پرتله ګړندی ټوټه ټوټه نشي. ټول درې موجوده ماډلونه، د ځینو ریزرویشنونو سره، د عملیاتو اټوميیت تضمینوي، مګر هغه ماډلونه چې د اتومي وړتیا له لاسه ورکوي او یوازې د برخې بشپړتیا ساتي هم ګټور کیدی شي. دا ډول ماډلونه د هر ډول غوښتنلیکونو (ډیټابیسونو او نورو) لپاره ګټور کیدی شي، کوم چې دمخه یې ځینې دندې ترسره کړي دي. دا خورا اسانه ده چې دا ماډلونه Reiser4 ته اضافه کړئ، مګر ما دا ونه کړل، ځکه چې هیڅوک له ما څخه پوښتنه نه کوي، او زه په شخصي توګه ورته اړتیا نلرم.
د میټاډاټا چیکسمونه څرګند شوي او ما پدې وروستیو کې دوی د "اقتصادي" عکسونو سره ضمیمه کړل (تر اوسه هم بې ثباته مواد). که چیرې د کوم بلاک چیکسم ناکام شي، Reiser4 سمدلاسه د ریپلیکا وسیلې څخه ورته بلاک لوستل کوي. په یاد ولرئ چې ZFS او Btrfs دا نشي کولی: ډیزاین دا اجازه نه ورکوي. هلته تاسو باید د "سکرب" په نوم د ځانګړي شالید سکین کولو پروسه پرمخ وړئ او د ستونزې لرونکي بلاک ته د رسیدو لپاره انتظار وکړئ. برنامه کونکي په مجازي ډول دا ډول پیښو ته "کرچچ" وايي.
او په نهایت کې ، متضاد منطقي حجمونه څرګند شوي ، هرڅه وړاندیز کوي چې ZFS ، Btrfs ، بلاک پرت ، او همدارنګه د FS + LVM ترکیبونه په اصولو کې نشي چمتو کولی - موازي اندازه کول ، O (1) ډیسک پته تخصیص کونکي ، د فرعي حجمونو ترمینځ شفاف ډیټا مهاجرت. وروستی هم د کارن انٹرفیس لري. اوس تاسو کولی شئ په اسانۍ سره ګرم ډیټا په خپل حجم کې ترټولو لوړ فعالیت ډرایو ته ولیږئ.
برسېره پردې، دا ممکنه ده چې په سمدستي توګه هر ډول ناپاک پاڼې داسې ډرایو ته فلش کړئ، په دې توګه د پام وړ غوښتنلیکونه چټکوي چې ډیری وختونه fsync(2) ته ویل کیږي. زه یادونه کوم چې د بلاک پرت فعالیت ، چې د bcache په نوم یادیږي ، په هیڅ ډول د عمل دومره آزادي نه ورکوي. نوي منطقي حجمونه زما د الګوریتم پراساس دي (دلته ورته پیټینټونه شتون لري). سافټویر لا دمخه خورا باثباته دی ، دا خورا امکان لري چې دا هڅه وکړئ ، فعالیت اندازه کړئ ، او داسې نور. یوازینۍ تکلیف دا دی چې د اوس لپاره تاسو اړتیا لرئ په لاسي ډول د حجم ترتیب تازه کړئ او چیرې یې ذخیره کړئ.
تر دې دمه زه توانیدلی یم چې خپل نظرونه په سلو کې 10 پلي کړم، په هرصورت، زه په هغه څه کې بریالی شوی یم چې ما ترټولو ستونزمن کار ګڼلی - د فلش پروسیجر سره د منطقي حجمونو سره نښلول چې په ریزر 4 کې ټول ځنډول شوي عملونه ترسره کوي. دا ټول لا تر اوسه په تجربوي "فارمیټ 41" څانګه کې دي.
ایا Reiser4 د xfstests پاس کوي؟
لږترلږه دا زما لپاره وکړل کله چې زه وروستی ریلیز چمتو کوم.
ایا دا په اصولو کې امکان لري چې د پلگ انونو په کارولو سره Reiser4 شبکه (کلستر) FS رامینځته کړئ؟
دا ممکنه ده، او حتی اړینه ده! که تاسو د سم ډیزاین شوي محلي فایل سیسټم پراساس د شبکې فایل رامینځته کړئ ، پایله به خورا اغیزمنه وي! په عصري شبکه FSs کې، زه د شاتنۍ ذخیره کولو کچې شتون څخه راضي نه یم، کوم چې د کوم ځایي FS په کارولو سره پلي کیږي. د دې کچې شتون په بشپړ ډول غیر عادلانه دی. شبکه FS باید په مستقیم ډول د بلاک پرت سره اړیکه ونیسي، او د محلي FS څخه نه وغواړي چې د نورو خدماتو فایلونه جوړ کړي!
په عموم کې، د فایل سیسټمونه په محلي او شبکه کې ویشل له بد څخه دی. دا د الګوریتمونو نیمګړتیا څخه رامینځته شوې چې دېرش کاله دمخه کارول شوي ، او د کوم ځای په ځای چې لاهم وړاندیز شوی نه دی. دا هم د غیر ضروري سافټویر اجزاو (مختلف خدمتونه، او نور) د ډله ایز ظهور لامل دی. په ښه توګه، دلته باید یوازې یو FS د کرنل ماډل په بڼه وي او په هر ماشین کې د کاروونکي یوټیلټیو سیټ نصب شي - یو کلستر نوډ. دا FS دواړه محلي او شبکه ده. او نور هیڅ نه!
که چیرې په لینکس کې د Reiser4 سره هیڅ کار ونه کړي، زه غواړم د FreeBSD لپاره FS وړاندیز وکړم (د تیرې مرکې څخه اقتباس: "...FreeBSD... اکاډمیک ریښې لري ... او دا پدې مانا ده چې موږ د لوړې کچې احتمال سره لرو. ایا د پراختیا کونکو سره به یوه ګډه ژبه ومومي")؟
نو، لکه څنګه چې موږ وموندل، هرڅه لا دمخه د لینکس سره په سمه توګه کار کوي: زموږ د ذخیره کولو د ماسټر څانګې په بڼه د دې لپاره جلا کاري Reiser4 بندر شتون لري. ما د FreeBSD په اړه هیر کړی نه دی! وړاندیز! زه چمتو یم چې د هغو کسانو سره نږدې کار وکړم څوک چې د FreeBSD دننه ښه پوهیږي. په لاره کې: هغه څه چې زه واقعیا د دوی د ټولنې په اړه خوښوم هغه دا دي چې دلته پریکړې د خپلواکو کارپوهانو د یوې تازه شوې شورا لخوا کیږي ، کوم چې د یو دایمي شخص له دولت سره هیڅ تړاو نلري.
تاسو نن ورځ د لینکس کارونکي ټولنه څنګه ارزوئ؟ ایا دا ډیر "پاپ" شوی؟
زما د کار ماهیت ته په پام سره، دا زما لپاره خورا ستونزمنه ده چې دا ارزونه وکړي. ډیری کارونکي ما ته د بګ راپورونو او د برخې د حل کولو غوښتنې سره راځي. د کاروونکو په توګه کاروونکي. ځینې یې ډیر هوښیار دي، ځینې لږ. له هر چا سره یو شان چلند کیږي. ښه، که چیرې کاروونکي زما لارښوونې له پامه غورځوي، نو ما بخښنه وکړه: د غفلت امر به زما په برخه کې هم داخل شي.
ایا دا ممکنه ده چې د راتلونکو پنځو څخه تر لسو کلونو پورې د فایل سیسټمونو پراختیا وړاندوینه وکړئ؟ تاسو څه فکر کوئ اصلي ننګونې دي چې د FS پراختیا کونکي ورسره مخ دي؟
هو، دا ستونزمنه نه ده چې دا ډول وړاندوینه وکړي. د اوږدې مودې لپاره په اپ سټریم کې د فایل سیسټمونو پرمختګ ندی شوی. یوازې دا ډول بڼه رامنځته کیږي. د محلي فایل سیسټمونو پراختیا کونکي د ضعیف ډیزاین پورې اړوند ستونزو سره مخ شوي. دلته باید یو احتیاط وشي. زه تش په نامه "ذخیره"، "چاټ" او د کوډ پورټ کول د پراختیا او پراختیا په توګه نه ګورم. او زه د "Btrfs" په نوم غلط فهم د هغه دلیلونو لپاره چې ما دمخه تشریح کړی د پرمختګ په توګه طبقه بندي نه کوم.
هر پیچ یوازې خپلې ستونزې لا پسې خرابوي. ښه. او تل مختلف ډوله "مبشران" شتون لري چې د دوی لپاره "هر څه کار کوي." اساسا ، دا د ښوونځي زده کونکي او زده کونکي دي چې لیکچر پریږدي. یوازې تصور وکړئ: دا د هغه لپاره کار کوي، مګر پروفیسور نه کوي. دا څومره د اډرینالین رش دی! زما له نظره ، ترټولو لوی زیان د "کارګرانو" لخوا رامینځته شوی څوک چې په لیوالتیا سره د Btrfs په زړه پورې ب featuresو ته په هر ډول پرتونو لکه سیسټمډ ، ډاکر او داسې نورو کې د "سکرو" لپاره ورغلي. - دا دمخه د میټاسټاسز سره ورته والی لري.
راځئ اوس هڅه وکړو چې د پنځو څخه تر لسو کلونو وړاندوینه وکړو. ما دمخه په لنډه توګه لیست کړی چې موږ به په Reiser4 کې څه وکړو. د لوړ پوړ څخه د ځایی FS پراختیا کونکو لپاره اصلي ننګونه به وي (هو ، دا دمخه رامینځته شوی) د معاش لپاره د ښه کار کولو وړتیا نه لري. د ډیټا ذخیره کولو په برخه کې د کوم نظر پرته، دوی به د دې بدبخته VFS، XFS او ext4 پیچ کولو هڅه وکړي. د VFS وضعیت په ځانګړي ډول د دې شالید پروړاندې مزاحیہ ښکاري ، د رستورانت د عصري کولو په اړه یادونه کوي چیرې چې هیڅ شیف شتون نلري ، او هیڅ شیف تمه نلري.
اوس د VFS کوډ، پرته له کوم شرط څخه، په ورته وخت کې د حافظې څو پاڼې بندوي او لاندې FS ته بلنه ورکوي چې کار وکړي. دا د حذف کولو عملیاتو په اړه د Ext4 فعالیت ښه کولو لپاره معرفي شوی و ، مګر لکه څنګه چې پوهیدل اسانه دي ، دا ډول سمسور تالا کول د پرمختللي لیږد ماډلونو سره په بشپړ ډول مطابقت نلري. دا دی، تاسو نشئ کولی په ساده ډول په کرنل کې د ځینې سمارټ فایل سیسټم لپاره ملاتړ اضافه کړئ. زه نه پوهیږم چې د لینکس په نورو برخو کې وضعیت څه دی ، مګر تر هغه ځایه چې د فایل سیسټمونو پورې اړه لري ، دلته هیڅ پرمختګ امکان نلري چې د توروالډز لخوا په عمل کې تعقیب شوي پالیسي سره مطابقت ولري (اکادمیکې پروژې لیرې شوي ، او سکیمران چې نه پوهیږو چې د بی ونې څه شی دی، د باور نه ختمیدونکی کریډیټ صادریږي). له همدې امله، د سست تخریب لپاره کورس ټاکل شوی و. البته، دوی به په ټول توان سره هڅه وکړي چې دا د "پرمختګ" په توګه تیر کړي.
سربیره پردې ، د فایل سیسټمونو "ساتونکي" ، پدې پوهیدل چې تاسو نشئ کولی یوازې د "ذخیرې" څخه ډیر عاید ترلاسه کړئ ، به د دوی لاس په ډیر ګټور سوداګرۍ کې هڅه وکړي. دا د یوې قاعدې په توګه، ویشل شوي فایل سیسټمونه او مجازی کول دي. شاید دوی به فیشن ZFS په بل ځای کې پورټ کړي چیرې چې دا لاهم شتون نلري. مګر دا د پورته جریان څخه د ټولو FS په څیر، د نوي کال ونې ته ورته دی: که تاسو کولی شئ یو څه نور کوچني شیان په سر کې ځړ کړئ، نو تاسو نشئ کولی ژوره ترلاسه کړئ. زه اعتراف کوم چې د ZFS پراساس د جدي تصدۍ سیسټم رامینځته کول ممکن دي ، مګر ځکه چې موږ اوس د راتلونکي په اړه بحث کوو ، زه یوازې په خواشینۍ سره ویلی شم چې ZFS پدې برخه کې نا امید دی: د دوی د مجازی وسیلو سره ، هلکانو اکسیجن پرې کړی. د خپل ځان او راتلونکي نسلونو د لا پرمختګ لپاره. ZFS د تیر شی دی. او ext4 او XFS حتی د پرون ورځ نه دي.
دا د "راتلونکي نسل لینکس فایل سیسټم" د حساس مفهوم په اړه په جلا توګه د یادونې وړ ده. دا په بشپړ ډول سیاسي او بازارموندنې پروژه ده چې د فرصت لپاره رامینځته شوې ، نو د خبرو کولو لپاره ، په لینکس کې د ځانګړو کرکټرونو شاته "د فایل سیسټمونو راتلونکي پن" کولو لپاره. حقیقت دا دی چې لینکس "یوازې د ساتیرۍ لپاره" و. مګر اوس دا په اصل کې د پیسو مینځلو ماشین دی. دوی په هر ممکنه توګه جوړ شوي دي. د مثال په توګه، د ښه سافټویر محصول رامینځته کول خورا ستونزمن کار دی، مګر سمارټ "پراختیا کونکي" د اوږدې مودې لپاره په دې پوهیدلي چې هیڅ ډول فشار ته اړتیا نشته: تاسو کولی شئ په بریالیتوب سره غیر موجود سافټویر وپلورئ کوم چې په هر ډول خلکو کې اعلان او وده کړې وه. پیښې - اصلي شی دا دی چې د پریزنټشن سلایډ باید ډیر "ځانګړتیاوې" ولري.
د فایل سیسټمونه د دې لپاره مناسب دي، ځکه چې تاسو کولی شئ په پایله کې د لسو کلونو لپاره په خوندي توګه معامله وکړئ. ښه، که څوک وروسته د دې پایلې د نشتوالي په اړه شکایت وکړي، نو هغه په ساده ډول د فایل سیسټمونو په اړه هیڅ نه پوهیږي! دا د مالي اهرام یادونه کوي: په پورتنۍ برخه کې هغه اتلان دي چې دا ګډوډي یې پیل کړې ، او هغه لږ شمیر چې "خوشحاله" وو: دوی "ګټې بیرته اخیستې" ، یعنی د پراختیا لپاره پیسې ترلاسه کړې، د مدیرانو په توګه د ښه معاش دنده ترلاسه کړه، په کنفرانسونو کې "ښکاره شو"، او داسې نور.
بیا هغه کسان راځي چې "بدبخته" دي: دوی به زیانونه حساب کړي، په تولید کې د ناکاره سافټویر محصول ځای پرځای کولو پایلو سره معامله وکړي، "او داسې نور. د دوی ډیری نور هم شتون لري. ښه ، د اهرام په اډه کې د پراختیا کونکو لوی ډله شتون لري چې بې کاره کوډ یې "څرمه" کوي. دوی تر ټولو لوی زیانمنونکي دي، ځکه چې ضایع شوي وخت بیرته نشي راتلی. دا ډول اهرامونه د توروالډز او د هغه د ملګرو لپاره خورا ګټور دي. او هرڅومره چې دا اهرامونه ډیر وي ، د دوی لپاره غوره وي. د دې ډول پیرامیدونو تغذیه کولو لپاره ، هرڅه په اصلي برخه کې اخیستل کیدی شي. البته، په عامه توګه دوی برعکس وايي. خو زه د الفاظو له مخې نه بلکې د عمل په واسطه قضاوت کوم.
نو، "په لینکس کې د فایل سیسټمونو راتلونکی" یو بل خورا لوړ شوی، مګر په سختۍ سره د کارولو وړ سافټویر دی. د Btrfs وروسته ، د لوړ احتمال سره ، د داسې "راتلونکي" ځای به د Bcachefs لخوا ونیول شي ، کوم چې د فایل سیسټم سره د لینکس بلاک پرت ته د تیریدو بله هڅه ده (یو بد مثال ساري ده). او هغه څه چې عادي دي: د Btrfs په څیر ورته ستونزې شتون لري. ما دا د اوږدې مودې لپاره شک درلود، او بیا یو څه زه مقاومت نشم کولی او کوډ ته یې ګورم - دا ریښتیا ده!
د Bcachefs او Btrfs لیکوالان، کله چې خپل FS رامینځته کوي، په فعاله توګه د نورو خلکو سرچینې کاروي، د دوی په اړه لږ څه پوهیدل. وضعیت د ماشومانو د لوبې "خراب شوي تلیفون" خورا یادونه کوي. او زه تقریبا تصور کولی شم چې دا کوډ به څنګه په کرنل کې شامل شي. په حقیقت کې، هیڅوک به "ریکیک" ونه ګوري (هرڅوک به وروسته په دوی ګام پورته کړي). د کوډ سټایل په اړه د ډیری خنډونو وروسته ، د نه شتون سرغړونو تورونه ، او داسې نور ، د لیکوال د "وفادارۍ" په اړه به یوه پایله رامینځته شي ، چې هغه د نورو پراختیا کونکو سره څومره ښه تعامل کوي ، او دا ټول څومره په بریالیتوب سره کولی شي. بیا به شرکتونو ته وپلورل شي.
وروستۍ پایله به د هیچا سره علاقه ونلري. شل کاله مخکې، شاید، زه به لیوالتیا وم، مګر اوس پوښتنې په بل ډول راپورته کیږي: ایا دا ممکنه ده چې دې ته وده ورکړي ترڅو په راتلونکو لسو کلونو کې ځینې خلک په کار وګمارل شي. او، افسوس، دا رواج نه دی چې د پای پایلې په اړه حیران شي.
په عموم کې ، زه به په کلکه مشوره وکړم چې ستاسو د فایل سیسټم له سکریچ څخه بیا رغول پیل کړئ. ځکه چې حتی د پام وړ مالي پانګه اچونه به په لسو کلونو کې د سیالۍ کولو لپاره کافي نه وي. البته، زه د جدي پروژو په اړه خبرې کوم، او نه د هغو په اړه چې موخه یې د کرنل ته "زورول" وي. نو، د خپل ځان څرګندولو لپاره یوه اغیزمنه لاره دا ده چې زموږ په څیر ریښتیني پرمختګونو کې ګډون وکړئ. البته، دا کار کول اسانه ندي - مګر دا د هرې لوړې کچې پروژې قضیه ده.
لومړی، تاسو اړتیا لرئ په خپلواکه توګه هغه ستونزه حل کړئ چې زه یې وړاندیز کوم. له هغې وروسته، ستاسو د ارادې په جديت قانع، زه به مرسته پیل کړم. په دودیز ډول، موږ یوازې خپل پرمختګونه کاروو. استثناوې د کمپریشن الګوریتم او ځینې هش افعال دي. موږ پراختیا کونکي نه لیږو چې کنفرانسونو ته سفر وکړي ، او بیا موږ ناست نه یو او د نورو خلکو نظرونه سره یوځای کوو ("شاید څه به پیښ شي") ، لکه څنګه چې په ډیری پیلونو کې دود دی.
موږ ټول الګوریتمونه پخپله وده کوو. زه اوس مهال د معلوماتو ذخیره کولو ساینس الجبریک او ګډ اړخونو سره علاقه لرم. په ځانګړې توګه، محدودې ساحې، غیر متناسب، د نابرابرۍ ثبوت. د عادي پروګرام کونکو لپاره هم کار شتون لري، مګر زه باید تاسو ته سمدستي خبرداری ورکړم: ټول وړاندیزونه چې "بل FS ته وګورئ او ورته کار وکړئ" له پامه غورځول شوي. پیچونه چې هدف یې د VFS له لارې لینکس سره نږدې ادغام کول دي هم به هلته لاړ شي.
نو، موږ ریک نلرو، مګر موږ پوهیږو چې چیرته حرکت ته اړتیا لرو، او موږ باور لرو چې دا سمه لار ده. دا پوهه د جنت څخه د مینې په بڼه نه وه راغلې. اجازه راکړئ تاسو ته یادونه وکړم چې موږ تر شا د 29 کلونو پراختیا تجربه لرو، دوه فایل سیسټمونه له سکریچ څخه لیکل شوي. او د معلوماتو د بیرته راګرځولو اسانتیاوو ورته شمیر. او دا ډیر دی!
سرچینه: opennet.ru