{"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 dati sostenibile e API file 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 le basi. Ho iniziato leggendo la specifica NVMe<\/a><\/noindex> per capire quali garanzie riguardanti la resilienza dei dati (cio\u00e8 le garanzie che i dati saranno disponibili dopo un guasto del sistema) ci offrono i dischi NVMe. Ho tratto le seguenti conclusioni principali: i dati devono essere considerati danneggiati dal momento in cui viene dato l'ordine di scrittura e fino a quando la scrittura non \u00e8 completata sul supporto. Tuttavia, nella maggior parte dei programmi di scrittura dei dati, vengono spesso utilizzate tranquillamente chiamate di sistema.<\/p>\n

In questo materiale, esaminer\u00f2 i meccanismi di resilienza dei dati forniti dalle API di file di Linux. Sembra che qui tutto dovrebbe essere semplice: il programma invoca il comando write()<\/code>, e dopo che il comando ha terminato la sua esecuzione, i dati dovrebbero essere salvati in modo affidabile sul disco. Ma write()<\/code> esso copia solo i dati dell'applicazione nella cache del kernel, che si trova nella memoria principale. Per costringere 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 rappresenta un insieme di appunti riguardo a ci\u00f2 che ho appreso sull'argomento che mi interessa. Se si desidera riassumere brevemente il punto pi\u00f9 importante, si pu\u00f2 affermare che per garantire la resilienza dei dati \u00e8 necessario utilizzare il comando fdatasync()<\/code> o aprire i file con il flag O_DSYNC<\/code>. Se sei interessato a scoprire nei dettagli ci\u00f2 che accade ai dati nel percorso dal codice sorgente al disco, dai un'occhiata a questa<\/a><\/noindex> articolo.
\n<\/a><\/noindex><\/p>\n

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

\nChiamata di sistema write()<\/code> definito nello standard IEEE POSIX<\/a><\/noindex> come un tentativo di scrivere dati in un descrittore di file. Dopo il completamento con successo, write()<\/code> le operazioni di lettura dei dati devono restituire esattamente quei byte che erano stati precedentemente scritti, anche se i dati vengono accessibili 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 entrambi i thread chiamano queste funzioni, ogni chiamata deve vedere o tutte le conseguenze designate derivanti dall'esecuzione di un'altra chiamata, oppure non deve vedere alcuna conseguenza. Questo porta alla conclusione che tutte le operazioni di input\/output sui file devono mantenere il blocco della risorsa su cui operano.<\/p>\n

Significa questo che l'operazione write()<\/code> \u00e8 atomica? Dal punto di vista tecnico \u2014 s\u00ec. Le operazioni di lettura dei dati devono restituire tutto o nulla di ci\u00f2 che \u00e8 stato scritto tramite write()<\/code>. Ma l'operazione write()<\/code>, secondo lo standard, non deve necessariamente completarsi scrivendo tutto ci\u00f2 che le \u00e8 stato proposto di scrivere. \u00c8 permesso scrivere solo una parte dei dati. Ad esempio, possiamo avere due thread, ognuno dei quali aggiunge 1024 byte a un file identificato dallo stesso descrittore di file. Dal punto di vista dello standard, \u00e8 accettabile che ogni operazione di scrittura possa aggiungere solo un byte al file. Queste operazioni rimarranno atomiche, ma una volta completate, 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 scrivere i dati su disco \u00e8 invocare la funzione fsync()<\/a><\/noindex>. Questa funzione richiede al sistema operativo di trasferire tutti i blocchi modificati dalla cache al disco. Questo include anche tutti i metadati del file (tempo di accesso, tempo di modifica del file e cos\u00ec via). Penso che la necessit\u00e0 di questi metadati si verifichi raramente, quindi se sai che non ti sono importanti, puoi utilizzare la funzione fdatasync()<\/code>. In informativa<\/a><\/noindex> da fdatasync()<\/code> afferma che nel corso di questa funzione viene eseguito il salvataggio su disco di un volume di metadati che \u00e8 \u201cnecessario per l'esecuzione corretta delle operazioni di lettura successiva sui dati\u201d. E questo \u00e8 esattamente ci\u00f2 che preoccupa la maggior parte delle applicazioni.<\/p>\n

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

Questo meccanismo pu\u00f2 essere implementato in modo diverso nei vari file system. Ho usato blktrace<\/a><\/noindex> per scoprire quali operazioni su disco vengono utilizzate nei file system ext4 e XFS. Entrambi emettono normali comandi di scrittura su disco sia per i contenuti dei file che per il journaling del file system, svuotano la cache e terminano l'operazione eseguendo una scrittura FUA (Force Unit Access, scrittura dei dati direttamente su disco, bypassando la cache) nel journal. \u00c8 probabile che procedano in questo modo per confermare l'operazione eseguita. Su dischi che non supportano FUA, ci\u00f2 provoca due svuotamenti della cache. I miei esperimenti hanno dimostrato che fdatasync()<\/code> \u00e8 un po' pi\u00f9 veloce fsync()<\/code>. L'utilit\u00e0 blktrace<\/code> indica che fdatasync()<\/code> scrive normalmente meno dati su disco (in ext4 fsync()<\/code> scrive 20 KiB, mentre fdatasync()<\/code> ne scrive 16 KiB). Inoltre, ho scoperto che XFS \u00e8 leggermente pi\u00f9 veloce di ext4. E qui sono riuscito a scoprire che blktrace<\/code> svuota su disco meno dati (4 KiB in XFS). fdatasync()<\/code> Situazioni ambigue che sorgono con l'uso di fsync()<\/p>\n

Posso ricordare tre situazioni ambigue riguardo<\/h2>\n

\n, con cui mi sono imbattuto nella pratica. fsync()<\/code>Il primo di questi casi \u00e8 avvenuto nel 2008. In quel momento, l'interfaccia di Firefox 3 'si bloccava' quando veniva scritta su disco una grande quantit\u00e0 di file. Il problema era che nell'implementazione dell'interfaccia per memorizzare informazioni sul suo stato veniva utilizzato un database SQLite. Dopo ogni modifica avvenuta nell'interfaccia, veniva chiamata la funzione<\/p>\n

, il che garantiva buone garanzie di persistenza dei dati. Nella file system utilizzata all'epoca, ext3, la funzione fsync()<\/code>, che forniva buone garanzie di archiviazione stabile dei dati. Nella filesystem ext3 utilizzata allora, la funzione fsync()<\/code> reindirizzava su disco tutte le pagine \"sporche\" nel sistema, e non solo quelle correlate al file pertinente. Ci\u00f2 significava che un clic su un pulsante in Firefox poteva avviare la scrittura di megabyte di dati su disco rigido, cosa che poteva richiedere molti secondi. Ho compreso la soluzione al problema da di questo<\/a><\/noindex> materiale che era quella di spostare il lavoro con il database in attivit\u00e0 di fondo asincrone. Ci\u00f2 implica che in precedenza in Firefox erano stati implementati requisiti di robustezza del salvataggio dei dati molto pi\u00f9 severi di quanto fosse realmente necessario, e le peculiarit\u00e0 del file system ext3 hanno solo aggravato questo problema.<\/p>\n

Il secondo inconveniente si \u00e8 verificato nel 2009. In quell'anno, dopo un guasto del sistema, gli utenti del nuovo file system ext4 si sono trovati di fronte al fatto che molti file di recente creazione avevano una lunghezza zero, mentre con il file system pi\u00f9 vecchio ext3 non si \u00e8 verificato nulla di simile. Nel paragrafo precedente accennavo al fatto che l'ext3 scriveva troppi dati su disco, il che rallentava notevolmente le operazioni fsync()<\/code>. Per migliorare la situazione, in ext4 vengono scritte su disco solo le \"pagine sporche\" che sono correlate a un file specifico. I dati degli altri file rimangono in memoria per un tempo molto pi\u00f9 lungo rispetto a quanto avveniva con l'uso dell'ext3. Questo \u00e8 stato fatto per migliorare le prestazioni (per impostazione predefinita, i dati rimangono in questo stato per 30 secondi, e questo pu\u00f2 essere configurato tramite dirty_expire_centisecs<\/a><\/noindex>; qui<\/a><\/noindex> , si possono trovare ulteriori materiali a riguardo). Ci\u00f2 significa che una grande quantit\u00e0 di dati pu\u00f2 essere permanentemente persa dopo un guasto. La soluzione a questo problema consiste nell'utilizzo di fsync()<\/code> applicazioni che necessitano di garantire una conservazione affidabile dei dati e proteggere al massimo dalle conseguenze dei guasti. La funzione fsync()<\/code> opera con l'ext4 in modo significativamente pi\u00f9 efficace rispetto all'ext3. Il rovescio della medaglia di questo approccio \u00e8 che la sua applicazione, come in passato, rallenta l'esecuzione di alcune operazioni, come l'installazione di programmi. Maggiori dettagli su questo si possono trovare qui<\/a><\/noindex> e qui<\/a><\/noindex>.<\/p>\n

Il terzo problema riguardante fsync()<\/code>, \u00e8 emerso nel 2018. In quell'anno, nell'ambito del progetto PostgreSQL, \u00e8 stato scoperto che se la funzione fsync()<\/code> incontra un errore, contrassegna le \"pagine sporche\" come \"pulite\". Di conseguenza, le chiamate successive fsync()<\/code> non si fa niente con queste pagine. A causa di ci\u00f2, le pagine modificate rimangono in memoria e non vengono mai scritte su disco. Questa \u00e8 una vera catastrofe, poich\u00e9 l'applicazione penser\u00e0 che alcuni dati siano stati scritti su disco, ma in realt\u00e0 cos\u00ec non \u00e8. Questi malfunzionamenti fsync()<\/code> si verificano raramente, l'applicazione in queste situazioni pu\u00f2 fare quasi nulla per affrontare il problema. Al giorno d'oggi, quando ci\u00f2 accade, PostgreSQL e altre applicazioni terminano improvvisamente. Qui<\/a><\/noindex>, nel materiale \"Can Applications Recover from fsync Failures?\", questo problema viene studiato in tutti i dettagli. Attualmente, la miglior soluzione per 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 gli errori che possono verificarsi durante l'esecuzione di operazioni specifiche di scrittura dei dati, ma questo approccio richiede che l'applicazione gestisca i buffer autonomamente. Maggiori dettagli su questo possono essere letti qui<\/a><\/noindex> e qui<\/a><\/noindex>.<\/p>\n

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

\nTorniamo a discutere dei meccanismi di Linux che garantiscono l'integrit\u00e0 dei dati. In particolare, si tratta dell'uso del flag O_SYNC<\/code> o del flag O_DSYNC<\/code> quando si aprono file usando la chiamata di sistema open()<\/a><\/noindex>. Con questo approccio, ogni operazione di scrittura di dati viene eseguita come se dopo ogni comando write()<\/code> al sistema venissero date, rispettivamente, le istruzioni fsync()<\/code> e fdatasync()<\/code>. In specifiche POSIX<\/a><\/noindex> questo \u00e8 chiamato \"Synchronized I\/O File Integrity Completion\" e \"Data Integrity Completion\". Il principale vantaggio di questo approccio \u00e8 che per garantire l'integrit\u00e0 dei dati \u00e8 necessario eseguire solo una chiamata di sistema, e non due (ad esempio - write()<\/code> e fdatasync()<\/code>). Lo svantaggio principale di questo approccio \u00e8 che tutte le operazioni di scrittura che utilizzano il relativo descrittore di file saranno sincronizzate, il che pu\u00f2 limitare le possibilit\u00e0 di strutturare il codice dell'applicazione.<\/p>\n

L'uso 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, interagendo direttamente con il disco. Questo, in molti casi, significa che i comandi di scrittura emessi dal programma verranno direttamente tradotti in comandi destinati a lavorare con il disco. Ma, in generale, questo meccanismo non sostituisce le funzioni fsync()<\/code> o fdatasync()<\/code>. Il fatto \u00e8 che il disco stesso pu\u00f2 rinviare o memorizzare in cache<\/a><\/noindex> i comandi corretti per la scrittura dei dati. E, peggio ancora, in alcuni casi particolari, le operazioni di input\/output eseguite utilizzando il flag O_DIRECT<\/code>, vengono tradotte<\/a><\/noindex> in operazioni di buffering tradizionali. Il modo pi\u00f9 semplice per risolvere questo problema \u00e8 utilizzare anche il flag per aprire i file O_DSYNC<\/code>, il che significher\u00e0 che ad ogni operazione di scrittura seguir\u00e0 una chiamata fdatasync()<\/code>.<\/p>\n

\u00c8 emerso che nel file system XFS \u00e8 stato recentemente aggiunto un 'percorso veloce' per O_DIRECT|O_DSYNC<\/code>-la scrittura dei dati. Se si riporta un blocco utilizzando O_DIRECT|O_DSYNC<\/code>, XFS, invece di svuotare la cache, eseguir\u00e0 il comando di scrittura FUA se l'hardware lo supporta. Ne ho avuto conferma utilizzando l'utilit\u00e0 blktrace<\/code> nel sistema Linux 5.4\/Ubuntu 20.04. Questo approccio dovrebbe essere pi\u00f9 efficace, poich\u00e9 riduce al minimo la quantit\u00e0 di dati scritti su disco e utilizza un'unica operazione anzich\u00e9 due (scrittura e svuotamento della cache). Ho trovato un collegamento al patch<\/a><\/noindex> kernel del 2018, in cui \u00e8 stato implementato questo meccanismo. L\u00ec c'\u00e8 una discussione relativa all'applicazione di questa ottimizzazione anche in altri file system, ma, per quanto ne so, XFS \u00e8 l'unico file system che attualmente lo 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 svuotare su disco solo una parte di un file, non l'intero file. Questa chiamata avvia uno svuotamento asincrono dei dati e non ne attende il completamento. Ma nella documentazione sync_file_range()<\/code> si afferma che questo comando \u00e8 'molto pericoloso'. Non \u00e8 consigliabile usarlo. Le caratteristiche e i pericoli sync_file_range()<\/code> sono descritti molto bene nel seguente<\/a><\/noindex> materiale. In particolare, sembra che questa chiamata utilizzi RocksDB per gestire quando il kernel svuota i dati 'sporchi' su disco. Ma al contempo, per garantire una memorizzazione persistente dei dati, utilizza anche fdatasync()<\/code>. In codice<\/a><\/noindex> RocksDB ci sono commenti interessanti su questo argomento. Ad esempio, sembra che la chiamata sync_file_range()<\/code> quando si utilizza ZFS non comporti lo svuotamento dei dati su disco. L'esperienza mi dice che il codice che viene usato raramente potrebbe contenere errori. Pertanto, consiglio di non utilizzare questa chiamata di sistema senza un'urgente necessit\u00e0.<\/p>\n

Le chiamate di sistema che aiutano a garantire una conservazione persistente dei dati<\/h2>\n

\nSono giunto alla conclusione che per effettuare operazioni di input\/output che garantiscano una conservazione persistente dei dati, si possono adottare 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> (\u00e8 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. Utilizzo del 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 accurate delle prestazioni dei vari meccanismi che ho esaminato. Le differenze di velocit\u00e0 che ho notato sono piuttosto minime. Questo significa che potrei sbagliarmi, e che in altre condizioni potrebbe mostrare risultati diversi. Inizier\u00f2 a parlare di ci\u00f2 che influisce maggiormente sulle prestazioni, e poi di ci\u00f2 che influisce meno.<\/p>\n

      \n
    1. La riscrittura dei dati di un file \u00e8 pi\u00f9 veloce dell'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 l'allocazione anticipata dello spazio necessario. Dopo, questo spazio deve essere esplicitamente riempito di zeri e chiamare fsync()<\/code>. Questo consente ai relativi blocchi nel file system di essere contrassegnati come \"allocati\" e non come \"non allocati\". Questo apporta un piccolo (circa il 2%) miglioramento delle prestazioni. Inoltre, alcuni dischi possono avere la prima operazione di accesso a un blocco che potrebbe richiedere pi\u00f9 tempo rispetto ad altri. Ci\u00f2 significa che riempire lo spazio di zeri pu\u00f2 portare a un miglioramento significativo (circa il 100%) delle prestazioni. In particolare, ci\u00f2 pu\u00f2 avvenire con i dischi AWS EBS<\/a><\/noindex> (questi sono dati non ufficiali, non sono riuscito a confermarli). Lo stesso vale per gli storage GCP Persistent Disk<\/a><\/noindex> (questo \u00e8 invece un dato ufficiale, confermato dai test). Altri specialisti hanno fatto osservazioni simili , relative a diversi dischi.<\/a><\/noindex>Meno chiamate di sistema ci sono, maggiore \u00e8 la prestazione (il guadagno pu\u00f2 essere circa il 5%). Sembra che la chiamata<\/li>\n
    2. o la chiamata open()<\/code> con il flag O_DSYNC<\/code> sia pi\u00f9 veloce della chiamata pwritev2()<\/code> con il flag RWF_SYNC<\/code> richiama pi\u00f9 rapidamente fdatasync()<\/code>Sospetto che il motivo risieda nel fatto che, con questo approccio, il numero di chiamate di sistema necessarie per risolvere lo stesso compito \u00e8 ridotto (una chiamata invece di due). Tuttavia, la differenza nelle prestazioni \u00e8 molto piccola, quindi potete ignorarla e utilizzare nell'applicazione ci\u00f2 che non porter\u00e0 a complicare la sua logica.<\/li>\n<\/ol>\n

      \nSe siete interessati al tema dell'archiviazione dati sicura, ecco alcuni materiali utili:<\/p>\n