ዘላቂ የውሂብ ማከማቻ እና የሊኑክስ ፋይል ኤፒአይዎች

እኔ, በደመና ስርዓቶች ውስጥ የውሂብ ማከማቻ መረጋጋትን በማጥናት, እራሴን ለመፈተሽ ወሰንኩኝ, መሰረታዊ ነገሮችን መረዳቴን ለማረጋገጥ. አይ NVMe spec በማንበብ ተጀምሯል። የመረጃን ጽናት በተመለከተ ምን ዋስትናዎች እንዳሉ ለመረዳት (ይህም ከስርዓት ውድቀት በኋላ መረጃ እንደሚገኝ ዋስትና) NMVe ዲስኮች ይሰጡናል ። የሚከተሉትን ዋና ድምዳሜዎች አድርጌአለሁ-የውሂብ ጽሁፍ ትዕዛዝ ከተሰጠበት ጊዜ ጀምሮ እና ወደ ማከማቻ ማህደረ መረጃው እስከሚጻፉበት ጊዜ ድረስ የተበላሸውን ውሂብ ግምት ውስጥ ማስገባት አለብዎት. ነገር ግን፣ በአብዛኛዎቹ ፕሮግራሞች፣ የስርዓት ጥሪዎች መረጃን ለመፃፍ ደህንነቱ በተጠበቀ ሁኔታ ጥቅም ላይ ይውላሉ።

በዚህ ጽሑፍ ውስጥ፣ በሊኑክስ ፋይል ኤፒአይዎች የቀረቡትን የመቆየት ዘዴዎችን እዳስሳለሁ። እዚህ ሁሉም ነገር ቀላል መሆን ያለበት ይመስላል: ፕሮግራሙ ትዕዛዙን ይጠራል write(), እና የዚህ ትዕዛዝ ስራ ከተጠናቀቀ በኋላ ውሂቡ ደህንነቱ በተጠበቀ ሁኔታ በዲስክ ላይ ይቀመጣል. ግን write() የመተግበሪያ ውሂብን በ RAM ውስጥ ወዳለው የከርነል መሸጎጫ ብቻ ይቀዳል። ስርዓቱ መረጃን ወደ ዲስክ እንዲጽፍ ለማስገደድ, አንዳንድ ተጨማሪ ዘዴዎችን መጠቀም ያስፈልጋል.

በአጠቃላይ ይህ ቁሳቁስ ለእኔ ትኩረት በሚሰጥ ርዕስ ላይ ከተማርኩት ጋር የተገናኘ የማስታወሻ ስብስብ ነው። ስለ በጣም አስፈላጊው ነገር በአጭሩ ከተነጋገርን, ዘላቂ የውሂብ ማከማቻን ለማደራጀት ትዕዛዙን መጠቀም ያስፈልግዎታል. fdatasync() ወይም በባንዲራ ፋይሎችን ይክፈቱ O_DSYNC. ከኮድ ወደ ዲስክ በሚወስደው መንገድ ላይ ባለው መረጃ ላይ ምን እንደሚፈጠር የበለጠ ለማወቅ ፍላጎት ካሎት ይመልከቱ ይሄ ጽሑፍ.

የመጻፍ () ተግባርን የመጠቀም ባህሪዎች

የስርዓት ጥሪ write() በደረጃው ውስጥ ይገለጻል IEEE POSIX በፋይል ገላጭ ላይ ውሂብ ለመጻፍ እንደ ሙከራ. ሥራው በተሳካ ሁኔታ ከተጠናቀቀ በኋላ write() የውሂብ ንባብ ክዋኔዎች ከዚህ ቀደም የተፃፉትን ባይቶች በትክክል መመለስ አለባቸው ፣ ይህንንም በማድረግ ውሂቡ ከሌሎች ሂደቶች ወይም ክሮች እየደረሰ ቢሆንም (እነሆም የ POSIX መደበኛ ክፍል)። ይህ ነው, ከመደበኛ የፋይል ስራዎች ጋር ክሮች መስተጋብር በሚለው ክፍል ውስጥ ሁለት ክሮች እያንዳንዳቸው እነዚህን ተግባራት ቢጠሩ, እያንዳንዱ ጥሪ የሌላኛው ጥሪ አፈፃፀም የሚያመጣውን ሁሉንም የተጠቆሙትን ውጤቶች ማየት አለበት የሚል ማስታወሻ አለ. ምንም ውጤት አላየሁም. ይህ ሁሉም የፋይል I/O ስራዎች በሚሰራበት ሃብት ላይ መቆለፊያ መያዝ አለባቸው ወደሚል መደምደሚያ ይመራል።

