{"id":98090,"date":"2020-10-24T02:42:38","date_gmt":"2020-10-24T00:42:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux"},"modified":"2020-11-18T00:58:48","modified_gmt":"2020-11-17T22:58:48","slug":"ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ustojchivoe-hranenie-dannyh-i-fajlovye-api-linux","title":{"rendered":"Archiviazione sicura dei dati e API di file in Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mentre esploravo la resilienza dello storage nei sistemi cloud, ho deciso di mettermi alla prova per assicurarmi di comprendere i concetti di base. Ho iniziato a leggere la specifica NVMe<\/a><\/noindex> per capire quali garanzie riguardanti la resilienza dello storage (cio\u00e8 le garanzie che i dati saranno accessibili dopo un guasto del sistema) ci forniscono i dischi NVMe. Ho tratto le seguenti conclusioni principali: si deve considerare che i dati sono danneggiati dal momento in cui viene emesso il comando di scrittura fino a quando la scrittura non \u00e8 completata sul supporto. Tuttavia, nella maggior parte dei programmi di scrittura, si utilizzano tranquillamente le chiamate di sistema.<\/p>\n

In questo articolo esaminer\u00f2 i meccanismi di resilienza dello storage forniti dalle API file di Linux. Sembra che qui tutto dovrebbe essere semplice: il programma chiama il comando write()<\/code>, e dopo che questo comando \u00e8 stato completato, i dati dovrebbero essere salvati in modo sicuro sul disco. Ma write()<\/code> copier\u00e0 solo i dati dell'applicazione nella cache del kernel, situata nella memoria. Per forzare il sistema a scrivere i dati sul disco, \u00e8 necessario utilizzare alcuni meccanismi aggiuntivi.<\/p>\n

\"Archiviazione<\/a><\/noindex><\/p>\n

In generale, questo materiale \u00e8 un insieme di appunti che riguardano ci\u00f2 che ho appreso sull'argomento che mi interessa. Se dobbiamo sintetizzare le informazioni pi\u00f9 importanti, si pu\u00f2 dire che per organizzare uno storage dati sostenibile \u00e8 necessario utilizzare il comando fdatasync()<\/code> o aprire i file con il flag O_DSYNC<\/code>. Se siete interessati a conoscere i dettagli su cosa succede ai dati durante il passaggio dal codice sorgente al disco, date un'occhiata a questo<\/a><\/noindex> articolo.
\n<\/a><\/noindex><\/p>\n

Le caratteristiche dell'uso della funzione write()<\/h2>\n

\nChiamata di sistema write()<\/code> sono definite nello standard IEEE POSIX<\/a><\/noindex> come un tentativo di scrivere dati in un descrittore di file. Dopo il completamento riuscito write()<\/code> le operazioni di lettura dei dati devono restituire esattamente i byte che sono stati precedentemente scritti, anche se i dati vengono acceduti da altri processi o thread (ecco<\/a><\/noindex> la sezione corrispondente dello standard POSIX). Qui<\/a><\/noindex>, nella sezione dedicata all'interazione dei thread con le normali operazioni sui file, c'\u00e8 una nota che afferma che se ciascuno dei due thread chiama queste funzioni, ogni chiamata deve vedere o tutte le conseguenze designate che derivano dall'esecuzione dell'altra chiamata, oppure non vedere affatto conseguenze. Questo porta a concludere che tutte le operazioni di input\/output su file devono trattenere il blocco della risorsa con cui stanno lavorando.<\/p>\n

Significa che l'operazione write()<\/code> \u00e8 atomica? Dal punto di vista tecnico \u2014 s\u00ec. Le operazioni di lettura dei dati devono restituire o tutto, o niente di quanto \u00e8 stato scritto con write()<\/code>. Ma l'operazione write()<\/code>, in conformit\u00e0 con lo standard, non \u00e8 necessario che si completi, registrando tutto ci\u00f2 che le \u00e8 stato proposto di registrare. Le \u00e8 consentito registrare solo una parte dei dati. Ad esempio, potremmo avere due flussi, ciascuno dei quali aggiunge 1024 byte a un file descritto dallo stesso descrittore di file. Dal punto di vista dello standard, si considererebbe accettabile il risultato in cui ciascuna delle operazioni di scrittura pu\u00f2 aggiungere solo un byte al file. Queste operazioni rimarranno atomiche, ma dopo il loro completamento, i dati scritti nel file risulteranno mescolati. Ecco<\/a><\/noindex> c'\u00e8 una discussione molto interessante su questo argomento su Stack Overflow.<\/p>\n

Le funzioni fsync() e fdatasync()<\/h2>\n

\nIl modo pi\u00f9 semplice per forzare la scrittura dei dati su disco \u00e8 chiamare la funzione fsync()<\/a><\/noindex>. Questa funzione richiede al sistema operativo di trasferire tutti i blocchi modificati dalla cache al disco. Ci\u00f2 include anche tutti i metadati del file (tempo di accesso, tempo di modifica del file e cos\u00ec via). Credo che la necessit\u00e0 di questi metadati sorga raramente, quindi, se sai che non sono importanti per te, puoi utilizzare la funzione fdatasync()<\/code>. In documentazione<\/a><\/noindex> per fdatasync()<\/code> Si dice che durante l'esecuzione di questa funzione venga salvato su disco un volume di metadati \u00abnecessario per l'esecuzione corretta delle operazioni di lettura dei dati successive\u00bb. E questo \u00e8 proprio ci\u00f2 che preoccupa la maggior parte delle applicazioni.<\/p>\n

Uno dei problemi che potrebbe sorgere qui \u00e8 che questi meccanismi non garantiscono che il file sar\u00e0 recuperabile dopo un possibile guasto. In particolare, quando si crea un nuovo file, \u00e8 necessario chiamare fsync()<\/code> per la directory che lo contiene. Altrimenti, dopo un guasto, potrebbe risultare che quel file non esiste. La ragione \u00e8 che in UNIX, a causa dell'uso dei collegamenti rigidi, un file pu\u00f2 esistere in pi\u00f9 directory. Pertanto, al momento della chiamata fsync()<\/code> per il file non c'\u00e8 modo di sapere quali dati di quale directory devono essere scritti su disco (qui<\/a><\/noindex> puoi leggere di pi\u00f9 a riguardo). Sembra che il file system ext4 sia in grado di automaticamente<\/a><\/noindex> applicare fsync()<\/code> alle directory che contengono i file appropriati, ma nel caso di altri file system questo potrebbe non essere cos\u00ec.<\/p>\n

Questo meccanismo pu\u00f2 essere implementato in vari modi nei diversi file system. Ho utilizzato blktrace<\/a><\/noindex> per scoprire quali operazioni di disco vengono utilizzate nei file system ext4 e XFS. Entrambi emettono comuni comandi di scrittura su disco sia per il contenuto dei file che per il registro del file system, svuotano la cache e terminano l'operazione eseguendo la scrittura FUA (Force Unit Access, scrittura dei dati direttamente sul disco, saltando la cache) nel registro. Probabilmente, adottano questo approccio per confermare che l'operazione \u00e8 stata effettuata. Su dischi che non supportano FUA, ci\u00f2 provoca due svuotamenti della cache. I miei esperimenti hanno dimostrato che fdatasync()<\/code> \u00e8 leggermente pi\u00f9 veloce fsync()<\/code>. Strumento blktrace<\/code> indica che fdatasync()<\/code> di solito scrive meno dati sul disco (in ext4 fsync()<\/code> scrive 20 KiB, mentre fdatasync()<\/code> scrive 16 KiB). Inoltre, ho scoperto che XFS \u00e8 leggermente pi\u00f9 veloce di ext4. E qui con l'aiuto di blktrace<\/code> sono riuscito a scoprire che fdatasync()<\/code> svuota sul disco meno dati (4 KiB in XFS).<\/p>\n

Situazioni ambigue che si presentano quando si utilizza fsync()<\/h2>\n

\nPosso ricordare tre situazioni ambigue riguardanti fsync()<\/code>, con cui mi sono confrontato nella pratica.<\/p>\n

Il primo caso di questo tipo si \u00e8 verificato nel 2008. Allora, l'interfaccia di Firefox 3 si bloccava quando si tentava di scrivere su disco un grande numero di file. Il problema era che nella realizzazione dell'interfaccia per memorizzare le informazioni sul suo stato veniva utilizzato un database SQLite. Dopo ogni modifica apportata all'interfaccia, veniva chiamata la funzione fsync()<\/code>, che garantiva buone garanzie di memorizzazione dei dati. Nella filesystem utilizzata allora, ext3, la funzione fsync()<\/code> scriveva su disco tutte le pagine \"sporche\" nel sistema, non solo quelle relative al file specifico. Questo significava che un clic su un pulsante in Firefox poteva avviare la registrazione di megabyte di dati su disco rigido, richiedendo molti secondi. La soluzione al problema, da quanto ho compreso da questo<\/a><\/noindex> materiale, consisteva nel trasferire il lavoro con il database in attivit\u00e0 di sfondo asincrone. Questo significa che prima in Firefox erano implementati requisiti pi\u00f9 severi per la robustezza della memorizzazione dei dati di quanto fosse realmente necessario, e le peculiarit\u00e0 del filesystem ext3 aggravavano ulteriormente questo problema.<\/p>\n

Il secondo malfunzionamento si \u00e8 verificato nel 2009. Allora, dopo un guasto del sistema, gli utenti del nuovo file system ext4 si sono trovati di fronte a file recentemente creati che avevano una lunghezza pari a zero, mentre con il pi\u00f9 vecchio file system ext3 questo non \u00e8 accaduto. Nel paragrafo precedente, ho accennato al fatto che ext3 scriveva su disco troppi dati, il che rallentava notevolmente l'operazione. fsync()<\/code>. Per migliorare la situazione, in ext4 vengono scritte su disco solo le pagine \"sporche\" relative a un file specifico. I dati degli altri file rimangono in memoria per un tempo molto pi\u00f9 lungo rispetto a quanto avviene con ext3. Questo \u00e8 stato realizzato per migliorare le prestazioni (di default i dati rimangono in questo stato per 30 secondi, questo pu\u00f2 essere configurato tramite dirty_expire_centisecs<\/a><\/noindex>; qui<\/a><\/noindex> \u00e8 possibile trovare ulteriori materiali a riguardo). Questo significa che un grande volume di dati pu\u00f2 andare irrimediabilmente perso dopo un guasto. La soluzione a questo problema consiste nell'utilizzo di fsync()<\/code> in applicazioni che necessitano di garantire una memorizzazione dati sicura e massimizzare la protezione da eventuali malfunzionamenti. La funzione fsync()<\/code> funziona con ext4 in modo molto pi\u00f9 efficiente rispetto a ext3. Lo svantaggio di questo approccio \u00e8 che, come prima, rallenta l'esecuzione di alcune operazioni, come l'installazione di programmi. Maggiori dettagli su questo si trovano qui<\/a><\/noindex> e qui<\/a><\/noindex>.<\/p>\n

Il terzo problema riguarda fsync()<\/code>, emerso nel 2018. Allora, nell'ambito del progetto PostgreSQL, si \u00e8 scoperto che se la funzione fsync()<\/code> incorre in un errore, contrassegna le pagine 'sporche' come 'pulite'. Di conseguenza, le chiamate successive fsync()<\/code> non fanno nulla con queste pagine. Questo comporta che le pagine modificate rimangano in memoria e non vengano mai scritte su disco. \u00c8 una vera e propria catastrofe, poich\u00e9 l'applicazione riterr\u00e0 che alcuni dati siano stati scritti su disco, mentre in realt\u00e0 non \u00e8 cos\u00ec. Tali guasti fsync()<\/code> sono rari, e l'applicazione in tali situazioni pu\u00f2 fare poco per combattere il problema. Oggigiorno, quando ci\u00f2 avviene, PostgreSQL e altre applicazioni terminano in modo anomalo. Qui<\/a><\/noindex>, nel materiale 'Can Applications Recover from fsync Failures?', questo problema viene approfondito in tutti i dettagli. Attualmente, la migliore soluzione a questo problema \u00e8 utilizzare Direct I\/O con il flag O_SYNC<\/code> o con il flag O_DSYNC<\/code>. Con questo approccio, il sistema segnaler\u00e0 eventuali errori che possono verificarsi durante specifiche operazioni di scrittura dei dati, ma richiede che l'applicazione gestisca autonomamente i buffer. Maggiori dettagli su questo possono essere trovati qui<\/a><\/noindex> e qui<\/a><\/noindex>.<\/p>\n

Apertura di file usando i flag O_SYNC e O_DSYNC<\/h2>\n

\nTorniamo a discutere dei meccanismi Linux che garantiscono la persistenza dei dati. In particolare, stiamo parlando dell'uso del flag O_SYNC<\/code> o del flag O_DSYNC<\/code> quando si apre file utilizzando la chiamata di sistema open()<\/a><\/noindex>. Con questo approccio, ogni operazione di scrittura dei dati viene eseguita come se dopo ogni comando write()<\/code> al sistema vengano date, rispettivamente, comandi fsync()<\/code> e fdatasync()<\/code>. In specifiche POSIX<\/a><\/noindex> questo \u00e8 noto come \u00abSynchronized I\/O File Integrity Completion\u00bb e \u00abData Integrity Completion\u00bb. Il principale vantaggio di questo approccio \u00e8 che per garantire l'integrit\u00e0 dei dati \u00e8 necessario effettuare solo una chiamata di sistema, invece di due (ad esempio \u2014 write()<\/code> e fdatasync()<\/code>). Il principale svantaggio di questo approccio \u00e8 che tutte le operazioni di scrittura che utilizzano il corrispondente descrittore di file saranno sincronizzate, il che pu\u00f2 limitare le capacit\u00e0 di strutturazione del codice dell'applicazione.<\/p>\n

Utilizzo di Direct I\/O con il flag O_DIRECT<\/h2>\n

\nChiamata di sistema open()<\/code> supporta il flag O_DIRECT<\/code>, che \u00e8 progettato per eseguire operazioni di input\/output bypassando la cache del sistema operativo e interagendo direttamente con il disco. Questo, in molti casi, significa che i comandi di scrittura emessi dal programma verranno tradotti direttamente in comandi diretti per lavorare con il disco. Tuttavia, in generale, questo meccanismo non sostituisce le funzioni fsync()<\/code> o fdatasync()<\/code>. Il fatto \u00e8 che il disco stesso pu\u00f2 ritardare o memorizzare nella cache<\/a><\/noindex> i corrispondenti comandi di scrittura dei dati. E, ci\u00f2 che \u00e8 peggio, in alcuni casi particolari, le operazioni di input\/output eseguite utilizzando il flag O_DIRECT<\/code>, vengono tradotte<\/a><\/noindex> in operazioni tradizionali con buffer. Il modo pi\u00f9 semplice per risolvere questo problema \u00e8 utilizzare anche il flag O_DSYNC<\/code>, il che significa che per ogni operazione di scrittura ci sar\u00e0 una chiamata fdatasync()<\/code>.<\/p>\n

Si \u00e8 scoperto che nel file system XFS \u00e8 stata recentemente aggiunta una \"via rapida\" per O_DIRECT|O_DSYNC<\/code>-la scrittura dei dati. Se si sovrascrive un blocco utilizzando O_DIRECT|O_DSYNC<\/code>, quindi XFS, invece di svuotare la cache, eseguir\u00e0 il comando FUA per la scrittura nel caso in cui il dispositivo lo supporti. Ne ho avuto la conferma utilizzando l'utility blktrace<\/code> sul sistema Linux 5.4\/Ubuntu 20.04. Questo approccio dovrebbe essere pi\u00f9 efficiente, poich\u00e9 comporta la scrittura di un numero minimo di dati sul disco e utilizza un'unica operazione, invece di due (scrittura e svuotamento della cache). Ho trovato un link a per correggere l'errore.<\/a><\/noindex> un kernel del 2018, in cui \u00e8 implementato questo meccanismo. L\u00ec c'\u00e8 una discussione riguardante l'applicazione di questa ottimizzazione anche in altri file system, ma, per quanto ne so, XFS \u00e8 attualmente l'unico file system che la supporta.<\/p>\n

La funzione sync_file_range()<\/h2>\n

\nIn Linux, esiste una chiamata di sistema sync_file_range()<\/a><\/noindex>, che consente di scrivere su disco solo una parte di un file, e non l'intero file. Questa chiamata avvia un flush asincrono dei dati e non aspetta il suo completamento. Ma nella documentazione di sync_file_range()<\/code> si dice che questo comando \u00e8 'molto pericoloso'. Non si consiglia di usarlo. Le caratteristiche e i pericoli sync_file_range()<\/code> sono ben descritti in questo<\/a><\/noindex> materiale. In particolare, sembra che questa chiamata utilizzi RocksDB per gestire quando il kernel scrive i dati \"sporchi\" su disco. Tuttavia, per garantire la persistenza dei dati, viene utilizzato anche fdatasync()<\/code>. In codice<\/a><\/noindex> RocksDB ha commenti interessanti su questo argomento. Ad esempio, sembra che la chiamata sync_file_range()<\/code> quando si utilizza ZFS non porti al salvataggio dei dati su disco. L'esperienza mi suggerisce che il codice utilizzato raramente potrebbe contenere errori. Pertanto, consiglierei di non utilizzare questa chiamata di sistema senza una ragione impellente.<\/p>\n

Chiamate di sistema che aiutano a garantire la persistenza dei dati<\/h2>\n

\nSono giunto alla conclusione che per eseguire operazioni di input\/output che garantiscono la persistenza dei dati, si possono utilizzare tre approcci. Tutti richiedono la chiamata della funzione fsync()<\/code> per la directory in cui \u00e8 stato creato il file. Ecco questi approcci:<\/p>\n

    \n
  1. Chiamata della funzione fdatasync()<\/code> o fsync()<\/code> dopo la funzione write()<\/code> (meglio utilizzare fdatasync()<\/code>).<\/li>\n
  2. Lavorare con il descrittore di file aperto con il flag O_DSYNC<\/code> o O_SYNC<\/code> (meglio \u2014 con il flag O_DSYNC<\/code>).<\/li>\n
  3. Utilizzare il comando pwritev2()<\/code> con il flag RWF_DSYNC<\/code> o RWF_SYNC<\/code> (preferibilmente \u2014 con il flag RWF_DSYNC<\/code>).<\/li>\n<\/ol>\n

    <\/p>\n

    Note sulle prestazioni<\/h2>\n

    \nNon ho effettuato misurazioni dettagliate delle prestazioni dei vari meccanismi che ho esaminato. Le differenze di velocit\u00e0 che ho osservato sono piuttosto piccole. Questo significa che potrei sbagliarmi e che, in condizioni diverse, quello stesso meccanismo potrebbe mostrare risultati diversi. Inizier\u00f2 parlando di ci\u00f2 che influisce maggiormente sulle prestazioni e poi di ci\u00f2 che ha un impatto minore.<\/p>\n

      \n
    1. La riscrittura dei dati di un file \u00e8 pi\u00f9 veloce rispetto all'aggiunta di dati a un file (il guadagno in prestazioni pu\u00f2 variare dal 2% al 100%). L'aggiunta di dati a un file richiede modifiche aggiuntive ai metadati del file, anche dopo la chiamata di sistema fallocate()<\/code>, ma l'entit\u00e0 di questo effetto pu\u00f2 variare. Raccomando, per garantire le migliori prestazioni, di chiamare fallocate()<\/code> per la preallocazione dello spazio necessario. Successivamente, \u00e8 necessario riempire esplicitamente questo spazio con zeri e chiamare fsync()<\/code>. Questo rende i blocchi corrispondenti nel file system contrassegnati come \u00abdedicati\u00bb invece di \u00abnon dedicati\u00bb. Ci\u00f2 fornisce un piccolo miglioramento delle prestazioni (circa il 2%). Inoltre, per alcuni dischi, la prima operazione di accesso a un blocco pu\u00f2 richiedere pi\u00f9 tempo di altre. Ci\u00f2 significa che riempire lo spazio con zeri pu\u00f2 portare a un miglioramento delle prestazioni significativo (circa il 100%). In particolare, questo pu\u00f2 accadere con i dischi AWS EBS<\/a><\/noindex> (questi dati non sono ufficiali, non sono riuscito a confermarli). Lo stesso vale per gli archivi GCP Persistent Disk<\/a><\/noindex> (questo \u00e8 invece un'informazione ufficiale, confermata da test). Altri esperti hanno fatto osservazioni simili osservazioni<\/a><\/noindex>, relative a vari dischi.<\/li>\n
    2. Meno chiamate di sistema ci sono, maggiore \u00e8 la prestazione (il guadagno pu\u00f2 essere di circa il 5%). Sembra che la chiamata open()<\/code> con il flag O_DSYNC<\/code> o la chiamata pwritev2()<\/code> con il flag RWF_SYNC<\/code> sia pi\u00f9 veloce della chiamata fdatasync()<\/code>Sospetto che il problema sia che, con questo approccio, il numero di chiamate di sistema per risolvere lo stesso compito \u00e8 ridotto (una chiamata anzich\u00e9 due). Ma la differenza nelle prestazioni \u00e8 molto piccola, quindi puoi tranquillamente non tenerne conto e usare nel tuo applicativo ci\u00f2 che non complica la sua logica.<\/li>\n<\/ol>\n

      \nSe ti interessa il tema della conservazione sostenibile dei dati \u2014 ecco alcuni materiali utili:<\/p>\n