ڪلائوڊ سسٽم ۾ ڊيٽا اسٽوريج جي استحڪام تي تحقيق ڪرڻ دوران، مون پاڻ کي جانچڻ جو فيصلو ڪيو ته پڪ ڪرڻ لاءِ ته مان بنيادي شين کي سمجهي چڪو آهيان. اي سمجھڻ لاءِ ته پائيدار ڊيٽا اسٽوريج جي حوالي سان ڪهڙي ضمانت ڏئي ٿي (يعني اها ضمانت آهي ته ڊيٽا سسٽم جي ناڪامي کان پوءِ دستياب هوندي) اسان کي ڏيو NMVe ڊسڪ. مون ھيٺين مکيه نتيجن کي ڪيو: ڊيٽا کي خراب ٿيڻ واري وقت کان سمجھيو وڃي ڊيٽا کي لکڻ جو حڪم ڏنو ويو آھي ان وقت تائين جيستائين اھو اسٽوريج وچولي ڏانھن لکيو وڃي. بهرحال، اڪثر پروگرامن کي ڊيٽا کي رڪارڊ ڪرڻ لاء سسٽم ڪالون ڪافي خوشيء سان استعمال ڪندا آهن.
هن پوسٽ ۾، مان ڳوليان ٿو مسلسل اسٽوريج ميڪانيزم جيڪي مهيا ڪيل آهن لينڪس فائل APIs. اهو لڳي ٿو ته هتي هر شيء سادو هجڻ گهرجي: پروگرام حڪم کي سڏي ٿو write()، ۽ هن حڪم جي مڪمل ٿيڻ کان پوء، ڊيٽا محفوظ طور تي ڊسڪ ۾ محفوظ ڪيو ويندو. پر write() صرف ايپليڪيشن ڊيٽا کي نقل ڪري ٿو RAM ۾ واقع ڪرنل ڪيش ۾. سسٽم کي مجبور ڪرڻ لاء ڊيٽا کي ڊسڪ ۾ لکڻ لاء، توهان کي ڪجهه اضافي ميڪانيزم استعمال ڪرڻ جي ضرورت آهي.
مجموعي طور تي، هي مواد نوٽس جو مجموعو آهي، جيڪو مون پنهنجي دلچسپيءَ واري موضوع تي سکيو آهي. جيڪڏهن اسان سڀ کان اهم شيءِ بابت تمام مختصر ڳالهايون ٿا، اهو ظاهر ٿئي ٿو ته پائيدار ڊيٽا اسٽوريج کي منظم ڪرڻ لاءِ توهان کي ڪمانڊ استعمال ڪرڻ جي ضرورت آهي. fdatasync() يا پرچم سان فائلون کوليو O_DSYNC. جيڪڏهن توهان انهي بابت وڌيڪ سکڻ ۾ دلچسپي رکو ٿا ته ڪوڊ کان ڊسڪ تائين ڊيٽا کي ڇا ٿيندو، هڪ نظر وٺو مضمون.
لکڻ () فنڪشن استعمال ڪرڻ جون خاصيتون
سسٽم ڪال write() معيار ۾ بيان ڪيو ويو آهي فائل ڊسڪرپٽر ڏانهن ڊيٽا لکڻ جي ڪوشش جي طور تي. ڪامياب ٿيڻ کان پوء write() ڊيٽا پڙهڻ واري عملن کي لازمي طور تي بائيٽ واپس ڪرڻ گهرجي جيڪي اڳ ۾ لکيل هئا، اهو ڪندي ڪندي جيتوڻيڪ ڊيٽا کي ٻين پروسيس يا ٿريڊس مان رسائي حاصل ڪئي وئي آهي ( POSIX معيار جو لاڳاپيل سيڪشن). , سيڪشن ۾ ڪئين موضوعن سان عام فائل جي عملن سان لهه وچڙ ۾، اتي هڪ نوٽ آهي جنهن ۾ چيو ويو آهي ته جيڪڏهن ٻه سٽون هر هڪ کي انهن ڪمن کي سڏين ٿا، پوء هر ڪال کي ڏسڻ گهرجي يا ته ٻئي ڪال جا سڀئي نامزد نتيجا، يا ڪجهه به نه. نتيجا. اهو نتيجو اهو ڪري ٿو ته سڀئي فائل I/O عملن کي لازمي طور تي هڪ تالا رکڻ گهرجي وسيلن تي اهي ڪم ڪري رهيا آهن.
ڇا ان جو مطلب اهو آهي ته آپريشن write() ڇا اهو ايٽمي آهي؟ ٽيڪنيڪل نقطي نظر کان، ها. ڊيٽا پڙهڻ جي عملن کي يا ته سڀ يا ڪجھ به نه موٽڻ گهرجي جنهن سان لکيو ويو هو write(). پر آپريشن write()معيار جي مطابق، ضروري ناهي ته هر شي کي ختم ڪندي ختم ڪيو وڃي جيڪو لکڻ لاء چيو ويو هو. هوء صرف ڊيٽا جو حصو لکڻ جي اجازت آهي. مثال طور، اسان وٽ شايد ٻه سلسلا هجن هر هڪ 1024 بائيٽ هڪ فائل ۾ XNUMX بائٽس ساڳئي فائل بيان ڪندڙ طرفان بيان ڪيل. معيار جي نقطي نظر کان، هڪ قابل قبول نتيجو ٿيندو جڏهن هر لکڻ جي عمل کي فائل ۾ صرف هڪ بائيٽ شامل ڪري سگهجي ٿو. اهي عمل ايٽمي رهندا، پر انهن جي مڪمل ٿيڻ کان پوء، انهن فائلن ۾ لکيل ڊيٽا کي گڏ ڪيو ويندو. اسٽيڪ اوور فلو تي هن موضوع تي تمام دلچسپ بحث.
fsync() ۽ fdatasync() افعال
ڊسڪ تي ڊيٽا کي فلش ڪرڻ جو آسان طريقو فنڪشن کي ڪال ڪرڻ آهي . هي فنڪشن آپريٽنگ سسٽم کان پڇي ٿو سڀني تبديل ٿيل بلاڪ کي ڪيش کان ڊسڪ ڏانهن منتقل ڪرڻ لاء. ھن ۾ سڀ فائل ميٽاداٽا شامل آھن (پھچائڻ جو وقت، فائل تبديل ڪرڻ جو وقت، وغيره). مان سمجهان ٿو ته هي ميٽا ڊيٽا تمام گهٽ گهربل آهي، تنهنڪري جيڪڏهن توهان کي خبر آهي ته اهو توهان لاء اهم ناهي، توهان فنڪشن استعمال ڪري سگهو ٿا fdatasync(). جي تي fdatasync() اهو چيو ويندو آهي ته هن فنڪشن جي آپريشن دوران، ميٽا ڊيٽا جي اهڙي مقدار کي ڊسڪ ۾ محفوظ ڪيو ويو آهي "هيٺ ڏنل ڊيٽا پڙهڻ جي عملن جي صحيح عمل لاء ضروري آهي." ۽ اھو اھو آھي جيڪو سڀ کان وڌيڪ ايپليڪيشنن جو خيال رکندو آھي.
هڪ مسئلو جيڪو هتي پيدا ٿي سگهي ٿو اهو آهي ته اهي ميکانيزم ضمانت نه ڏيندا آهن ته فائل کي ممڪن ناڪام ٿيڻ کان پوء دريافت ڪيو ويندو. خاص طور تي، جڏهن هڪ نئين فائل ٺاهي، توهان کي ڪال ڪرڻ جي ضرورت آهي fsync() ڊاريڪٽري لاءِ جنهن ۾ اهو شامل آهي. ٻي صورت ۾، ناڪام ٿيڻ کان پوء، اهو ٿي سگهي ٿو ته هي فائل موجود ناهي. ان جو سبب اهو آهي ته UNIX ۾، سخت لنڪ جي استعمال جي ڪري، هڪ فائل ڪيترن ئي ڊائريڪٽرن ۾ موجود ٿي سگهي ٿي. تنهن ڪري، جڏهن سڏ fsync() فائل لاءِ اهو ڄاڻڻ جو ڪو طريقو ناهي ته ڪهڙي ڊاريڪٽري ڊيٽا کي ڊسڪ ۾ فلش ڪيو وڃي ( توهان هن بابت وڌيڪ پڙهي سگهو ٿا). اهو لڳي ٿو ته ext4 فائيل سسٽم جي قابل آهي استعمال ڪريو fsync() ڊاريڪٽري ۾ لاڳاپيل فائلن تي مشتمل آهي، پر اهو ٿي سگهي ٿو اهو معاملو ٻين فائل سسٽم سان نه هجي.
هي ميکانيزم مختلف فائل سسٽم تي مختلف طريقي سان لاڳو ٿي سگهي ٿو. مون استعمال ڪيو ext4 ۽ XFS فائل سسٽم ۾ ڪهڙيون ڊسڪ آپريشنز استعمال ٿينديون آهن، ان بابت سکڻ لاءِ. ٻئي جاري ڪن ٿا ڊسڪ تي باقاعدي لکڻ جا ڪمانڊ ٻنهي فائلن جي مواد ۽ فائل سسٽم جرنل لاءِ، ڪيش کي فلش ڪريو، ۽ FUA (فورس يونٽ جي رسائي، ڊيٽا کي سڌو ڊسڪ تي لکڻ، ڪيش کي نظرانداز ڪندي) جرنل ڏانهن لکو. اهي شايد اهو ڪن ٿا انهي جي تصديق ڪرڻ لاءِ ته ٽرانزيڪشن ٿي چڪي آهي. ڊرائيوز تي جيڪي FUA کي سپورٽ نٿا ڪن، هي ٻه ڪيش فلش جو سبب بڻجن ٿا. منهنجا تجربا ڏيکاريا ويا fdatasync() ٿورو تيز fsync(). افاديت blktrace انهي طرف اشارو ڪري ٿو fdatasync() عام طور تي ڊسڪ تي گهٽ ڊيٽا لکي ٿو (ext4 ۾ fsync() لکي ٿو 20 KiB، ۽ fdatasync() - 16 KiB). پڻ، مون کي معلوم ٿيو ته XFS ext4 کان ٿورو تيز آهي. ۽ هتي جي مدد سان blktrace اهو معلوم ڪرڻ ۾ ڪامياب ٿيو fdatasync() گھٽ ڊيٽا کي ڊسڪ تي فلش ڪري ٿو (XFS ۾ 4 KiB).
غير واضح حالتون جيڪي پيدا ٿين ٿيون جڏهن استعمال ڪندي fsync()
مان ٽن مبهم حالتن بابت سوچي سگهان ٿو fsync()جيڪو مون کي عملي طور تي مليو.
اهڙو پهريون ڪيس 2008ع ۾ سامهون آيو. پوءِ فائر فاڪس 3 انٽرفيس منجمد ٿي ويو جيڪڏهن فائلن جو وڏو تعداد ڊسڪ تي لکيو ويو. مسئلو اهو هو ته انٽرفيس جي نفاذ هڪ SQLite ڊيٽابيس استعمال ڪيو ان جي رياست بابت معلومات ذخيرو ڪرڻ لاءِ. انٽرفيس ۾ هر تبديليءَ کان پوءِ، فنڪشن سڏبو هو fsync()، جيڪو مستحڪم ڊيٽا اسٽوريج جي سٺي ضمانت ڏني. ext3 فائل سسٽم ۾ پوء استعمال ڪيو ويو، فنڪشن fsync() سسٽم ۾ سڀني "گندا" صفحن کي ڊسڪ ۾ ڊمپ ڪيو، ۽ نه صرف اهي جيڪي لاڳاپيل فائل سان لاڳاپيل هئا. ان جو مطلب اهو ٿيو ته فائر فاڪس ۾ هڪ بٽڻ کي دٻائڻ سان ميگا بائيٽ ڊيٽا کي ٽاري سگھي ٿو مقناطيسي ڊسڪ تي لکڻ لاءِ، جنهن ۾ ڪيترائي سيڪنڊ لڳن ٿا. مسئلي جو حل، جيتري قدر مان سمجهان ٿو مواد ڊيٽابيس سان ڪم کي غير مطابقت واري پس منظر جي ڪمن ڏانهن منتقل ڪرڻ هو. هن جو مطلب اهو آهي ته فائر فاڪس اڳ ۾ وڌيڪ سخت اسٽوريج گهرجن کي لاڳو ڪيو ويو آهي حقيقت جي ضرورت کان، ۽ ext3 فائل سسٽم جي خاصيتن صرف هن مسئلي کي وڌايو.
ٻيو مسئلو 2009 ع ۾ ٿيو. ان کان پوء، سسٽم جي حادثي کان پوء، نئين ext4 فائل سسٽم جي استعمال ڪندڙن کي حقيقت سان منهن ڏيڻو پيو ته ڪيترن ئي نئين ٺاهيل فائلن جي ڊيگهه صفر هئي، پر پراڻي ext3 فائل سسٽم سان ائين نه ٿيو. پوئين پيراگراف ۾، مون بابت ڳالهايو ته ڪيئن ext3 تمام گهڻو ڊيٽا کي ڊسڪ ڏانهن وڌايو، جنهن شين کي تمام گهڻو سست ڪيو. fsync(). صورتحال کي بهتر ڪرڻ لاء، ext4 ۾ صرف اهي گندا صفحا جيڪي هڪ خاص فائل سان لاڳاپيل هوندا آهن ڊسڪ ڏانهن ڦهليل آهن. ۽ ٻين فائلن جي ڊيٽا ext3 جي ڀيٽ ۾ تمام گهڻي وقت تائين ميموري ۾ رهي ٿي. اهو ڪارڪردگي بهتر ڪرڻ لاءِ ڪيو ويو (ڊفالٽ طور، ڊيٽا هن حالت ۾ 30 سيڪنڊن تائين رهي ٿي، توهان هن کي استعمال ڪندي ترتيب ڏئي سگهو ٿا ; توھان ان بابت اضافي مواد ڳولي سگھو ٿا). هن جو مطلب آهي ته ڊيٽا جي هڪ وڏي رقم هڪ ناڪامي کان پوء irretrievably گم ٿي سگهي ٿو. هن مسئلي جو حل استعمال ڪرڻ آهي fsync() ايپليڪيشنن ۾ جيڪي مستحڪم ڊيٽا اسٽوريج کي يقيني بڻائڻ جي ضرورت آهي ۽ انهن کي ممڪن حد تائين ناڪامي جي نتيجن کان بچائڻ جي ضرورت آهي. فنڪشن fsync() ext4 استعمال ڪرڻ جي ڀيٽ ۾ ext3 استعمال ڪرڻ وقت تمام گهڻو موثر ڪم ڪري ٿو. هن طريقي جو نقصان اهو آهي ته ان جو استعمال، اڳ وانگر، ڪجهه عملن جي عمل کي سست ڪري ٿو، جهڙوڪ پروگرامن کي نصب ڪرڻ. ان بابت تفصيل ڏسو и .
ٽيون مسئلو بابت fsync()، 2018 ۾ پيدا ٿيو. پوء، PostgreSQL منصوبي جي فريم ورڪ جي اندر، اهو مليو ته جيڪڏهن فنڪشن fsync() هڪ غلطي کي منهن ڏئي ٿو، اهو نشان لڳندو آهي "گندا" صفحا "صاف" طور. نتيجي طور، هيٺيان ڪالون fsync() اهي اهڙن صفحن سان ڪجهه به نٿا ڪن. انهي جي ڪري، تبديل ٿيل صفحا ياداشت ۾ محفوظ ڪيا ويا آهن ۽ ڪڏهن به ڊسڪ تي نه لکندا آهن. هي هڪ حقيقي آفت آهي، ڇاڪاڻ ته ايپليڪيشن سوچيو ته ڪجهه ڊيٽا ڊسڪ تي لکيل آهي، پر حقيقت ۾ اهو نه ٿيندو. اهڙيون ناڪاميون fsync() نادر آهن، اهڙين حالتن ۾ ايپليڪيشن مسئلي کي منهن ڏيڻ لاء تقريبا ڪجھ به نه ڪري سگهي ٿي. اهي ڏينهن، جڏهن اهو ٿئي ٿو، PostgreSQL ۽ ٻيون ايپليڪيشنون حادثو. مواد ۾ "ڇا ايپليڪيشنون ٻيهر حاصل ڪري سگھن ٿيون fsync ناڪامين کان؟"، هن مسئلي کي تفصيل سان ڳولهيو ويو آهي. في الحال هن مسئلي جو بهترين حل آهي استعمال ڪرڻ لاءِ سڌو I/O پرچم سان O_SYNC يا هڪ پرچم سان O_DSYNC. هن طريقي سان، سسٽم غلطين جي رپورٽ ڪندو جيڪي مخصوص لکڻ جي عملن دوران ٿي سگھن ٿيون، پر هن طريقي جي ضرورت آهي ايپليڪيشن کي بفرز کي منظم ڪرڻ لاء. هن بابت وڌيڪ پڙهو и .
O_SYNC ۽ O_DSYNC پرچم استعمال ڪندي فائلون کولڻ
اچو ته لينڪس ميڪانيزم جي بحث ڏانهن موٽون جيڪي مستحڪم ڊيٽا اسٽوريج مهيا ڪن ٿيون. يعني، اسان پرچم استعمال ڪرڻ بابت ڳالهائي رهيا آهيون O_SYNC يا پرچم O_DSYNC جڏهن سسٽم ڪال استعمال ڪندي فائلن کي کوليو . هن طريقي سان، هر ڊيٽا لکڻ جي آپريشن کي انجام ڏنو ويندو آهي ڄڻ ته هر حڪم کان پوء write() سسٽم مطابق حڪم ڏنو ويو آهي fsync() и fdatasync(). جي ان کي سڏيو ويندو آهي " هم وقت سازي I / O فائل جي سالميت جي مڪمل ٿيڻ "۽ "ڊيٽا سالميت مڪمل". هن طريقي جو بنيادي فائدو اهو آهي ته ڊيٽا جي سالميت کي يقيني بڻائڻ لاءِ، توهان کي صرف هڪ سسٽم ڪال ڪرڻ جي ضرورت آهي، بلڪه ٻه (مثال طور - write() и fdatasync()). هن طريقي جو بنيادي نقصان اهو آهي ته لاڳاپيل فائل بيان ڪندڙ استعمال ڪندي سڀ لکت کي هم وقت سازي ڪئي ويندي، جيڪا ايپليڪيشن ڪوڊ کي ترتيب ڏيڻ جي صلاحيت کي محدود ڪري سگهي ٿي.
O_DIRECT پرچم سان سڌو I/O استعمال ڪندي
سسٽم ڪال open() پرچم کي سپورٽ ڪري ٿو O_DIRECT، جنهن کي ڊزائين ڪيو ويو آهي آپريٽنگ سسٽم ڪيش کي بائي پاس ڪرڻ لاءِ I/O آپريشن ڪرڻ لاءِ سڌو سنئون ڊسڪ سان رابطو ڪندي. اهو، ڪيترن ئي ڪيسن ۾، مطلب اهو آهي ته پروگرام پاران جاري ڪيل حڪم لکندا آهن سڌو سنئون ڪمن ۾ ترجمو ڪيو ويندو جنهن جو مقصد ڊسڪ سان ڪم ڪرڻ آهي. پر، عام طور تي، هي ميکانيزم افعال لاء متبادل ناهي fsync() يا fdatasync(). حقيقت اها آهي ته ڊسڪ پاڻ ڪري سگهي ٿو لاڳاپيل ڊيٽا لکڻ جو حڪم. ۽، معاملن کي وڌيڪ خراب ڪرڻ لاء، ڪجهه خاص ڪيسن ۾ I/O آپريشن ڪيا ويا جڏهن پرچم استعمال ڪندي O_DIRECT, روايتي بفر ٿيل آپريشن ۾. هن مسئلي کي حل ڪرڻ جو آسان طريقو فائلن کي کولڻ لاء پرچم استعمال ڪرڻ آهي O_DSYNC، جنهن جو مطلب اهو ٿيندو ته هر لکڻ جي عمل کي ڪال جي پٺيان لڳايو ويندو fdatasync().
اهو ظاهر ٿيو ته XFS فائل سسٽم تازو شامل ڪيو هو "تيز رستو" لاء O_DIRECT|O_DSYNC- ڊيٽا رڪارڊنگ. جيڪڏهن هڪ بلاڪ استعمال ڪندي ٻيهر لکيو ويو آهي O_DIRECT|O_DSYNC، پوءِ XFS، ڪيش کي فلش ڪرڻ جي بدران، FUA لکڻ واري حڪم تي عمل ڪندو جيڪڏهن ڊوائيس ان کي سپورٽ ڪري. مون ان جي تصديق ڪئي يوٽيليٽي استعمال ڪندي blktrace لينڪس 5.4 / Ubuntu 20.04 سسٽم تي. اهو طريقو وڌيڪ ڪارائتو هجڻ گهرجي، ڇاڪاڻ ته جڏهن استعمال ڪيو ويو آهي، ڊسڪ تي ڊيٽا جي گهٽ ۾ گهٽ مقدار لکيو ويندو آهي ۽ هڪ آپريشن استعمال ڪيو ويندو آهي، ٻن بدران (ڪيش لکڻ ۽ فلش ڪرڻ). مون کي هڪ لنڪ مليو 2018 ڪنيل، جيڪو هن ميڪانيزم کي لاڳو ڪري ٿو. اتي ڪجھ بحث آھي ھن اصلاح کي ٻين فائل سسٽم تي لاڳو ڪرڻ بابت، پر جيتري قدر مون کي خبر آھي، XFS واحد فائل سسٽم آھي جيڪو ھن وقت تائين سپورٽ ڪري ٿو.
sync_file_range() فنڪشن
لينڪس وٽ هڪ سسٽم ڪال آهي ، جيڪو توهان کي اجازت ڏئي ٿو ته فائل جي صرف هڪ حصي کي ڊسڪ ڏانهن، بلڪه پوري فائل جي. هي ڪال هڪ غير مطابقت واري ڊيٽا فلش شروع ڪري ٿو ۽ ان جي مڪمل ٿيڻ جو انتظار نٿو ڪري. پر سند ۾ sync_file_range() ٽيم چيو وڃي ٿو "تمام خطرناڪ". ان کي استعمال ڪرڻ جي سفارش نه آهي. خاصيتون ۽ خطرا sync_file_range() تمام سٺو بيان ڪيو ويو آهي مواد. خاص طور تي، هي ڪال ظاهر ٿئي ٿو RocksDB استعمال ڪرڻ لاءِ ڪنٽرول ڪرڻ لاءِ جڏهن ڪنيل گندي ڊيٽا کي ڊسڪ تي فليش ڪري ٿو. پر ساڳئي وقت، مستحڪم ڊيٽا اسٽوريج کي يقيني بڻائڻ لاء، اهو پڻ استعمال ڪيو ويندو آهي fdatasync(). جي RocksDB هن موضوع تي ڪجهه دلچسپ رايا آهن. مثال طور، اهو ظاهر ٿئي ٿو ته ڪال sync_file_range() جڏهن ZFS استعمال ڪندي، اهو ڊسڪ ڏانهن ڊيٽا کي فلش نٿو ڪري. تجربو مون کي ٻڌائي ٿو ته ڪوڊ جيڪو گهٽ ۾ گهٽ استعمال ڪيو ويندو آهي ممڪن آهي ته ڪيڙا هجن. تنهن ڪري، مان هن سسٽم کي استعمال ڪرڻ جي خلاف مشورو ڏيندس جيستائين بلڪل ضروري نه هجي.
سسٽم ڪالون جيڪي ڊيٽا جي تسلسل کي يقيني بڻائڻ ۾ مدد ڪن ٿيون
مان ان نتيجي تي پهتو آهيان ته ٽي طريقا آهن جيڪي I/O عملن کي انجام ڏيڻ لاءِ استعمال ڪري سگھجن ٿيون جيڪي ڊيٽا جي تسلسل کي يقيني بڻائين ٿيون. انهن سڀني کي هڪ فنڪشن ڪال جي ضرورت آهي fsync() ڊاريڪٽري لاءِ جنهن ۾ فائل ٺاهي وئي هئي. اهي طريقا آهن:
- هڪ فنڪشن سڏڻ
fdatasync()ياfsync()فنڪشن کان پوءwrite()(اهو استعمال ڪرڻ بهتر آهيfdatasync()). - ھڪڙي فائل بيان ڪندڙ سان ڪم ڪندي ھڪڙي پرچم سان کوليو
O_DSYNCياO_SYNC(بهتر - هڪ پرچم سانO_DSYNC). - حڪم استعمال ڪندي
pwritev2()پرچم سانRWF_DSYNCياRWF_SYNC(ترجيح طور تي هڪ پرچم سانRWF_DSYNC).
ڪارڪردگي نوٽس
مون مختلف ميکانيزم جي ڪارڪردگي کي احتياط سان نه ماپيو آهي جن جو مون جائزو ورتو آهي. انهن جي ڪم جي رفتار ۾ مون جيڪي فرق محسوس ڪيا آهن اهي تمام ننڍا آهن. هن جو مطلب اهو آهي ته مان غلط ٿي سگهي ٿو، ۽ مختلف حالتن ۾ ساڳيو شيء مختلف نتيجا پيدا ڪري سگهي ٿي. پهرين، مان ان بابت ڳالهائيندس جيڪو ڪارڪردگي کي وڌيڪ متاثر ڪري ٿو، ۽ پوء ڇا ڪارڪردگي کي گهٽ متاثر ڪري ٿو.
- فائل ڊيٽا کي اوور رائٽنگ ڪرڻ تيز آهي فائل ۾ ڊيٽا شامل ڪرڻ کان (ڪارڪردگي جو فائدو 2-100٪ ٿي سگهي ٿو). فائل ۾ ڊيٽا شامل ڪرڻ فائل جي ميٽا ڊيٽا ۾ اضافي تبديلين جي ضرورت آهي، جيتوڻيڪ سسٽم ڪال کان پوء
fallocate()، پر هن اثر جي شدت مختلف ٿي سگهي ٿي. مان سفارش ڪريان ٿو، بهترين ڪارڪردگي لاء، ڪال ڪرڻ لاءfallocate()گھربل جاء اڳ ۾ مختص ڪرڻ لاء. پوء هن خلا کي واضح طور تي زيرو سان ڀريو وڃي ۽ سڏيو وڃيfsync(). اهو يقيني بڻائيندو ته فائل سسٽم ۾ لاڳاپيل بلاڪ "غير مختص ٿيل" جي بدران "مختص ڪيل" طور نشان لڳل آهن. اهو هڪ ننڍڙو (اٽڪل 2٪) ڪارڪردگي بهتري ڏئي ٿو. اضافي طور تي، ڪجهه ڊسڪ ٻين جي ڀيٽ ۾ بلاڪ تائين سست پهرين رسائي حاصل ڪري سگھن ٿيون. هن جو مطلب آهي ته صفر سان خلا کي ڀرڻ سان ڪارڪردگي ۾ هڪ اهم (اٽڪل 100٪) بهتري ٿي سگهي ٿي. خاص طور تي، اهو ٿي سگهي ٿو ڊسڪ سان (هي غير سرڪاري ڊيٽا آهي، مان ان جي تصديق نه ڪري سگهيو آهيان). ساڳيو ئي اسٽوريج لاء آهي (۽ اها اڳ ۾ ئي سرڪاري معلومات آهي، ٽيسٽن جي تصديق ٿيل آهي). ٻين ماهرن به ائين ئي ڪيو آهي ، مختلف ڊسڪ سان لاڳاپيل. - گهٽ سسٽم ڪال، اعلي ڪارڪردگي (فائدو تقريبا 5٪ ٿي سگهي ٿو). هڪ چيلنج وانگر لڳي ٿو
open()پرچم سانO_DSYNCيا سڏpwritev2()پرچم سانRWF_SYNCڪال کان وڌيڪ تيزfdatasync(). مون کي شڪ آهي ته هتي نقطو اهو آهي ته اهو نقطو حقيقت ۾ ڪردار ادا ڪري ٿو ته ساڳئي مسئلي کي حل ڪرڻ لاء گهٽ سسٽم ڪالون انجام ڏيڻ گهرجن (ٻن جي بدران هڪ ڪال). پر ڪارڪردگي ۾ فرق تمام ننڍڙو آهي، تنهنڪري توهان ان کي مڪمل طور تي نظر انداز ڪري سگهو ٿا ۽ ايپليڪيشن ۾ ڪجهه استعمال ڪري سگهو ٿا جيڪو ان جي منطق کي پيچيده نه ڪندو.
جيڪڏهن توهان پائيدار ڊيٽا اسٽوريج جي موضوع ۾ دلچسپي رکو ٿا، هتي ڪجهه مفيد مواد آهن:
- - ان پٽ/آئوٽ پٽ ميڪانيزم جي بنيادي ڳالهين جو جائزو.
- - ايپليڪيشن کان ڊسڪ تائين رستي تي ڊيٽا کي ڇا ٿئي ٿو بابت هڪ ڪهاڻي.
- - جڏهن استعمال ڪرڻ جي سوال جو جواب
fsync()ڊائريڪٽرن لاء. هن کي مختصر ۾ رکڻ لاء، اهو ظاهر ٿئي ٿو ته توهان کي اهو ڪرڻ جي ضرورت آهي جڏهن هڪ نئين فائل ٺاهي، ۽ هن سفارش جو سبب اهو آهي ته لينڪس ۾ ساڳئي فائل جا ڪيترائي حوالا ٿي سگهن ٿا. - - هتي هڪ وضاحت آهي ته ڪيئن مسلسل ڊيٽا اسٽوريج کي لاڳو ڪيو ويو آهي SQL سرور ۾ لينڪس پليٽ فارم تي. هتي ونڊوز ۽ لينڪس سسٽم ڪالن جي وچ ۾ ڪجهه دلچسپ مقابلو آهن. مون کي لڳ ڀڳ پڪ آهي ته اها هن مواد جي مهرباني هئي جيڪا مون XFS جي FUA اصلاح بابت سکيا.
ڇا توهان ڊيٽا وڃائي ڇڏيو آهي جيڪو توهان سوچيو ته محفوظ طور تي ڊسڪ تي محفوظ ڪيو ويو آهي؟
جو ذريعو: www.habr.com