ይህ ማለት ኦፕሬሽኑ ማለት ነው write() አቶሚክ ነው? ከቴክኒካዊ እይታ, አዎ. የውሂብ ንባብ ክዋኔዎች የተፃፉትን በሙሉ ወይም አንዳቸውም መመለስ አለባቸው write(). ግን ቀዶ ጥገናው write(), በስታንዳርድ መሰረት, እንድትጽፍ የተጠየቀችውን ሁሉ በመጻፍ ማለቅ የለበትም. የመረጃውን ክፍል ብቻ ለመፃፍ ተፈቅዶለታል። ለምሳሌ፣ በተመሳሳዩ የፋይል ገላጭ በተገለጸው ፋይል ላይ እያንዳንዳቸው 1024 ባይት የሚጨምሩ ሁለት ዥረቶች ሊኖሩን ይችላሉ። ከደረጃው አንጻር እያንዳንዱ የፅሁፍ ስራዎች በፋይሉ ላይ አንድ ባይት ብቻ ሲጨምሩ ውጤቱ ተቀባይነት ይኖረዋል። እነዚህ ክዋኔዎች አቶሚክ ሆነው ይቆያሉ፣ ነገር ግን ከጨረሱ በኋላ፣ ወደ ፋይሉ የሚጽፉት ዳታ ይደመሰሳል። እዚህ በ Stack Overflow ላይ በዚህ ርዕስ ላይ በጣም አስደሳች ውይይት።

fsync () እና fdatasync () ተግባራት

መረጃን ወደ ዲስክ ለማውጣት ቀላሉ መንገድ ተግባሩን መጥራት ነው fsync(). ይህ ተግባር ኦፕሬቲንግ ሲስተም ሁሉንም የተሻሻሉ ብሎኮች ከመሸጎጫው ወደ ዲስክ እንዲያንቀሳቅስ ይጠይቃል። ይህ ሁሉንም የፋይሉ ሜታዳታ (የመዳረሻ ጊዜ፣ የፋይል ማሻሻያ ጊዜ እና የመሳሰሉትን) ያካትታል። ይህ ሜታዳታ እምብዛም አያስፈልግም ብዬ አምናለሁ፣ ስለዚህ ለእርስዎ አስፈላጊ እንዳልሆነ ካወቁ ተግባሩን መጠቀም ይችላሉ። fdatasync(). በ እገዛ ላይ fdatasync() ይህ ተግባር በሚሠራበት ጊዜ እንዲህ ያለው የሜታዳታ መጠን በዲስክ ላይ እንደሚቀመጥ ይናገራል ይህም "ለሚከተሉት የውሂብ ንባብ ስራዎች ትክክለኛ አፈፃፀም አስፈላጊ ነው." እና አብዛኛው አፕሊኬሽኖች የሚጨነቁት ይሄ ነው።

