ટકાઉ ડેટા સ્ટોરેજ અને Linux ફાઇલ API

મેં, ક્લાઉડ સિસ્ટમમાં ડેટા સ્ટોરેજની સ્થિરતા પર સંશોધન કરીને, હું મૂળભૂત બાબતોને સમજી શકું છું તેની ખાતરી કરવા માટે, મારી જાતને ચકાસવાનું નક્કી કર્યું. આઈ NVMe સ્પેક વાંચીને શરૂ કર્યું ડેટા પર્સિસ્ટન્સ (એટલે ​​કે સિસ્ટમની નિષ્ફળતા પછી ડેટા ઉપલબ્ધ થશે તેવી બાંયધરી આપે છે) તે સમજવા માટે અમને NMVe ડિસ્ક આપો. મેં નીચેના મુખ્ય તારણો કાઢ્યા છે: તમારે ડેટા લખવાનો આદેશ આપવામાં આવે તે ક્ષણથી નુકસાન થયેલા ડેટાને ધ્યાનમાં લેવાની જરૂર છે, અને જ્યાં સુધી તે સ્ટોરેજ માધ્યમમાં લખવામાં આવે ત્યાં સુધી. જો કે, મોટાભાગના પ્રોગ્રામ્સમાં, ડેટા લખવા માટે સિસ્ટમ કોલ્સનો ઉપયોગ તદ્દન સુરક્ષિત રીતે થાય છે.

આ લેખમાં, હું Linux ફાઈલ API દ્વારા પૂરી પાડવામાં આવેલ પર્સિસ્ટન્સ મિકેનિઝમ્સનું અન્વેષણ કરું છું. એવું લાગે છે કે અહીં બધું સરળ હોવું જોઈએ: પ્રોગ્રામ આદેશને કૉલ કરે છે write(), અને આ આદેશની કામગીરી પૂર્ણ થયા પછી, ડેટા સુરક્ષિત રીતે ડિસ્ક પર સંગ્રહિત થશે. પણ write() ફક્ત RAM માં સ્થિત કર્નલ કેશમાં એપ્લિકેશન ડેટાની નકલ કરે છે. સિસ્ટમને ડિસ્ક પર ડેટા લખવા માટે દબાણ કરવા માટે, કેટલીક વધારાની પદ્ધતિઓનો ઉપયોગ કરવો આવશ્યક છે.

સામાન્ય રીતે, આ સામગ્રી એ મારા રસના વિષય પર મેં જે શીખ્યા છે તેનાથી સંબંધિત નોંધોનો સમૂહ છે. જો આપણે સૌથી મહત્વપૂર્ણ વિશે ખૂબ જ ટૂંકમાં વાત કરીએ, તો તે તારણ આપે છે કે ટકાઉ ડેટા સ્ટોરેજ ગોઠવવા માટે, તમારે આદેશનો ઉપયોગ કરવાની જરૂર છે fdatasync() અથવા ધ્વજ સાથે ફાઇલો ખોલો O_DSYNC. જો તમને કોડથી ડિસ્ક સુધીના માર્ગમાં ડેટાનું શું થાય છે તે વિશે વધુ જાણવામાં રસ હોય, તો તેના પર એક નજર નાખો આ લેખ

write() ફંક્શનનો ઉપયોગ કરવાની સુવિધાઓ

સિસ્ટમ કૉલ write() ધોરણમાં વ્યાખ્યાયિત આઇઇઇઇ પોસિક્સ ફાઇલ વર્ણનકર્તા પર ડેટા લખવાના પ્રયાસ તરીકે. કાર્ય સફળતાપૂર્વક પૂર્ણ થયા પછી write() ડેટા રીડ ઑપરેશન્સે અગાઉ લખેલા બાઇટ્સ બરાબર પરત કરવા જોઈએ, જો ડેટા અન્ય પ્રક્રિયાઓ અથવા થ્રેડોમાંથી એક્સેસ કરવામાં આવી રહ્યો હોય તો પણ આમ કરવાથી (જોયેલું POSIX ધોરણનો અનુરૂપ વિભાગ). તે, સામાન્ય ફાઇલ ઑપરેશન્સ સાથે થ્રેડોની ક્રિયાપ્રતિક્રિયા પરના વિભાગમાં, એક નોંધ છે જે કહે છે કે જો બે થ્રેડો દરેક આ કાર્યોને કૉલ કરે છે, તો દરેક કૉલે કાં તો અન્ય કૉલના અમલીકરણ તરફ દોરી જાય છે તે તમામ સૂચિત પરિણામો જોવા જોઈએ, અથવા કોઈ પણ પરિણામ જોતા નથી. આ નિષ્કર્ષ તરફ દોરી જાય છે કે તમામ ફાઇલ I/O ઑપરેશન્સે જે સંસાધન પર કામ કરવામાં આવે છે તેના પર લૉક રાખવો જોઈએ.

