Kas Linux lubab voolukatkestuse korral järjestikuste failide kirjutamist?

Failide kirjutamise vastupidavuse mõistmine voolukatkestuse ajal

Kujutage ette, et kirjutate faili kaks olulist andmeosa ja äkki katkeb toide. Kas Linux või teie valitud failisüsteem tagab, et teie teist kirjutamist ei ilmu salvestusruumi enne, kui esimene on lõpetatud? Paljud arendajad jätavad selle küsimuse tähelepanuta, kuni katastroof saabub. 🛑

Failide vastupidavus on andmete terviklikkuse käsitlemisel ülioluline, eriti voolukatkestuse või krahhi korral. See küsimus muutub veelgi pakilisemaks, kui töötate POSIX-ühilduvate süsteemide või levinud failisüsteemidega, nagu ext4. Kas kirjutised on tagatud järjestikused ja aatomipõhised või vajate täiendavaid ettevaatusabinõusid?

Näiteks kaaluge suurt rakendust, mis kirjutab logid või struktureeritud andmed faili kahes mittekattuvas osas. Ilma selgete garantiideta on oht, et osa teisest kirjutisest hiilib kettale, jättes faili ebajärjekindlasse olekusse. See võib põhjustada andmebaaside rikkumist, tehingute kadumist või mittetäielikke kirjeid. 😓

Selles artiklis uuritakse, kas POSIX, Linux või kaasaegsed failisüsteemid (nt ext4) tagavad faili kirjutamise vastupidavuse ja järjestuse. Samuti otsustame, kas fsync() või fdatasync() kasutamine kirjutamiste vahel on ainus usaldusväärne lahendus andmete vastuolude vältimiseks.

Failide kirjutamise vastupidavuse mõistmine ja andmete järjepidevuse tagamine

Varem esitatud skriptides käsitlesime vastupidavusgarantiide probleemi Linuxi failikirjutustes ootamatute sündmuste (nt voolukatkestuste) korral. Keskenduti sellele, et teine ​​andmeplokk andmed2, ei säiliks salvestamisel, välja arvatud juhul, kui esimene plokk, andmed1, oli juba täielikult kirjutatud. Lahendus põhines hoolikalt valitud süsteemikutsete kombinatsioonil, näiteks pwrite ja fsyncja failisüsteemi käitumist. Esimene kasutatud skript fsync kahe järjestikuse kirjutamise vahel tagamaks, et andmed1 loputatakse kettale enne andmete2 kirjutamise jätkamist. See tagab andmete terviklikkuse, isegi kui süsteem jookseb kokku pärast esimest kirjutamist.

Jaotame selle edasi: pwrite funktsioon kirjutab failis määratud nihkele ilma failikursorit muutmata. See on eriti kasulik mittekattuvate kirjutamiste puhul, nagu siin näidatud, kus kaks andmeplokki kirjutatakse erinevate nihetega. Kasutades selgesõnaliselt fsync pärast esimest kirjutamist sunnime operatsioonisüsteemi faili puhverdatud sisu kettale loputama, tagades püsivuse. Ilma fsyncita võivad andmed jääda mällu, mis on voolukatkestuse korral haavatav. Kujutage ette kriitilise logikirje kirjutamist või andmebaasi osa salvestamist – kui esimene osa kaob, muutuvad andmed ebajärjekindlaks. 😓

Teises skriptis uurisime selle kasutamist O_SYNC lipp avatud süsteemikõne. Kui see lipp on lubatud, loputab iga kirjutamistoiming andmed koheselt salvestusruumi, eemaldades vajaduse käsitsi salvestada fsync kõned. See lihtsustab koodi, tagades samas vastupidavuse garantii. Siiski on kompromiss: O_SYNC kasutamine toob kaasa jõudlustrahvi, kuna sünkroonkirjutamine võtab puhverdatud kirjutamisega võrreldes kauem aega. See lähenemine sobib ideaalselt süsteemidele, mille töökindlus kaalub üles jõudlusega seotud probleemid, nagu finantssüsteemid või reaalajas andmete logimine. Näiteks kui salvestate andurite andmeid või tehinguloge, peavad kõik kirjutised olema täiesti usaldusväärsed. 🚀

