გამძლე მონაცემთა შენახვა და Linux ფაილების API

მე, ვიკვლევდი ღრუბლოვან სისტემებში მონაცემთა შენახვის სტაბილურობას, გადავწყვიტე საკუთარი თავის გამოცდა, რათა დავრწმუნდე, რომ მესმის ძირითადი რამ. მე დაიწყო NVMe სპეციფიკაციის წაკითხვით იმისათვის, რომ გავიგოთ, რა გარანტიებს გვაძლევს მონაცემთა მდგრადობასთან დაკავშირებით (ანუ გარანტიები, რომ მონაცემები ხელმისაწვდომი იქნება სისტემის უკმარისობის შემდეგ) გვაძლევს NMVe დისკებს. მე გავაკეთე შემდეგი ძირითადი დასკვნები: თქვენ უნდა გაითვალისწინოთ დაზიანებული მონაცემები მონაცემთა ჩაწერის ბრძანების მიცემის მომენტიდან და სანამ ისინი ჩაწერენ შესანახ საშუალებას. თუმცა, უმეტეს პროგრამებში სისტემური ზარები საკმაოდ უსაფრთხოდ გამოიყენება მონაცემთა ჩასაწერად.

ამ სტატიაში მე ვიკვლევ Linux ფაილის API-ებით მოწოდებულ მდგრადობის მექანიზმებს. როგორც ჩანს, აქ ყველაფერი მარტივი უნდა იყოს: პროგრამა უწოდებს ბრძანებას write()და ამ ბრძანების მოქმედების დასრულების შემდეგ მონაცემები უსაფრთხოდ შეინახება დისკზე. მაგრამ write() მხოლოდ აპლიკაციის მონაცემებს კოპირებს RAM-ში მდებარე ბირთვის ქეშში. იმისათვის, რომ სისტემა აიძულოს დაწეროს მონაცემები დისკზე, უნდა იქნას გამოყენებული დამატებითი მექანიზმები.

ზოგადად, ეს მასალა არის შენიშვნების ერთობლიობა, რომელიც ეხება იმას, რაც ვისწავლე ჩემთვის საინტერესო თემაზე. თუ ძალიან მოკლედ ვისაუბრებთ ყველაზე მნიშვნელოვანზე, გამოდის, რომ მონაცემთა მდგრადი შენახვის ორგანიზებისთვის, თქვენ უნდა გამოიყენოთ ბრძანება fdatasync() ან გახსენით ფაილები დროშით O_DSYNC. თუ გაინტერესებთ მეტი გაიგოთ იმის შესახებ, თუ რა ემართება მონაცემებს კოდიდან დისკამდე მიმავალ გზაზე, გადახედეთ ეს სტატია.

Write() ფუნქციის გამოყენების თავისებურებები

სისტემური ზარი write() სტანდარტში განსაზღვრული IEEE POSIX როგორც ფაილის აღწერისთვის მონაცემების ჩაწერის მცდელობა. სამუშაოს წარმატებით დასრულების შემდეგ write() მონაცემთა წაკითხვის ოპერაციებმა უნდა დააბრუნოს ზუსტად ის ბაიტები, რომლებიც ადრე იყო დაწერილი, მაშინაც კი, თუ მონაცემებზე წვდომა ხდება სხვა პროცესებიდან ან ძაფებიდან (აქ POSIX სტანდარტის შესაბამისი განყოფილება). აქ, ძაფების ურთიერთქმედების განყოფილებაში ჩვეულებრივი ფაილის ოპერაციებთან, არის შენიშვნა, რომელშიც ნათქვამია, რომ თუ ორი ძაფი იძახებს ამ ფუნქციებს, მაშინ თითოეულმა ზარმა ან უნდა ნახოს ყველა მითითებული შედეგი, რომელსაც იწვევს სხვა ზარის შესრულება, ან შედეგს საერთოდ ვერ ვხედავ. ეს მივყავართ დასკვნამდე, რომ ყველა ფაილის I/O ოპერაციას უნდა ჰქონდეს ჩაკეტილი რესურსი, რომელზეც მუშაობს.

ნიშნავს თუ არა ეს ოპერაციას write() ატომურია? ტექნიკური თვალსაზრისით, დიახ. მონაცემების წაკითხვის ოპერაციებმა უნდა დააბრუნოს ყველაფერი ან არცერთი, რომლითაც დაიწერა write(). მაგრამ ოპერაცია write()სტანდარტის შესაბამისად, არ უნდა დასრულდეს, ჩაწერეთ ყველაფერი, რისი ჩაწერასაც სთხოვდნენ. დასაშვებია მონაცემების მხოლოდ ნაწილის ჩაწერა. მაგალითად, ჩვენ შეიძლება გვქონდეს ორი ნაკადი, რომელთაგან თითოეული 1024 ბაიტი ამატებს ფაილს, რომელიც აღწერილია იმავე ფაილის აღწერით. სტანდარტის თვალსაზრისით, შედეგი მისაღები იქნება, როდესაც ჩაწერის თითოეულ ოპერაციას შეუძლია ფაილში მხოლოდ ერთი ბაიტის დამატება. ეს ოპერაციები დარჩება ატომური, მაგრამ მათი დასრულების შემდეგ, ფაილში ჩაწერილი მონაცემები შერეული იქნება. აქ ძალიან საინტერესო დისკუსია ამ თემაზე Stack Overflow-ზე.