શું આનો અર્થ એ છે કે ઓપરેશન write() અણુ છે? તકનીકી દૃષ્ટિકોણથી, હા. ડેટા રીડ ઑપરેશન્સે જે લખવામાં આવ્યું હતું તેમાંથી બધુ જ અથવા કંઈપણ પરત કરવું આવશ્યક છે write(). પરંતુ ઓપરેશન write(), ધોરણ અનુસાર, તેણીને જે લખવાનું કહેવામાં આવ્યું હતું તે બધું લખીને, તેને સમાપ્ત કરવાની જરૂર નથી. તેને ડેટાનો માત્ર એક ભાગ લખવાની મંજૂરી છે. ઉદાહરણ તરીકે, અમારી પાસે સમાન ફાઇલ વર્ણનકર્તા દ્વારા વર્ણવેલ ફાઇલમાં 1024 બાઇટ્સ જોડતી દરેક સ્ટ્રીમ હોઈ શકે છે. ધોરણના દૃષ્ટિકોણથી, પરિણામ સ્વીકાર્ય હશે જ્યારે દરેક લેખન ઑપરેશન ફાઇલમાં માત્ર એક બાઇટ ઉમેરી શકે. આ ઓપરેશન્સ એટોમિક રહેશે, પરંતુ તેઓ પૂર્ણ થયા પછી, તેઓ ફાઇલમાં લખે છે તે ડેટા ગૂંચવવામાં આવશે. અહીં સ્ટેક ઓવરફ્લો પર આ વિષય પર ખૂબ જ રસપ્રદ ચર્ચા.

fsync() અને fdatasync() કાર્યો

ડિસ્ક પર ડેટા ફ્લશ કરવાનો સૌથી સહેલો રસ્તો ફંક્શનને કૉલ કરવાનો છે fsync(). આ ફંક્શન ઓપરેટિંગ સિસ્ટમને તમામ સંશોધિત બ્લોક્સને કેશમાંથી ડિસ્ક પર ખસેડવા માટે કહે છે. આમાં ફાઇલના તમામ મેટાડેટા (એક્સેસ ટાઇમ, ફાઇલમાં ફેરફાર કરવાનો સમય અને તેથી વધુ) શામેલ છે. હું માનું છું કે આ મેટાડેટાની ભાગ્યે જ જરૂર છે, તેથી જો તમને ખબર હોય કે તે તમારા માટે મહત્વપૂર્ણ નથી, તો તમે ફંક્શનનો ઉપયોગ કરી શકો છો fdatasync(). આ મદદ પર fdatasync() તે કહે છે કે આ ફંક્શનની કામગીરી દરમિયાન, ડિસ્કમાં મેટાડેટાનો આટલો જથ્થો સાચવવામાં આવે છે, જે "નીચેની ડેટા રીડિંગ કામગીરીના યોગ્ય અમલ માટે જરૂરી છે." અને આ તે જ છે જેની મોટાભાગની એપ્લિકેશનો કાળજી લે છે.

એક સમસ્યા જે અહીં ઊભી થઈ શકે છે તે એ છે કે આ મિકેનિઝમ્સ બાંહેધરી આપતા નથી કે સંભવિત નિષ્ફળતા પછી ફાઇલ શોધી શકાય છે. ખાસ કરીને, જ્યારે નવી ફાઇલ બનાવવામાં આવે છે, ત્યારે કોઈએ કૉલ કરવો જોઈએ fsync() તે સમાવે છે તે ડિરેક્ટરી માટે. નહિંતર, ક્રેશ પછી, તે ચાલુ થઈ શકે છે કે આ ફાઇલ અસ્તિત્વમાં નથી. તેનું કારણ એ છે કે UNIX હેઠળ, હાર્ડ લિંક્સના ઉપયોગને કારણે, ફાઇલ બહુવિધ ડિરેક્ટરીઓમાં અસ્તિત્વમાં હોઈ શકે છે. તેથી, જ્યારે કૉલ કરો fsync() કઈ ડાયરેક્ટરી ડેટા પણ ડિસ્ક પર ફ્લશ થવો જોઈએ તે જાણવા માટે ફાઈલ માટે કોઈ રસ્તો નથી (અહીં તમે આ વિશે વધુ વાંચી શકો છો). એવું લાગે છે કે ext4 ફાઇલ સિસ્ટમ સક્ષમ છે આપમેળે લાગુ કરો fsync() અનુરૂપ ફાઈલો ધરાવતી ડિરેક્ટરીઓ માટે, પરંતુ અન્ય ફાઈલ સિસ્ટમો સાથે આવું ન હોઈ શકે.

