Per l'inclusione del kernel Linux 6.2 sono stati proposti miglioramenti a Btrfs riguardanti la risoluzione del problema del \"write hole\" nell'implementazione RAID 5\/6. La questione principale \u00e8 che, se si verifica un crash durante la scrittura, \u00e8 inizialmente impossibile determinare quale blocco su quale dispositivo RAID sia stato scritto correttamente e quale scrittura non sia stata completata. In caso di tentativo di recupero del RAID in una simile situazione, potrebbero verificarsi danni ai blocchi corrispondenti ai blocchi non scritti, poich\u00e9 lo stato dei blocchi RAID risulta desincronizzato. Questo problema si presenta in qualsiasi array RAID1\/5\/6 dove non sono state adottate misure specifiche per combattere questo effetto. <\/p>\n
Nella realizzazione di RAID, come RAID1 in btrfs, questo problema viene risolto utilizzando checksum in entrambe le copie; in caso di incoerenza, i dati vengono semplicemente ripristinati dalla seconda copia. Questo approccio funziona anche se uno dei dispositivi inizia a restituire dati errati anzich\u00e9 fallire completamente. <\/p>\n
Tuttavia, nel caso di RAID5\/6, il file system non memorizza checksum per i blocchi di parit\u00e0: in condizioni normali, la correttezza dei blocchi viene verificata dal fatto che tutti sono dotati di checksum e il blocco di parit\u00e0 pu\u00f2 essere ricreato dai dati. Tuttavia, in caso di scrittura parziale, questo approccio potrebbe non funzionare in determinate situazioni. In tal caso, durante il ripristino dell'array, non si pu\u00f2 escludere che i blocchi soggetti a registrazioni incomplete possano essere ripristinati in modo errato. <\/p>\n
Nel caso di btrfs, questo problema \u00e8 particolarmente rilevante se la scrittura effettuata \u00e8 inferiore alla dimensione dello striping. In questo caso, il file system deve eseguire l'operazione di lettura-modifica-scrittura (read-modify-write, RMW). Se si incontrano blocchi con scritture incomplete, l'operazione RMW pu\u00f2 causare danni che non saranno rilevati, nonostante i checksum. Gli sviluppatori hanno apportato modifiche affinch\u00e9 l'operazione RMW controlli i checksum dei blocchi prima di eseguire questa operazione e, se necessario per il recupero dei dati, esegue anche il controllo dei checksum dopo la scrittura. Purtroppo, nel caso della scrittura di uno strip incompleto (RMW), questo porta a costi aggiuntivi per il calcolo dei checksum, ma aumenta notevolmente l'affidabilit\u00e0. Per RAID6, questa logica non \u00e8 ancora pronta, ma per tale guasto in RAID6 \u00e8 necessario che la scrittura fallisca su due dispositivi contemporaneamente, il che \u00e8 meno probabile. <\/p>\n
In aggiunta, si possono notare le raccomandazioni degli sviluppatori per l'uso di RAID5\/6, che suggeriscono che in Btrfs il profilo di archiviazione dei metadati e dei dati pu\u00f2 differire. Si pu\u00f2 utilizzare un profilo RAID1 (mirror) o persino RAID1C3 (3 copie) per i metadati, mentre per i dati si utilizzano RAID5 o RAID6. Questo garantisce una protezione affidabile dei metadati e l'assenza del \"write hole\" da un lato, e un utilizzo pi\u00f9 efficace dello spazio, tipico di RAID5\/6, dall'altro. Questo permette di evitare danni ai metadati, mentre i danni ai dati possono essere corretti. <\/p>\n
Si pu\u00f2 anche notare che per SSD in Btrfs nel kernel 6.2 sar\u00e0 attivata di default l'esecuzione asincrona dell'operazione \"discard\" (segnare i blocchi liberati che non devono pi\u00f9 essere conservati fisicamente). Il vantaggio di questo modo \u00e8 l'alta prestazione grazie all'efficace raggruppamento delle operazioni di \"discard\" in coda e alla successiva elaborazione della coda da parte di un gestore in background, il che fa s\u00ec che le normali operazioni FS non vengano rallentate, a differenza del \"discard\" sincrono durante il rilascio dei blocchi, e l'SSD pu\u00f2 prendere decisioni pi\u00f9 ottimali. D'altra parte, non sar\u00e0 pi\u00f9 necessario utilizzare utilit\u00e0 come fstrim, poich\u00e9 tutti i blocchi disponibili verranno puliti nel FS senza la necessit\u00e0 di una scansione aggiuntiva e senza rallentare le operazioni. \u0414\u043b\u044f \u0432\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u044f \u044f\u0434\u0440\u043e Linux 6.2 \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0435\u043d\u044b \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f Btrfs, \u043a\u0430\u0441\u0430\u044e\u0449\u0438\u0435\u0441\u044f \u0438\u0441\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b «write hole» \u0432 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 RAID 5\/6. \u0421\u0443\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u0441\u0432\u043e\u0434\u0438\u0442\u0441\u044f \u043a \u0442\u043e\u043c\u0443, \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043a\u0440\u0430\u0445 \u0441\u043b\u0443\u0447\u0438\u043b\u0441\u044f \u0432\u043e \u0432\u0440\u0435\u043c\u044f \u0437\u0430\u043f\u0438\u0441\u0438, \u0438\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043d\u0435\u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e \u043f\u043e\u043d\u044f\u0442\u044c \u043a\u0430\u043a\u043e\u0439 \u0431\u043b\u043e\u043a \u043d\u0430 \u043a\u0430\u043a\u043e\u043c \u0438\u0437 \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432 RAID \u0437\u0430\u043f\u0438\u0441\u0430\u043b\u0441\u044f \u043a\u043e\u0440\u0440\u0435\u043a\u0442\u043d\u043e, \u0430 \u0432 \u043a\u0430\u043a\u043e\u043c \u0437\u0430\u043f\u0438\u0441\u044c \u043d\u0435 \u0431\u044b\u043b\u0430 \u0437\u0430\u0432\u0435\u0440\u0448\u0435\u043d\u0430. \u0412 \u0441\u043b\u0443\u0447\u0430\u0435 \u043f\u043e\u043f\u044b\u0442\u043a\u0438 \u0432\u043e\u0441\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u044f RAID \u0432 \u043f\u043e\u0434\u043e\u0431\u043d\u043e\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-106149","post","type-post","status-publish","format-standard","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Il kernel Linux 6.2 includer\u00e0 miglioramenti RAID5\/6 in Btrfs | ProHoster","description":"Per l'inclusione, il kernel Linux 6.2 propone miglioramenti a Btrfs riguardanti la risoluzione del problema del \"write hole\" nell'implementazione RAID 5\/6.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/news\/v-yadro-linux-6-2-vojdut-uluchsheniya-raid5-6-v-btrfs","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412 \u044f\u0434\u0440\u043e Linux 6.2 \u0432\u043e\u0439\u0434\u0443\u0442 \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f RAID5\/6 \u0432 Btrfs | ProHoster","og:description":"\u0414\u043b\u044f \u0432\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u044f \u044f\u0434\u0440\u043e Linux 6.2 \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0435\u043d\u044b \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f Btrfs, \u043a\u0430\u0441\u0430\u044e\u0449\u0438\u0435\u0441\u044f \u0438\u0441\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b "write hole" \u0432 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 RAID 5\/6.","og:url":"https:\/\/prohoster.info\/it\/blog\/news\/v-yadro-linux-6-2-vojdut-uluchsheniya-raid5-6-v-btrfs","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2022-12-18T19:36:39+00:00","article:modified_time":"2022-12-18T19:36:39+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":[],"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/106149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=106149"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/106149\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=106149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=106149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=106149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n
Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"