fsync() და fdatasync() ფუნქციები

მონაცემთა დისკზე გადატანის უმარტივესი გზა არის ფუნქციის გამოძახება fsync (). ეს ფუნქცია სთხოვს ოპერაციულ სისტემას გადაიტანოს ყველა შეცვლილი ბლოკი ქეშიდან დისკზე. ეს მოიცავს ფაილის ყველა მეტამონაცემებს (წვდომის დრო, ფაილის შეცვლის დრო და ა.შ.). მე მჯერა, რომ ეს მეტამონაცემები იშვიათად არის საჭირო, ასე რომ, თუ იცით, რომ ეს თქვენთვის არ არის მნიშვნელოვანი, შეგიძლიათ გამოიყენოთ ფუნქცია fdatasync(). In დახმარება on fdatasync() მასში ნათქვამია, რომ ამ ფუნქციის მუშაობის დროს, მეტამონაცემების ისეთი რაოდენობა ინახება დისკზე, რაც „აუცილებელია მონაცემთა წაკითხვის შემდეგი ოპერაციების სწორად შესრულებისთვის“. და ეს არის ზუსტად ის, რაც აპლიკაციების უმეტესობას აინტერესებს.

ერთი პრობლემა, რომელიც შეიძლება წარმოიშვას აქ არის ის, რომ ეს მექანიზმები არ იძლევა გარანტიას, რომ ფაილის პოვნა შესაძლებელია შესაძლო წარუმატებლობის შემდეგ. კერძოდ, როდესაც იქმნება ახალი ფაილი, უნდა დარეკოთ fsync() დირექტორიაში, რომელიც შეიცავს მას. წინააღმდეგ შემთხვევაში, ავარიის შემდეგ, შეიძლება აღმოჩნდეს, რომ ეს ფაილი არ არსებობს. ამის მიზეზი ის არის, რომ UNIX-ის პირობებში, მყარი ბმულების გამოყენების გამო, ფაილი შეიძლება არსებობდეს მრავალ დირექტორიაში. ამიტომ დარეკვისას fsync() არ არსებობს საშუალება, რომ ფაილმა იცოდეს, რომელი დირექტორიას მონაცემები ასევე უნდა გაირეცხოს დისკზე (აქ შეგიძლიათ მეტი წაიკითხოთ ამის შესახებ). როგორც ჩანს, ext4 ფაილურ სისტემას შეუძლია ავტომატურად ვრცელდება fsync() დირექტორიაში, რომელიც შეიცავს შესაბამის ფაილებს, მაგრამ ეს შეიძლება არ იყოს სხვა ფაილური სისტემების შემთხვევაში.

ეს მექანიზმი შეიძლება განსხვავებულად განხორციელდეს სხვადასხვა ფაილურ სისტემაში. მე გამოვიყენე blktrace გაიგოთ რა დისკის ოპერაციები გამოიყენება ext4 და XFS ფაილურ სისტემებში. ორივე გასცემს ჩვეულებრივ ჩაწერის ბრძანებებს დისკზე როგორც ფაილების შიგთავსისთვის, ასევე ფაილური სისტემის ჟურნალისთვის, ასუფთავებს ქეშს და გამოდის ჟურნალში FUA (Force Unit Access, მონაცემების პირდაპირ დისკზე ჩაწერა, ქეშის გვერდის ავლით) ჩაწერის შესრულებით. ისინი ალბათ ამას აკეთებენ იმისთვის, რომ დაადასტურონ გარიგების ფაქტი. დისკებზე, რომლებსაც არ აქვთ FUA-ს მხარდაჭერა, ეს იწვევს ქეშის ორ გამორთვას. ჩემმა ექსპერიმენტებმა აჩვენა ეს fdatasync() ცოტა უფრო სწრაფად fsync(). კომუნალური blktrace მიუთითებს იმაზე fdatasync() ჩვეულებრივ წერს ნაკლებ მონაცემს დისკზე (ext4 fsync() წერს 20 KiB და fdatasync() - 16 KiB). ასევე, გავარკვიე, რომ XFS ოდნავ უფრო სწრაფია ვიდრე ext4. და აქ დახმარებით blktrace ამის გარკვევა შეძლო fdatasync() აფრქვევს ნაკლებ მონაცემს დისკზე (4 KiB XFS-ში).

ორაზროვანი სიტუაციები fsync() გამოყენებისას

მე შემიძლია ვიფიქრო სამ ორაზროვან სიტუაციაზე fsync()რაც პრაქტიკაში შემხვედრია.