Pythonis kirjutatud üksuse testskript kinnitas need lahendused, kontrollides pärast C-programmi käivitamist faili sisu. See tagas, et nii andmed1 kui ka andmed2 kirjutati ootuspäraselt. See samm rõhutab failitoimingute testimise tähtsust erinevates tingimustes. Kui juurutaksite sarnase lahenduse tootmisserveris, oleks üksusetestid teie kirjutiste terviklikkuse kontrollimisel kriitilise tähtsusega. Kombineerides tugevad kodeerimistavad, nagu fsynci kasutamine testide kaudu valideerimisega, saate kindlalt tagada oma failide kirjutamise vastupidavuse ja järjepidevuse POSIX-iga ühilduvates süsteemides.

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
int main() {
    int fd;
    const char *path = "example_file.txt";
    const char *data1 = "First write block";
    const char *data2 = "Second write block";
    size_t size1 = strlen(data1);
    size_t size2 = strlen(data2);
    off_t offset1 = 0;
    off_t offset2 = size1;

    // Open the file
    fd = open(path, O_RDWR | O_CREAT, 0666);
    if (fd == -1) {
        perror("Failed to open file");
        return 1;
    }

    // Perform first write
    if (pwrite(fd, data1, size1, offset1) == -1) {
        perror("Failed to write data1");
        close(fd);
        return 1;
    }

    // Use fsync to flush the first write to disk
    if (fsync(fd) == -1) {
        perror("fsync failed after data1");
        close(fd);
        return 1;
    }

    // Perform second write
    if (pwrite(fd, data2, size2, offset2) == -1) {
        perror("Failed to write data2");
        close(fd);
        return 1;
    }

    // Final fsync to ensure data2 is flushed
    if (fsync(fd) == -1) {
        perror("fsync failed after data2");
        close(fd);
        return 1;
    }

    // Close the file
    if (close(fd) == -1) {
        perror("Failed to close file");
        return 1;
    }

    printf("Writes completed and synced successfully.\n");
    return 0;
}

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
int main() {
    int fd;
    const char *path = "simple_ordered_file.txt";
    const char *data1 = "Data block 1";
    const char *data2 = "Data block 2";
    size_t size1 = strlen(data1);
    size_t size2 = strlen(data2);

    // Open file with O_SYNC for synchronous writes
    fd = open(path, O_RDWR | O_CREAT | O_SYNC, 0666);
    if (fd == -1) {
        perror("Open failed");
        return 1;
    }

    // Write first data
    if (write(fd, data1, size1) == -1) {
        perror("Write data1 failed");
        close(fd);
        return 1;
    }

    // Write second data
    if (write(fd, data2, size2) == -1) {
        perror("Write data2 failed");
        close(fd);
        return 1;
    }

    // Close file
    close(fd);
    printf("Writes completed with O_SYNC.\n");
    return 0;
}

import os
def validate_file_content(path):
    try:
        with open(path, 'r') as f:
            content = f.read()
        assert "Data block 1" in content
        assert "Data block 2" in content
        print("Test passed: Both writes are present.")
    except AssertionError:
        print("Test failed: Writes are inconsistent.")
    except Exception as e:
        print(f"Error: {e}")

# File validation after running a C program
validate_file_content("simple_ordered_file.txt")

Andmete järjepidevuse tagamine Linuxis: päevik ja puhverdatud kirjutised

Üks mõistmise kriitiline aspekt vastupidavuse garantiid Linuxi failisüsteemides, nagu ext4, on ajakirjade roll. Päevikusüsteemid aitavad vältida riknemist ootamatute sündmuste (nt voolukatkestuste) ajal, pidades muudatuste logi (või päevikut) enne nende põhimällu sidumist. Päevik tagab mittetäielike toimingute tagasipööramise, hoides teie andmed järjepidevana. Päeviku pidamine ei taga aga olemuselt tellitud kirjutamist ilma täiendavate ettevaatusabinõudeta, nagu helistamine fsync. Meie näites võib päeviku pidamine tagada, et fail ei rikuta, kuid selle osad andmed2 võiks ikka enne püsida andmed1.

Teine kaalutlus on see, kuidas Linux puhverdab faili. Kui kasutate pwrite või write, kirjutatakse andmed sageli mälupuhvrisse, mitte otse kettale. See puhverdamine parandab jõudlust, kuid loob andmete kadumise ohu, kui süsteem jookseb kokku enne puhvri tühjendamist. Helistamine fsync või faili avamine nupuga O_SYNC lipp tagab puhverdatud andmete ohutu kettale loputamise, vältides vastuolusid. Ilma nende meetmeteta võivad andmed olla osaliselt kirjutatud, eriti voolukatkestuse korral. ⚡

Suurte failide või kriitiliste süsteemidega töötavate arendajate jaoks on oluline kavandada programme, pidades silmas vastupidavust. Kujutage ette näiteks lennufirma broneerimissüsteemi, mis kirjutab istekohtade saadavuse andmeid. Kui esimene plokk, mis näitab lennu üksikasju, pole täielikult kirjutatud ja teine ​​plokk püsib, võib see põhjustada andmete rikkumist või topeltbroneeringuid. Kasutades fsync või fdatasync kriitilistes etappides väldib neid lõkse. Usaldusväärsuse tagamiseks testige käitumist alati reaalsete rikete simulatsioonidega. 😊