Ego, vestigans stabilitatem notitiarum repositionis in systematis nubili, me ipsum probare decrevi, efficere ut fundamentalia intelligam. ego ut intelligamus ea quae cautiones circa notitia perseverantiae (id est, cautiones datae post defectum systematis suppetunt) nobis dant orbes NMVe. Praecipuas conclusiones sequentes feci: debes considerare notitias corruptas a momento datae scribe praeceptum, et usque ad momentum scribentur ad medium repositionis. Pleraque tamen programmata systematis utendi vocat satis feliciter ad data scribenda.
In hoc articulo, mechanismos perseverantiam a Linux fasciculi APIs explorato. Videtur quod omnia hic simplicia sint: progressio mandatum vocat write()et post operationem mandati huius peractam, notitia tuto in disco reponetur. Sed write() tantum exemplaria applicationis data ad cache nuclei in RAM sito. Ut systema ad scribendum notitias orbis cogat, aliquae machinae adiectis utendae sunt.
In genere, haec materia est copia notarum ad ea quae didici de usuris mihi. Si brevissime de praecipuis loquimur, evenit ut notitiarum repositionum sustinendarum ordinetur, imperio uti debes. fdatasync() aut aperta files cum vexillum O_DSYNC. Si plus interesse in discendo quid eveniat notitia in via a codice ad orbis, Vide articulus.
Features utendi scribe () munus
Systema vocationis write() definitur vexillum ut conatus scribere notitia ad lima descriptor. Post perfectionem operis write() lecta opera data prorsus redire debent bytes qui antea scripserant, ita ut etiam si ex aliis processibus vel stamina data sit accessio. correspondentia sectionis vexillum POSIX). , in sectione de commercio staminum cum operationibus fasciculi normalibus, notandum est quod si duo fila singula haec functiones vocent, singulae vocationes debent vel videre omnes consequentias indicatas quas alterius vocationis executio ducit ad vel. omnino nullas consequatur. Hinc ad conclusionem omnes fasciculi I/O operationes debent crinem tenere in subsidiis operando.
Hoc est quod operatio? write() est nuclei? Ex technica parte, est. Data lege operationes reddere debent vel omnia vel nulla quae scripta sunt write(). Sed operatio write()iuxta mensuram, finem non habet, conscribendo omnia quae rogata sunt scribere. Pars notitia tantum scribere licet. Exempli gratia, habeamus duos rivos singulas appendentes 1024 bytes ad limam ab eodem fasciculo descriptom descriptos. Ex parte vexillum, id gratum erit, cum singulae operationes scribendae una tantum tabulae byte apponere possunt. Hae operationes atomicae manebunt, sed postquam perficiunt, notitia quae scripserint in tabella mittenda erit. valde interesting disputatio de hoc argumento in Stack Overflow.
fsync () et fdatasync () functiones
Facillima via est ad ruborem data orbis vocare munus . Hoc munus systematis operantis rogat ut omnes caudices modificatos e cella in disco moveat. Haec omnia metadata tabella includit (tempus accessum, tempus modificationis fasciculi, et sic porro). Hanc metadatam coniecturam raro opus esse suspicor, si scias te non magni momenti esse, functione uti potes fdatasync(). Quod on fdatasync() dicit, durante operatione huius functionis, tanta metadatae moles ad disci servatam esse, quae "necesse est ad rectam executionem operationum lectionis sequentis notitiae". Atque hoc ipsum est quod maxime curant applicationes.
Una quaestio quae hic oriri potest est has machinationes non spondere tabellam post defectum possibilem inveniri posse. Praesertim, cum novum fasciculum creando, vocare debes fsync() pro presul continente. Alioquin, post fragorem, eveniat ut haec fasciculus non sit. Cuius ratio est quia in UNIX, ob nexus durorum adhibitis, fasciculus in pluribus directoriis exsistere potest. Ideo cum vocatione fsync() nulla via est ad cognoscendum utra notitia directorium subnixa etiam ad disci ( Plura de hoc legere potes). Is vultus sicut ratio lima ext4 capax est adhibere fsync() ad directoria continens imaginum correspondentium, sed hoc fieri non potest cum aliis systematibus fasciculi.
Haec mechanismus aliter in diversis systematibus fasciculi impleri potest. ego cognoscere quid orbis operationes in ext4 et XFS systemata fasciculi adhibeantur. Utrumque usitatum scribere mandata disci pro utraque contenta scriptionis et ephemeride systematis, rubenti cella et exitum faciendo a FUA (Force Unit Obvius, scribens data directo ad disco, praeteriens cache) ephemeride scribe. Verisimiliter faciunt id ad rem gestam confirmandam. In agitet quod FUA non sustinet, haec duo cache rubet facit. Experimenta mea demonstravimus fdatasync() paulum citius fsync(). utilitas blktrace indicat fdatasync() plerumque scribit minus notitia ad disci (in ext4 fsync() scribit XX KiB et fdatasync() β 16 KiB). Etiam inveni XFS paulo velocius quam ext4. Et hic cum auxilio blktrace poterat invenire quod fdatasync() minus rubet disco notitia (IV KiB in XFS).
Ambigua res cum usura fsync ()
De tribus ambiguis condicionibus cogitare possum fsync()quae ego in usu.
Primus casus talis anno 2008 evenit. Eo tempore, Firefox 3 interface "gelida" si numerus fasciculorum scribebantur in disco. Problema erat quod exsecutio instrumenti SQLite datorum usus est ut informationes de suo statu reponeret. Post singulas vicissitudines quae in instrumento facta sunt, munus vocatum est fsync()quae bona cautiones stabilis notitia repono. In ratio lima ext3 tunc usus est, munus fsync() rubentes omnes paginas "sordida" in systematis disco, et non solum ea quae ad file respondentem referebantur. Hoc significabat puga pyga in Firefox facere megabytas notitiarum megabytarum scribendorum ad disci magneticum, quod multa secundis capere potuit. Solutio problema, quod intellexi materia erat, opus cum datorum ad asynchronum in scaena opera movendum erat. Hoc significat quod Firefox usus est ad repositionis pervicaciae strictius ad efficiendum requisita quam vere opus erat, et lineamenta filesystem extera solum hoc problema exacerbant.
Secunda quaestio anno 2009 accidit. Deinde, post fragorem systematis, usores novi systematis fasciculi ext4 invenerunt multos files nuper creatos nulla longitudo esse, sed hoc non evenit cum systematis fasciculi ext3 vetustioribus. In paragrapho praecedente, locutus sum quomodo ext3 nimis proiecerat notitias in orbe, quae res multum retardavit. fsync(). Ad meliorem statum ext4 solum illae paginae sordidae quae ad fasciculum particulare pertinentes rubescunt in disco. Et notitia ex aliis fasciculis manet in memoria multo diutius quam cum ext3. Hoc factum est ut melioris effectus (per default, notitia in hoc statu remanet pro 30 secundis, hunc utens configurare potes ; plura de hoc reperire potes). Hoc significat magnam copiam notitiarum irrevocabiliter post ruinam amitti posse. Solutio huius problematis est utendum fsync() in applicationibus quae reposita stabilia notitiarum stabilium praebere debent easque quam maxime ab insequentibus defectibus tueantur. Officium fsync() multo efficacius cum ext4 than with ext3. Incommodum accessionis est quod usus eius, sicut prius, exsecutionem aliquarum operationum retardat, sicut programmata inaugurari. Vide singula in hoc ΠΈ .
Tertia quaestio de fsync()editae MMXVIII. Tum, intra ambitum propositi PostgreSQL, deprehensum est si munus fsync() Error incurrit, paginas "sordidas" ut "mundas" notat. Quam ob rem haec vocat fsync() nihil cum talibus paginis. Propter hoc, paginae mutatae in memoria repositae sunt et numquam in disco scriptae. Haec clades vera est, quia applicatio aliqua data scriptioni disco scripta putabit, re vera non erit. Haec defectis fsync() rara sunt, applicatio in eiusmodi rerum adiunctis nihil fere potest ad quaestionem pugnare. Haec dies, cum hoc incidit, PostgreSQL aliaque medicamenta fragorem faciunt. in articulo "An Applications de defectibus fsync" Recuperare?", haec quaestio singillatim exploratur. In statu optima solutionis huius problematis utatur Direct I/O cum vexillo O_SYNC aut cum vexillum O_DSYNC. Cum hoc aditu, systema errores referet qui in certis operationibus scribentibus accidere possunt, sed hic accessus postulat applicationem ad se buffers regendi. Read more about it ΠΈ .
Documenta aperiens utens O_SYNC et O_DSYNC vexillis
Redeamus ad disputationem de machinationibus Linux quae notitias repositiones persistentes praebent. Nempe de vexillo loquimur O_SYNC aut vexillum O_DSYNC Cum foramen lima utendi ratio vocationis . Cum hoc accessu, singulae notitiae scribendae operandi causa exercentur quasi post unumquodque mandatum write() ratio datur, respective imperat fsync() ΠΈ fdatasync(). Quod hoc appellatur " Synchronised I/O File Integrity Perfectio" et "Integritas Perfectio". Praecipua utilitas huius accessionis est quod una tantum ratio vocationis necessitates exsecutioni mandandi dat integritatem, et non duo (exempli gratia write() ΠΈ fdatasync()). Praecipuum huius accessionis incommodum est quod omnes scribentes operationes utentes tabella descriptorum respondente synchronisedantur, quae facultatem ad schedula applicandi codicem circumscribere possunt.
Direct I/O cum O_DIRECT vexillum
Systema vocationis open() sustinet vexillum O_DIRECTquae destinatur praeterire cella operativam, operationes I/O, directe cum orbe interacting praestare. Hoc, multis in casibus, significat scribere mandata edita a programmatis directo transferri in mandata quae ad operandum cum disco. Sed in genere haec mechanismus ad functiones substitutio non est fsync() aut fdatasync(). Ita est quod disco ipsum correspondentes mandata scripto data. Et etiam peius in quibusdam casibus specialibus operationes exercentur I / o cum vexillo utendo O_DIRECT, in traditionalem buffered operationem. Facillime modus hanc quaestionem solvendi est ut vexillum ad lima aperta utatur O_DSYNC, quod unumquodque scribet operationem, sequetur vocatio fdatasync().
Evenit ut systema fasciculi XFS nuper "vel celeriter iter" addidisset O_DIRECT|O_DSYNCβdata monumentis. Si obstructionum est overwritten usus O_DIRECT|O_DSYNCergo XFS, pro rutilante cella, FUA scribam mandatum faciet, si fabrica id sustineat. Ego verificatur hoc per utilitatem blktrace in a Linux 5.4/Ubuntu 20.04 systema. Accessus hic efficacior esse debet, cum minimam copiam notitiarum orbis scribit et una operatione utitur, non duo (scribe ac rubore cache). Inveni vinculum to 2018 nucleus qui hanc machinam conficit. Disceptatio quaedam est de applicando hanc optimam ad alia systemata fasciculi, sed, ut sciam, XFS ratio fasciculi unica est, quae hoc modo sustinet.
sync_file_range() munus
Linux est ratio vocationis quae permittit ut rubeat tantum pars tabellae discri, quam totum fasciculum. Haec vocatio asynchronam datam ruborem inchoat et eam perficere non expectat. Sed in certificatorium sync_file_range() Hoc mandatum dicitur esse periculosum. Suspendisse non dictum tortor. Features et pericula sync_file_range() optime descriptus est materiam. Peculiariter haec vocatio videtur uti RocksDB ad refrenandum cum nucleus notitiarum orbis "sordida" rubet. Simul autem ibi, ut notitia repono stabilis, etiam adhibetur fdatasync(). Quod RocksDB de hoc argumento nonnulla commenta iucunda habet. Videtur quod vocatio exempli sync_file_range() Cum ZFS utens, notitia ad disci non solet. Usus mihi narrat raro codicem adhibitum esse cimices continere. Quapropter ego contra hanc rationem vocationis utendo monerem nisi absolute necessarium.
Systema vocat ad auxilium ut notitia perseverantia
Ad conclusionem venio tres aditus esse qui assidue I/O operationes exercere possunt. Omnes munus vocationis fsync() ad indicem in quo tabella creata est. Hi aditus;
- Munus vocationis
fdatasync()autfsync()post munuswrite()(Melius utorfdatasync()). - Operantes cum descriptor lima vexillum cum aperuit
O_DSYNCautO_SYNC(Melius - cum vexillumO_DSYNC). - Imperium usus
pwritev2()cum vexillumRWF_DSYNCautRWF_SYNC(Potius cum vexillumRWF_DSYNC).
Praecipua euismod
Variis machinationibus quas indagavi exercendis diligenter metiebam. Differentiae quas notavi in ββvelocitate operis sui valde parvae sunt. Hoc significat me falli posse, et in aliis conditionibus idem diversimode ostendere. Prius dicam de iis quae ad rem faciendam magis pertinent, deinde de iis quae ad effectum minus pertinent.
- Data fasciculi overwriting velocior est quam ad tabellam appensione data (lucrum perficiendi potest esse 2-100%). Figens notitias ad fasciculum requirit additos mutationes metadatae tabellae, etiam postquam ratio vocationis
fallocate()sed variari hujus rei magnitudo. Commendo, ad optimam observantiam vocarefallocate()praeexistere placeat requiritur spatium. Tunc hoc spatium phiris zephyris expresse replendum est et vocaturfsync(). Hoc faciet stipites correspondentes in systematis tabellae loco "dispositae" notandi. Hoc dat parvam (circa 2%) emendationem perficiendi. Etiam, nonnulli orbes primum impedimentum accessum operationis tardiorem habere possunt quam alii. Id significat quod spatium cum cyphras implens ad emendationem significantem (circiter 100%) ducere potest. Hoc imprimis fieri potest cum orbis. (hoc est privata notitia, ea confirmare non potui). Idem valet de repono. (quod iam officialis notitiae probatis confirmatae sunt). Alii periti idem fecerunt ad diversas orbis. - Systema pauciores vocat, quo superiores effectus sunt (quaestus circa 5%) potest esse. Videtur provocatione
open()cum vexillumO_DSYNCaut vocationispwritev2()cum vexillumRWF_SYNCcitius vocatiofdatasync(). Suspicor hic punctum esse cum hac accessione, quod pauciores vocat ratio ad idem opus solvendum (una voce pro duobus) partes agere. Sed differentia perficientur minima est, ut facile eam ignorare possis et aliquo usu uti in applicatione quae non ducit ad complicationem suae logicae.
Si interest in themate notitiarum repositionis sustineri, hic sunt nonnullae materiae utiles;
- - inspectio fundamentalum input / output machinationes.
- - Narratio de iis quae fiunt in notitia in via ab applicatione ad orbis.
- - responsum ad quaestionem de qua applicatur
fsync()pro directoriis. In nuce evenit ut hoc facere debes cum novum fasciculum creando, et causa huius commendationis est quod in Linux multae ad idem fasciculi possunt esse. - - Hic descriptio est quam constans notitia repono in SQL Servo in suggestu Linux perficiatur. Comparationes inter Fenestra et Linux hic vocat nonnullas interesting. Pro certo sum prope hanc materiam gratias agere quod de FUA optimizationi XFS didici.
Amisisti notitia quam putabatis in orbe conditum esse secure?
Source: www.habr.com