ما، په بادل سیسټمونو کې د ډیټا ذخیره کولو ثبات څیړنه وکړه، پریکړه یې وکړه چې خپل ځان ازموینه وکړم، ترڅو ډاډ ترلاسه کړم چې زه په اساسي شیانو پوهیږم. زه د دې لپاره چې پوه شئ چې د ډیټا دوام په اړه کوم تضمین (دا تضمین کوي چې ډاټا به د سیسټم له ناکامۍ وروسته شتون ولري) موږ ته NMVe ډیسک راکړئ. ما لاندې اصلي پایلې ترلاسه کړې: تاسو اړتیا لرئ د هغه شیبې څخه زیانمن شوي ډیټا په پام کې ونیسئ چې د ډیټا لیکلو کمانډ ورکړل شوی وي ، او تر هغه وخته پورې چې دوی د ذخیره کولو مینځ ته لیکل شوي وي. په هرصورت، په ډیری برنامو کې، د سیسټم زنګونه په خوندي ډول د معلوماتو لیکلو لپاره کارول کیږي.
پدې مقاله کې ، زه د دوام میکانیزمونه وپلټم چې د لینکس فایل APIs لخوا چمتو شوي. داسې ښکاري چې دلته هرڅه باید ساده وي: برنامه قوماندې ته زنګ وهي write()، او وروسته له دې چې د دې قوماندې عملیات بشپړ شي ، معلومات به په خوندي ډول په ډیسک کې زیرمه شي. خو write() یوازې د غوښتنلیک ډاټا کاپي کوي د کرنل کیچ ته چې په RAM کې موقعیت لري. د دې لپاره چې سیسټم مجبور کړي چې ډیسک ته ډاټا ولیکي، ځینې اضافي میکانیزمونه باید وکارول شي.
په عموم کې، دا مواد د یادښتونو مجموعه ده چې د هغه څه پورې اړه لري چې ما د خپلې خوښې په موضوع کې زده کړل. که موږ د خورا مهم په اړه په لنډه توګه وغږیږو ، نو دا معلومه شوه چې د دوامداره معلوماتو ذخیره کولو تنظیم کولو لپاره ، تاسو اړتیا لرئ کمانډ وکاروئ fdatasync() یا د بیرغ سره فایلونه خلاص کړئ O_DSYNC. که تاسو د دې په اړه نور څه زده کولو کې علاقه لرئ چې د کوډ څخه ډیسک ته په لاره کې ډیټا ته څه پیښیږي ، یو نظر وګورئ مقاله
د لیکلو () فنکشن کارولو ځانګړتیاوې
د سیسټم زنګ write() په معیار کې تعریف شوی د فایل تشریح کونکي ته د معلوماتو لیکلو هڅې په توګه. د کار د بریالیتوب وروسته write() د ډیټا لوستلو عملیات باید په سمه توګه هغه بایټونه بیرته راستانه کړي چې مخکې لیکل شوي وو، دا کار کول حتی که ډاټا د نورو پروسو یا تارونو څخه لاس رسی وي ( د POSIX معیار اړونده برخه). ، د نورمال فایل عملیاتو سره د تارونو د تعامل په برخه کې ، یو یادونه شتون لري چې وايي که دوه تارونه هر یو دا فنکشن ته زنګ ووهي ، نو هر کال باید ټولې هغه پایلې وګوري چې د بل کال اجرا کیدو لامل کیږي ، یا هیڅ پایلې نه ګورئ. دا دې پایلې ته رسوي چې ټولې فایل I/O عملیات باید په هغه منابع کې چې کار کوي یو بند وساتي.
ایا دا پدې معنی ده چې عملیات write() اټومي دی؟ د تخنیکي نظر څخه، هو. د معلوماتو لوستلو عملیات باید ټول یا هیڅ هغه څه بیرته راستانه کړي چې ورسره لیکل شوي write(). خو عملیات write()د معیار سره سم، پای ته اړتیا نلري، هر هغه څه چې د هغې څخه یې د لیکلو غوښتنه شوې وه لیکلې دي. دا اجازه لري چې یوازې د معلوماتو برخه ولیکئ. د مثال په توګه، موږ ممکن دوه جریانونه ولرو چې هر یو د ورته فایل توضیح کونکي لخوا تشریح شوي فایل ته 1024 بایټس ضمیمه کوي. د معیار له نظره ، پایله به د منلو وړ وي کله چې د لیکلو هر عملیات کولی شي فایل ته یوازې یو بایټ ضمیمه کړي. دا عملیات به اټومي پاتې شي، مګر وروسته له دې چې دوی بشپړ شي، هغه معلومات چې دوی فایل ته لیکي به ګډوډ شي. د سټیک اوور فلو په اړه پدې موضوع خورا په زړه پوري بحث.
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() ډیسک ته لږ ډیټا فلش کوي (4 KiB په XFS کې).
مبهم حالتونه کله چې د fsync () کارول
زه د دریو مبهم حالتونو په اړه فکر کولی شم fsync()کوم چې ما په عمل کې ولیدل.
دا ډول لومړۍ پېښه په ۲۰۰۸ کال کې رامنځته شوه. په هغه وخت کې، د فایرفوکس 2008 انٹرفیس "منجمد" که چیرې ډیری فایلونه ډیسک ته ولیکل شي. ستونزه دا وه چې د انٹرفیس پلي کول د دې حالت په اړه معلومات ذخیره کولو لپاره د SQLite ډیټابیس کارولی. د هر بدلون وروسته چې په انٹرفیس کې پیښیږي، فنکشن بلل کیږي fsync()، کوم چې د باثباته ډیټا ذخیره کولو ښه تضمین ورکړی. په بیا کارول شوي ext3 فایل سیسټم کې، فعالیت fsync() په سیسټم کې د ټولو "خندا" پاڼو ډیسک ته فلش شوی، او نه یوازې هغه چې د اړونده فایل سره تړاو لري. د دې معنی دا وه چې په فایرفوکس کې د تڼۍ کلیک کول کولی شي میګابایټ ډیټا په مقناطیسي ډیسک کې ولیکل شي ، کوم چې ډیری ثانیې وخت نیسي. د ستونزې حل، تر هغه چې زه پوهیدم مواد، د ډیټابیس سره کار د غیر متناسب شالید کارونو ته لیږدول وو. دا پدې مانا ده چې فایرفوکس د واقعیا اړتیا په پرتله د خورا سخت ذخیره کولو دوام اړتیاو پلي کولو لپاره کارولې ، او د ext3 فایل سیسټم ځانګړتیاوې یوازې دا ستونزه لا پسې پراخه کړې.
دویمه ستونزه په 2009 کې رامنځته شوه. بیا، د سیسټم له حادثې وروسته، د نوي ext4 فایل سیسټم کاروونکو وموندله چې ډیری نوي جوړ شوي فایلونه صفر اوږدوالی لري، مګر دا د زاړه ext3 فایل سیسټم سره نه پیښیږي. په تیرو پراګراف کې، ما د دې په اړه خبرې وکړې چې څنګه ext3 په ډیسک کې ډیر ډیټا ډنډ کړي، کوم چې شیان خورا ورو کړي. fsync(). د وضعیت د ښه کولو لپاره، ext4 یوازې هغه "خندا" پاڼې فلش کوي چې د یوې ځانګړې فایل سره تړاو لري. او د نورو فایلونو ډاټا د ext3 په پرتله د ډیر وخت لپاره په حافظه کې پاتې کیږي. دا د فعالیت ښه کولو لپاره ترسره شوی (د ډیفالټ په واسطه، ډاټا په دې حالت کې د 30 ثانیو لپاره پاتې کیږي، تاسو کولی شئ دا په کارولو سره تنظیم کړئ ; تاسو کولی شئ پدې اړه نور معلومات ترلاسه کړئ). دا پدې مانا ده چې د حادثې وروسته د معلوماتو لوی مقدار په غیرقانوني توګه له لاسه ورکول کیدی شي. د دې ستونزې د حل لاره کارول دي 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(). د دې ته د "Synchronized 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 / اوبنټو 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