እዚህ ሊነሳ የሚችል አንድ ችግር እነዚህ ዘዴዎች ፋይሉ ከተሳካ ውድቀት በኋላ ሊገኝ እንደሚችል ዋስትና አይሰጡም. በተለይም አዲስ ፋይል ሲፈጠር አንድ ሰው መደወል አለበት fsync() በውስጡ የያዘው ማውጫ. ያለበለዚያ ፣ ከብልሽት በኋላ ፣ ይህ ፋይል እንደሌለ ሊታወቅ ይችላል። ይህ የሆነበት ምክንያት በ UNIX ስር, በሃርድ ማገናኛዎች አጠቃቀም ምክንያት, ፋይል በበርካታ ማውጫዎች ውስጥ ሊኖር ይችላል. ስለዚህ, ሲደውሉ fsync() ፋይሉ የትኛው ማውጫ ውሂብ ወደ ዲስክ መፍሰስ እንዳለበት የሚያውቅበት ምንም መንገድ የለም (እዚህ ስለዚህ ጉዳይ የበለጠ ማንበብ ይችላሉ). የ ext4 ፋይል ስርዓት አቅም ያለው ይመስላል በራስ-ሰር አጠቃቀም fsync() ተጓዳኝ ፋይሎችን ወደያዙ ማውጫዎች, ነገር ግን ይህ በሌሎች የፋይል ስርዓቶች ላይ ላይሆን ይችላል.

ይህ ዘዴ በተለያዩ የፋይል ስርዓቶች ውስጥ በተለየ መንገድ ሊተገበር ይችላል. ተ ጠ ቀ ም ኩ blktrace በ ext4 እና XFS የፋይል ስርዓቶች ውስጥ ምን የዲስክ ስራዎች ጥቅም ላይ እንደሚውሉ ለማወቅ. ሁለቱም ለፋይሎች ይዘቶች እና ለፋይል ስርዓት ጆርናል ለዲስክ የተለመደውን የመፃፍ ትዕዛዞችን ይሰጣሉ ፣ መሸጎጫውን ያጥፉ እና FUA (Force Unit Access, data በቀጥታ ወደ ዲስክ በመፃፍ ፣ መሸጎጫውን በማለፍ) በመጽሔቱ ላይ ይፃፉ ። የግብይቱን እውነታ ለማረጋገጥ ምናልባት ያንን ያደርጉ ይሆናል። FUAን በማይደግፉ ድራይቮች ላይ፣ ይህ ሁለት የመሸጎጫ ማፍሰሻዎችን ያስከትላል። የእኔ ሙከራዎች ይህን አሳይተዋል fdatasync() ትንሽ ፈጣን fsync(). መገልገያ blktrace መሆኑን ይጠቁማል fdatasync() ብዙውን ጊዜ ያነሰ ውሂብ ወደ ዲስክ ይጽፋል (በ ext4 fsync() 20 ኪቢ ይጽፋል, እና fdatasync() - 16 ኪ.ቢ.) እንዲሁም፣ XFS ከ ext4 ትንሽ ፈጣን መሆኑን ተረድቻለሁ። እና እዚህ በእርዳታ blktrace የሚለውን ለማወቅ ችሏል። fdatasync() ያነሰ ውሂብ ወደ ዲስክ (4 ኪቢ በXFS) ያፈስሳል።

fsync () ሲጠቀሙ አሻሚ ሁኔታዎች

ስለ ሶስት አሻሚ ሁኔታዎች ማሰብ እችላለሁ fsync()በተግባር ያጋጠመኝ.

የመጀመሪያው እንዲህ ዓይነቱ ክስተት በ 2008 ተከስቷል. በዚያን ጊዜ የፋየርፎክስ 3 በይነገጽ ብዙ ቁጥር ያላቸው ፋይሎች ወደ ዲስክ እየተጻፉ ከሆነ "በረዶ" ነበር. ችግሩ የበይነገጽ አተገባበር ስለ ግዛቱ መረጃ ለማከማቸት የ 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(). በ POSIX ዝርዝሮች ይህ "የተመሳሰለ I/O ፋይል ኢንተግሪቲ ማጠናቀቅ" እና "የውሂብ ኢንተግሪቲ ማጠናቀቅ" ይባላል። የዚህ አካሄድ ዋና ጥቅሙ የመረጃውን ታማኝነት ለማረጋገጥ አንድ የስርዓት ጥሪ ብቻ ነው መተግበር የሚያስፈልገው እንጂ ሁለት አይደለም (ለምሳሌ፡- write() и fdatasync()). የዚህ አቀራረብ ዋነኛው ጉዳቱ ተጓዳኝ የፋይል ገላጭን በመጠቀም ሁሉም የመፃፍ ስራዎች እንዲመሳሰሉ ይደረጋል, ይህም የመተግበሪያውን ኮድ የማዋቀር ችሎታን ሊገድብ ይችላል.

