<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9"> <TITLE>Software-RAID HOWTO: Desiderata di MD e del relativo software</TITLE> <LINK HREF="Software-RAID-0.4x-HOWTO-10.html" REL=previous> <LINK HREF="Software-RAID-0.4x-HOWTO.html#toc11" REL=contents> </HEAD> <BODY> Avanti <A HREF="Software-RAID-0.4x-HOWTO-10.html">Indietro</A> <A HREF="Software-RAID-0.4x-HOWTO.html#toc11">Indice</A> <HR> <H2><A NAME="s11">11. Desiderata di MD e del relativo software</A></H2> <P>Bradley Ward Allen < <A HREF="mailto:ulmo@Q.Net">ulmo@Q.Net</A>> ha scritto: <BLOCKQUOTE> Le idee includono: <UL> <LI>Parametri di boot per dire al kernel quali dispositivi dovranno essere dispositivi MD (niente più ``<CODE>mdadd</CODE>'')</LI> <LI>Rendere MD trasparente a ``<CODE>mount</CODE>''/``<CODE>umount</CODE>'' in modo tale che non vi siano più ``<CODE>mdrun</CODE>'' e ``<CODE>mdstop</CODE>''</LI> <LI>Completa integrazione nel kernel di ``<CODE>ckraid</CODE>'' e sua esecuzione automatica in caso di bisogno.</LI> </UL> (Ho già suggerito di smetterla di usare i tool e di integrarli nel kernel; io la penso così, si parla di un filesystem, non di un giocattolo.) <UL> <LI>Trattare sistemi che possano facilmente sopravvivere al malfunzionamento (simultaneo o in momenti separati) di N dischi, con N intero > 0 definito dall'amministratore di sistema.</LI> <LI>Migliorarne il comportamento in caso di blocco del kernel, problemi con l'alimentazione e altri shutdown improvvisi.</LI> <LI>Non disabilitare l'intero disco se solo una parte di esso si è rovinata, ad es. se gli errori di lettura sono meno del 50% su 20 diverse richieste di accesso, si continua ad usare il disco ignorando i settori che hanno dato problemi.</LI> <LI>Settori danneggiati: <UL> <LI>Un meccanismo che consenta di memorizzare da qualche parte nel disco quali settori sono danneggiati.</LI> <LI>Se esiste già una convenzione riconoscibile dai filesystem di livello più alto per marcare i settori danneggiati, questa deve essere usata. Programmarne una se non ne esiste una riconoscibile.</LI> <LI>Forse in alternativa un meccanismo per fare sapere allo strato superiore che le dimensioni del disco si sono ridotte, magari implementando una automazione che consenta allo strato superiore di spostare i dati dalle aree che vengono eliminate. Questo potrebbe anche andare bene per trattare i blocchi danneggiati.</LI> <LI>Nel caso non si possano realizzare le idee di cui sopra, lasciare una piccola parte del disco (definibile dall'amministratore di sistema) da parte per i blocchi danneggiati (magari distribuita su tutto il disco?) e usare questa area (la più vicina) al posto dei blocchi danneggiati quando questi vengono scoperti. Ovviamente questa soluzione è inefficiente. Oltretutto il kernel dovrebbe mettere nei log, ogni volta che il sistema RAID viene avviato, tutti i settori danneggiati e i provvedimenti adottati nei loro riguardi con priorità ``<CODE>crit</CODE>'', solo per far sapere all'amministratore che il suo disco è impolverato internamente (o ha una testina malata).</LI> </UL> </LI> <LI>Dischi (dis)attivabili via software: <DL> <DT><B>``disattiva questo disco''</B><DD><P>si blocca fino a che il kernel non si è assicurato che non vi siano dati che possono servire sul disco che sta per essere disattivato (ad es. per completare uno XOR/ECC/ o altra correzione di errore), quindi cessa l'utilizzo del disco (in modo che possa essere rimosso, ecc.) <DT><B>``attiva questo disco''</B><DD><P>esegue, se necessario, <CODE>mkraid</CODE> su un nuovo disco e quindi lo utilizza per le operazioni ECC/qualsiasi, ampliando quindi il sistema RAID5; <DT><B>``ridimensiona il sistema''</B><DD><P>reimposta il numero totale di dischi e il numero di dischi ridondanti, spesso con il risultato di aumentare le dimensioni del sistema RAID; sarebbe bello poter usare questa opzione, quando serve, senza perdere dati, ma mi viene difficile immaginare come possa funzionare effettivamente; in ogni caso, un modo per sospendere (possibilmente per delle ore (il kernel dovrebbe scrivere qualcosa nei log ogni dieci secondi in questo caso)) potrebbe essere necessario; <DT><B>``attiva questo disco mentre salvi i dati''</B><DD><P>che salvi i dati su un disco così com'è e lo inserisca in un sistema RAID5, in modo tale che l'orrendo "salva e ripristina" non debba essere eseguito ogni volta che qualcuno configuri un sistema RAID5 (oppure, potrebbe essere più semplice salvare una partizione al posto di due, potrebbe addirittura entrare nella prima come file compresso con gzip); infine, <DT><B>``riattiva disco''</B><DD><P>potrebbe essere un modo grazie al quale l'operatore scavalca il SO per provare un disco che in precedenza era risultato non funzionante (potrebbe semplicemente chiamare "disattiva" e quindi "attiva", penso). </DL> </LI> </UL> </BLOCKQUOTE> <P>Altre idee dalla rete: <BLOCKQUOTE> <UL> <LI>rendere finalrd simile a initrd, per semplificare il boot da raid.</LI> <LI>una modalità raid di sola scrittura, per rendere più semplice quanto sopra</LI> <LI>Contrassegnare il sistema RAID come "pulito" quando non siano state effettuate "mezze scritture". -- Sarebbe come dire che non vi sono operazioni di scrittura finite su un disco e ancora da ultimare su un altro disco. Aggiungere un timeout che segnali "inattività in scrittura" (per evitare seek frequenti al superblock RAID quando il sistema RAID è relativamente occupato.) </LI> </UL> </BLOCKQUOTE> <P> <HR> Avanti <A HREF="Software-RAID-0.4x-HOWTO-10.html">Indietro</A> <A HREF="Software-RAID-0.4x-HOWTO.html#toc11">Indice</A> </BODY> </HTML>