આ મિકેનિઝમ અલગ અલગ ફાઇલ સિસ્ટમમાં અલગ રીતે લાગુ કરી શકાય છે. મે વાપર્યુ blktrace 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 સેકન્ડ સુધી રહે છે, તમે આનો ઉપયોગ કરીને તેને ગોઠવી શકો છો dirty_expire_centisecs; અહીં તમે આના પર વધુ માહિતી મેળવી શકો છો). આનો અર્થ એ છે કે ક્રેશ થયા પછી મોટી માત્રામાં ડેટા પુનઃપ્રાપ્ત કરી શકાય તેમ નથી. આ સમસ્યાનો ઉકેલ ઉપયોગ કરવાનો છે 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(). આ POSIX સ્પષ્ટીકરણો તેને "સિંક્રોનાઇઝ્ડ 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() આ આદેશ "ખૂબ જોખમી" હોવાનું કહેવાય છે. તેનો ઉપયોગ કરવાની ભલામણ કરવામાં આવતી નથી. લક્ષણો અને જોખમો sync_file_range() માં ખૂબ જ સારી રીતે વર્ણવેલ આ સામગ્રી ખાસ કરીને, જ્યારે કર્નલ ડિસ્ક પર "ગંદા" ડેટાને ફ્લશ કરે છે ત્યારે નિયંત્રણ કરવા માટે આ કૉલ RocksDB નો ઉપયોગ કરે છે. પરંતુ તે જ સમયે, સ્થિર ડેટા સ્ટોરેજની ખાતરી કરવા માટે, તેનો ઉપયોગ પણ થાય છે fdatasync(). આ કોડ આ વિષય પર RocksDB ની કેટલીક રસપ્રદ ટિપ્પણીઓ છે. ઉદાહરણ તરીકે, તે કૉલ જેવું લાગે છે sync_file_range() ZFS નો ઉપયોગ કરતી વખતે ડિસ્ક પર ડેટા ફ્લશ થતો નથી. અનુભવ મને કહે છે કે ભાગ્યે જ ઉપયોગમાં લેવાતા કોડમાં ભૂલો હોઈ શકે છે. તેથી, જ્યાં સુધી એકદમ જરૂરી ન હોય ત્યાં સુધી હું આ સિસ્ટમ કૉલનો ઉપયોગ કરવા સામે સલાહ આપીશ.

ડેટા દ્રઢતાની ખાતરી કરવામાં મદદ કરવા માટે સિસ્ટમ કૉલ્સ

હું નિષ્કર્ષ પર આવ્યો છું કે ત્યાં ત્રણ અભિગમો છે જેનો ઉપયોગ સતત I/O કામગીરી કરવા માટે થઈ શકે છે. તે બધાને ફંક્શન કૉલની જરૂર છે fsync() ડિરેક્ટરી માટે જ્યાં ફાઇલ બનાવવામાં આવી હતી. આ અભિગમો છે:

1. કાર્ય કૉલ fdatasync() અથવા fsync() કાર્ય પછી write() (ઉપયોગ કરવો વધુ સારું fdatasync()).
2. ધ્વજ સાથે ખોલેલ ફાઇલ વર્ણનકર્તા સાથે કામ કરવું O_DSYNC અથવા O_SYNC (વધુ સારું - ધ્વજ સાથે O_DSYNC).
3. આદેશ વપરાશ pwritev2() ધ્વજ સાથે RWF_DSYNC અથવા RWF_SYNC (પ્રાધાન્ય ધ્વજ સાથે RWF_DSYNC).

પ્રદર્શન નોંધો

મેં તપાસ કરેલી વિવિધ મિકેનિઝમ્સની કામગીરીને મેં કાળજીપૂર્વક માપી નથી. તેમના કામની ઝડપમાં મેં જે તફાવતો જોયા તે બહુ ઓછા છે. આનો અર્થ એ છે કે હું ખોટો હોઈ શકું છું, અને અન્ય પરિસ્થિતિઓમાં સમાન વસ્તુ અલગ પરિણામો બતાવી શકે છે. પ્રથમ, હું શું પ્રભાવને વધુ અસર કરે છે તે વિશે વાત કરીશ, અને પછી, પ્રદર્શનને ઓછી અસર કરે છે તે વિશે.