პირველი ასეთი შემთხვევა 2008 წელს მოხდა. იმ დროს, Firefox 3-ის ინტერფეისი "გაყინული" იყო, თუ ფაილების დიდი რაოდენობა იწერებოდა დისკზე. პრობლემა ის იყო, რომ ინტერფეისის განხორციელებისას გამოიყენებოდა SQLite მონაცემთა ბაზა მისი მდგომარეობის შესახებ ინფორმაციის შესანახად. ინტერფეისში მომხდარი ყოველი ცვლილების შემდეგ, ფუნქცია გამოიძახებოდა fsync(), რაც იძლევა მონაცემთა სტაბილური შენახვის კარგ გარანტიას. შემდეგ გამოყენებულ ext3 ფაილურ სისტემაში ფუნქცია fsync() გარეცხილია სისტემის ყველა "ბინძური" გვერდის დისკზე და არა მხოლოდ ის, რაც დაკავშირებული იყო შესაბამის ფაილთან. ეს ნიშნავს, რომ Firefox-ში ღილაკზე დაწკაპუნებამ შეიძლება გამოიწვიოს მეგაბაიტების მონაცემების ჩაწერა მაგნიტურ დისკზე, რასაც შეიძლება მრავალი წამი დასჭირდეს. პრობლემის გადაწყვეტა, რამდენადაც მე მივხვდი ამ მასალა, იყო მონაცემთა ბაზასთან მუშაობის გადატანა ასინქრონული ფონის ამოცანებზე. ეს ნიშნავს, რომ Firefox ახორციელებდა შენახვის მდგრადობის უფრო მკაცრ მოთხოვნებს, ვიდრე ეს იყო რეალურად საჭირო და 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 დროშების გამოყენებით

მოდით დავუბრუნდეთ Linux მექანიზმების განხილვას, რომლებიც უზრუნველყოფენ მონაცემთა მუდმივ შენახვას. კერძოდ, საუბარია დროშის გამოყენებაზე O_SYNC ან დროშა O_DSYNC ფაილების გახსნისას სისტემური ზარის გამოყენებით გახსნა (). ამ მიდგომით, მონაცემთა ჩაწერის თითოეული ოპერაცია შესრულებულია ისე, თითქოს ყოველი ბრძანების შემდეგ write() სისტემას ეძლევა, შესაბამისად, ბრძანებები fsync() и fdatasync(). In 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 Linux 5.4/Ubuntu 20.04 სისტემაზე. ეს მიდგომა უფრო ეფექტური უნდა იყოს, რადგან ის წერს მონაცემთა მინიმალურ რაოდენობას დისკზე და იყენებს ერთ ოპერაციას და არა ორს (ქეშის ჩაწერა და ამოღება). ვიპოვე ბმული პატჩი 2018 ბირთვი, რომელიც ახორციელებს ამ მექანიზმს. არსებობს გარკვეული დისკუსია ამ ოპტიმიზაციის სხვა ფაილურ სისტემებზე გამოყენების შესახებ, მაგრამ რამდენადაც მე ვიცი, XFS არის ერთადერთი ფაილური სისტემა, რომელიც მხარს უჭერს მას ჯერჯერობით.

sync_file_range() ფუნქცია

Linux-ს აქვს სისტემური ზარი sync_file_range(), რომელიც საშუალებას გაძლევთ გადმოიტანოთ ფაილის მხოლოდ ნაწილი დისკზე და არა მთელი ფაილი. ეს ზარი იწყებს ასინქრონულ გარეცხვას და არ ელოდება მის დასრულებას. მაგრამ მითითებაში sync_file_range() ნათქვამია, რომ ეს ბრძანება "ძალიან საშიშია". არ არის რეკომენდებული მისი გამოყენება. მახასიათებლები და საფრთხეები sync_file_range() ძალიან კარგად არის აღწერილი ეს მასალა. კერძოდ, ეს ზარი, როგორც ჩანს, იყენებს RocksDB-ს, რათა აკონტროლოს, როდის ასუფთავებს ბირთვი „ბინძურ“ მონაცემებს დისკზე. მაგრამ ამავე დროს იქ, მონაცემთა სტაბილური შენახვის უზრუნველსაყოფად, იგი ასევე გამოიყენება fdatasync(). In კოდი 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() დირექტორიებისთვის. მოკლედ, გამოდის, რომ ეს უნდა გააკეთოთ ახალი ფაილის შექმნისას და ამ რეკომენდაციის მიზეზი არის ის, რომ Linux-ში შეიძლება იყოს ბევრი მითითება იმავე ფაილზე.
• SQL სერვერი Linux-ზე: FUA Internals - აქ არის აღწერა, თუ როგორ ხორციელდება მონაცემთა მუდმივი შენახვა SQL Server-ში Linux პლატფორმაზე. აქ არის რამდენიმე საინტერესო შედარება Windows და Linux სისტემის ზარებს შორის. თითქმის დარწმუნებული ვარ, რომ სწორედ ამ მასალის წყალობით გავიგე XFS-ის FUA ოპტიმიზაციის შესახებ.

ოდესმე დაკარგეთ მონაცემები, რომლებიც ფიქრობდით, რომ უსაფრთხოდ იყო შენახული დისკზე?

წყარო: www.habr.com