ቀጥታ I/Oን ከO_DIRECT ባንዲራ ጋር መጠቀም

የስርዓት ጥሪ 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() ውስጥ በጣም በደንብ ተገልጿል ይሄ ቁሳቁስ. በተለይም ይህ ጥሪ ከርነል "ቆሻሻ" መረጃን ወደ ዲስክ ሲያፈስ ለመቆጣጠር 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 ኢቢኤስ (ይህ መደበኛ ያልሆነ መረጃ ነው፣ ላረጋግጥላቸው አልቻልኩም)። ለማከማቻው ተመሳሳይ ነው. የጂሲፒ ቋሚ ዲስክ (እና ይህ ቀድሞውኑ ኦፊሴላዊ መረጃ ነው, በፈተናዎች የተረጋገጠ). ሌሎች ባለሙያዎችም እንዲሁ አድርገዋል ምልከታከተለያዩ ዲስኮች ጋር የተያያዘ.
2. ጥቂት የስርዓት ጥሪዎች, አፈፃፀሙ ከፍ ያለ ነው (ትርፉ ወደ 5% ገደማ ሊሆን ይችላል). ፈታኝ ይመስላል open() ባንዲራ ያለው O_DSYNC ወይም ይደውሉ pwritev2() ባንዲራ ያለው RWF_SYNC ፈጣን ጥሪ fdatasync(). እዚህ ላይ ዋናው ቁም ነገር ከዚህ አካሄድ ጋር ተመሳሳይ ተግባር ለመፍታት (ከሁለት ይልቅ አንድ ጥሪ) ጥቂት የስርዓት ጥሪዎች መደረጉ የራሱን ሚና እንደሚጫወት እገምታለሁ። ነገር ግን የአፈፃፀም ልዩነት በጣም ትንሽ ነው, ስለዚህ በቀላሉ ችላ ሊሉት እና በመተግበሪያው ውስጥ ወደ አመክንዮው ውስብስብነት የማይመራውን ነገር መጠቀም ይችላሉ.

ዘላቂ የመረጃ ማከማቻ ርዕስ ላይ ፍላጎት ካሎት አንዳንድ ጠቃሚ ቁሳቁሶች እዚህ አሉ

• የI/O መዳረሻ ዘዴዎች - የግቤት / ውፅዓት ዘዴዎች አጠቃላይ እይታ።
• መረጃ ወደ ዲስክ መድረሱን ማረጋገጥ - ከመተግበሪያው ወደ ዲስክ በሚወስደው መንገድ ላይ ባለው መረጃ ላይ ምን እንደሚከሰት ታሪክ።
• ማውጫውን መቼ ማመሳሰል አለብዎት? - መቼ ማመልከት እንዳለበት ለሚለው ጥያቄ መልስ fsync() ለ ማውጫዎች. በአጭር አነጋገር, አዲስ ፋይል ሲፈጥሩ ይህን ማድረግ ያስፈልግዎታል, እና የዚህ ምክር ምክንያት በሊኑክስ ውስጥ ለተመሳሳይ ፋይል ብዙ ማጣቀሻዎች ሊኖሩ ይችላሉ.
• SQL አገልጋይ በሊኑክስ፡ FUA Internals - የውሂብ ጽናት በሊኑክስ መድረክ ላይ በ SQL አገልጋይ ውስጥ እንዴት እንደሚተገበር መግለጫ እዚህ አለ። በዊንዶውስ እና ሊኑክስ ሲስተም ጥሪዎች መካከል አንዳንድ አስደሳች ንፅፅሮች እዚህ አሉ። እርግጠኛ ነኝ ስለ FUA XFS ማመቻቸት የተማርኩት ለዚህ ቁሳቁስ ምስጋና ይግባው ነበር።

ደህንነቱ በተጠበቀ ሁኔታ በዲስክ ላይ ተከማችቷል ብለው የሚያስቡትን ውሂብ ጠፍተው ያውቃሉ?

ምንጭ: hab.com