క్లౌడ్ సిస్టమ్‌లలో డేటా నిల్వ యొక్క స్థిరత్వం గురించి పరిశోధిస్తున్నప్పుడు, నేను ప్రాథమిక విషయాలను అర్థం చేసుకున్నానని నిర్ధారించుకోవడానికి నన్ను నేను పరీక్షించుకోవాలని నిర్ణయించుకున్నాను. I స్థిరమైన డేటా నిల్వకు సంబంధించి (అంటే, సిస్టమ్ వైఫల్యం తర్వాత డేటా అందుబాటులో ఉంటుందని హామీ ఇస్తుంది) గురించి అర్థం చేసుకోవడానికి మాకు NMVe డిస్క్‌లను అందించండి. నేను ఈ క్రింది ప్రధాన తీర్మానాలను చేసాను: డేటాను వ్రాయడానికి ఆదేశం ఇవ్వబడిన క్షణం నుండి అది నిల్వ మాధ్యమానికి వ్రాయబడే వరకు డేటా దెబ్బతిన్నదని పరిగణించాలి. అయినప్పటికీ, చాలా ప్రోగ్రామ్‌లు డేటాను రికార్డ్ చేయడానికి సిస్టమ్ కాల్‌లను చాలా సంతోషంగా ఉపయోగిస్తాయి.
ఈ పోస్ట్‌లో, Linux ఫైల్ APIల ద్వారా అందించబడిన నిరంతర నిల్వ మెకానిజమ్‌లను నేను అన్వేషిస్తాను. ఇక్కడ ప్రతిదీ సరళంగా ఉండాలని అనిపిస్తుంది: ప్రోగ్రామ్ ఆదేశాన్ని పిలుస్తుంది 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 కిబి వ్రాస్తుంది మరియు fdatasync() - 16 కిబి). అలాగే, XFS ext4 కంటే కొంచెం వేగంగా ఉందని నేను కనుగొన్నాను. మరియు ఇక్కడ సహాయంతో blktrace అని తెలుసుకోగలిగారు fdatasync() డిస్క్‌కి తక్కువ డేటాను ఫ్లష్ చేస్తుంది (XFSలో 4 KiB).
fsync()ని ఉపయోగిస్తున్నప్పుడు తలెత్తే అస్పష్టమైన పరిస్థితులు
నేను మూడు అస్పష్టమైన పరిస్థితుల గురించి ఆలోచించగలను fsync()నేను ఆచరణలో ఎదుర్కొన్న.
ఇలాంటి మొదటి కేసు 2008లో జరిగింది. పెద్ద సంఖ్యలో ఫైల్‌లు డిస్క్‌కి వ్రాయబడితే అప్పుడు Firefox 3 ఇంటర్‌ఫేస్ స్తంభించిపోయింది. సమస్య ఏమిటంటే, ఇంటర్‌ఫేస్ అమలు దాని స్థితి గురించి సమాచారాన్ని నిల్వ చేయడానికి SQLite డేటాబేస్‌ను ఉపయోగించింది. ఇంటర్ఫేస్లో సంభవించిన ప్రతి మార్పు తర్వాత, ఫంక్షన్ అని పిలుస్తారు fsync(), ఇది స్థిరమైన డేటా నిల్వకు మంచి హామీలను ఇచ్చింది. అప్పుడు ఉపయోగించిన ext3 ఫైల్ సిస్టమ్‌లో, ఫంక్షన్ fsync() సిస్టమ్‌లోని అన్ని “డర్టీ” పేజీలను డిస్క్‌కి డంప్ చేసింది మరియు సంబంధిత ఫైల్‌కు సంబంధించినవి మాత్రమే కాదు. ఫైర్‌ఫాక్స్‌లోని బటన్‌ను క్లిక్ చేయడం ద్వారా మాగ్నెటిక్ డిస్క్‌కి వ్రాయడానికి మెగాబైట్‌ల డేటాను ప్రేరేపించవచ్చని దీని అర్థం, దీనికి చాలా సెకన్లు పట్టవచ్చు. నేను అర్థం చేసుకున్నంతవరకు సమస్యకు పరిష్కారం మెటీరియల్ అనేది డేటాబేస్తో పనిని అసమకాలిక నేపథ్య పనులకు బదిలీ చేయడం. దీనర్థం Firefox గతంలో నిజంగా అవసరమైన దానికంటే ఎక్కువ కఠినమైన నిల్వ అవసరాలను అమలు చేసింది మరియు 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 ఫ్లాగ్‌లను ఉపయోగించి ఫైల్‌లను తెరవడం
స్థిరమైన డేటా నిల్వను అందించే Linux మెకానిజమ్‌ల చర్చకు తిరిగి వద్దాం. నామంగా, మేము జెండాను ఉపయోగించడం గురించి మాట్లాడుతున్నాము 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 Linux 5.4/Ubuntu 20.04 సిస్టమ్‌పై. ఈ విధానం మరింత సమర్థవంతంగా ఉండాలి, ఎందుకంటే ఉపయోగించినప్పుడు, డిస్క్‌కి కనీస మొత్తంలో డేటా వ్రాయబడుతుంది మరియు రెండు (కాష్‌ను వ్రాయడం మరియు ఫ్లష్ చేయడం) కాకుండా ఒక ఆపరేషన్ ఉపయోగించబడుతుంది. నాకు లింక్ దొరికింది 2018 కెర్నల్, ఇది ఈ విధానాన్ని అమలు చేస్తుంది. ఇతర ఫైల్ సిస్టమ్‌లకు ఈ ఆప్టిమైజేషన్‌ని వర్తింపజేయడం గురించి అక్కడ కొంత చర్చ ఉంది, కానీ నాకు తెలిసినంతవరకు, XFS మాత్రమే ఇప్పటివరకు దీనికి మద్దతిచ్చే ఫైల్ సిస్టమ్.
sync_file_range() ఫంక్షన్
Linuxకి సిస్టమ్ కాల్ ఉంది , ఇది మొత్తం ఫైల్‌ని కాకుండా ఫైల్‌లోని కొంత భాగాన్ని మాత్రమే డిస్క్‌కి ఫ్లష్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. ఈ కాల్ అసమకాలిక డేటా ఫ్లష్‌ను ప్రారంభిస్తుంది మరియు అది పూర్తయ్యే వరకు వేచి ఉండదు. కానీ సర్టిఫికేట్‌లో 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()డైరెక్టరీల కోసం. దీన్ని క్లుప్తంగా చెప్పాలంటే, క్రొత్త ఫైల్‌ను సృష్టించేటప్పుడు మీరు దీన్ని చేయవలసి ఉంటుందని తేలింది మరియు ఈ సిఫార్సుకు కారణం Linux లో ఒకే ఫైల్‌కు అనేక సూచనలు ఉండవచ్చు. - — Linux ప్లాట్‌ఫారమ్‌లోని SQL సర్వర్‌లో నిరంతర డేటా నిల్వ ఎలా అమలు చేయబడుతుందో ఇక్కడ వివరించబడింది. ఇక్కడ Windows మరియు Linux సిస్టమ్ కాల్‌ల మధ్య కొన్ని ఆసక్తికరమైన పోలికలు ఉన్నాయి. XFS యొక్క FUA ఆప్టిమైజేషన్ గురించి నేను తెలుసుకున్న ఈ మెటీరియల్‌కు ధన్యవాదాలు అని నేను దాదాపు ఖచ్చితంగా అనుకుంటున్నాను.
డిస్క్‌లో సురక్షితంగా నిల్వ చేయబడిందని మీరు భావించిన డేటాను మీరు కోల్పోయారా?
మూలం: www.habr.com