1. ફાઇલ ડેટાને ઓવરરાઇટ કરવું ફાઇલમાં ડેટા ઉમેરવા કરતાં વધુ ઝડપી છે (પ્રદર્શન લાભ 2-100% હોઈ શકે છે). ફાઇલ સાથે ડેટા જોડવા માટે ફાઇલના મેટાડેટામાં વધારાના ફેરફારોની જરૂર પડે છે, સિસ્ટમ કૉલ પછી પણ fallocate(), પરંતુ આ અસરની તીવ્રતા અલગ અલગ હોઈ શકે છે. હું શ્રેષ્ઠ પ્રદર્શન માટે, કૉલ કરવાની ભલામણ કરું છું fallocate() જરૂરી જગ્યા અગાઉથી ફાળવવા માટે. પછી આ જગ્યા સ્પષ્ટપણે શૂન્યથી ભરેલી હોવી જોઈએ અને બોલાવવી જોઈએ fsync(). આનાથી ફાઈલ સિસ્ટમમાં લાગતાવળગતા બ્લોક્સને "અનલૉકેટેડ" ને બદલે "ફાળવેલ" તરીકે ચિહ્નિત કરવામાં આવશે. આ એક નાનો (લગભગ 2%) પ્રદર્શન સુધારણા આપે છે. ઉપરાંત, કેટલીક ડિસ્કમાં અન્ય કરતા ધીમી પ્રથમ બ્લોક એક્સેસ કામગીરી હોઈ શકે છે. આનો અર્થ એ છે કે શૂન્ય સાથે જગ્યા ભરવાથી નોંધપાત્ર (લગભગ 100%) પ્રદર્શન સુધારણા થઈ શકે છે. ખાસ કરીને, આ ડિસ્ક સાથે થઈ શકે છે. AWS EBS (આ બિનસત્તાવાર ડેટા છે, હું તેની પુષ્ટિ કરી શક્યો નથી). તે જ સંગ્રહ માટે જાય છે. GCP પર્સિસ્ટન્ટ ડિસ્ક (અને આ પહેલેથી જ અધિકૃત માહિતી છે, પરીક્ષણો દ્વારા પુષ્ટિ થયેલ છે). અન્ય નિષ્ણાતોએ પણ એવું જ કર્યું છે અવલોકનવિવિધ ડિસ્ક સાથે સંબંધિત.
2. ઓછા સિસ્ટમ કૉલ્સ, ઉચ્ચ કાર્યક્ષમતા (ગેઇન લગભગ 5% હોઈ શકે છે). તે કૉલ જેવું લાગે છે open() ધ્વજ સાથે O_DSYNC અથવા કૉલ કરો pwritev2() ધ્વજ સાથે RWF_SYNC ઝડપી કૉલ fdatasync(). મને શંકા છે કે અહીંનો મુદ્દો એ છે કે આ અભિગમ સાથે, હકીકત એ છે કે સમાન કાર્યને ઉકેલવા માટે ઓછા સિસ્ટમ કૉલ્સ કરવા પડે છે (બેને બદલે એક કૉલ) ભૂમિકા ભજવે છે. પરંતુ પ્રદર્શન તફાવત ખૂબ જ નાનો છે, તેથી તમે તેને સરળતાથી અવગણી શકો છો અને એપ્લિકેશનમાં કંઈક ઉપયોગ કરી શકો છો જે તેના તર્કની ગૂંચવણ તરફ દોરી જતું નથી.

જો તમને ટકાઉ ડેટા સ્ટોરેજના વિષયમાં રસ હોય, તો અહીં કેટલીક ઉપયોગી સામગ્રી છે:

• I/O ઍક્સેસ પદ્ધતિઓ ઇનપુટ/આઉટપુટ મિકેનિઝમ્સની મૂળભૂત બાબતોની ઝાંખી.
• ડેટા ડિસ્ક સુધી પહોંચે તેની ખાતરી કરવી - એપ્લિકેશનથી ડિસ્ક તરફ જવાના માર્ગમાં ડેટાનું શું થાય છે તે વિશેની વાર્તા.
• તમારે સમાવિષ્ટ ડિરેક્ટરી ક્યારે fsync કરવી જોઈએ - ક્યારે અરજી કરવી તે પ્રશ્નનો જવાબ fsync() ડિરેક્ટરીઓ માટે. ટૂંકમાં, તે તારણ આપે છે કે નવી ફાઇલ બનાવતી વખતે તમારે આ કરવાની જરૂર છે, અને આ ભલામણનું કારણ એ છે કે Linux માં સમાન ફાઇલના ઘણા સંદર્ભો હોઈ શકે છે.
• Linux પર SQL સર્વર: FUA આંતરિક - Linux પ્લેટફોર્મ પર SQL સર્વરમાં કેવી રીતે સતત ડેટા સ્ટોરેજ લાગુ કરવામાં આવે છે તેનું વર્ણન અહીં છે. અહીં Windows અને Linux સિસ્ટમ કૉલ્સ વચ્ચે કેટલીક રસપ્રદ સરખામણીઓ છે. મને લગભગ ખાતરી છે કે XFS ના FUA ઑપ્ટિમાઇઝેશન વિશે મેં શીખ્યા કે આ સામગ્રીનો આભાર હતો.

શું તમે ક્યારેય એવો ડેટા ગુમાવ્યો છે જે તમે વિચાર્યું હતું કે ડિસ્ક પર સુરક્ષિત રીતે સંગ્રહિત છે?

સોર્સ: www.habr.com