Ho lo stesso problema che molte persone hanno: come creare una soluzione di archiviazione personale affidabile con il fatto che:

1. I dischi rigidi si guastano con regolarità allarmante. Perdere file è inaccettabile.
2. Comprerò un nuovo HDD di volta in volta. Inevitabilmente, il miglior prezzo / GB ha dimensioni diverse rispetto all'ultimo acquisto di HDD.

3. 2 significa che nel tempo ho una raccolta eterogenea di dischi. Voglio usarli tutti e i dischi guasti verranno generalmente sostituiti da dischi più grandi.

4. L'integrità e l'affidabilità dei dati per me sono più importanti della velocità.

Quindi dopo aver sbattuto la testa contro questo problema per alcuni giorni (e nella parte posteriore della mia testa per anni), propongo la seguente soluzione. Descriverò una soluzione che ho testato sulla base di Linux ZFS nativo che è disponibile in un Ubuntu PPA , ma LVM, MD e btrfs possono essere usati per ottenere lo stesso. Per questo userò RAID1 (ZFS mirror vdevs).

1. Dato il tuo set di unità, raggruppali in due set di dischi, in modo tale che la capacità di ciascun set sia il più vicino possibile all'altro.
2. Partizionare i dischi più grandi in modo tale che vi sia una partizione esattamente della stessa dimensione di uno dei dischi più piccoli, nell'altro gruppo.
3. Crea vdev mirror in modo tale che ogni disco abbia il suo mirror su un altro disco.

Ad esempio, si consideri un set di dischi di una nuova unità da 2 TB, un'unità da 750 GB, 2 unità da 400 GB e una da 500 GB. Il partizionamento speculare ottimale ha 2 TB di spazio utilizzabile ed è descritto nel diagramma seguente in cui ':' separa le partizioni e '|' separa i dischi:

+------------------------------------------------------------------+
| 2TB (sda1)        : (sda2)       : (sda3)       : (sda4)         |
+------------------------------------------------------------------+--+
| 750 GB (sdb)      | 400 GB (sdc) | 400 GB (sdd) | 500 GB (sde1)  :XX|
+---------------------------------------------------------------------+

Crea il tuo zpool come

zpool create archive mirror /dev/sda1 /dev/sdb mirror /dev/sda2 /dev/sdc mirror /dev/sda3 /dev/sdd mirror /dev/sda4 /dev/sde1

Questo crea 4 vdev con mirroring. Se uno qualsiasi dei dischi si guasta, può essere sostituito (con qualsiasi disco di dimensioni) e partizionato per ricreare le partizioni mancanti. È importante che i vdev di ZFS possano essere aggiunti a un pool ma non rimossi . Quindi, se possibile, quando si acquista una nuova unità, si desidera riorganizzare i vdev esistenti. Supponiamo che il prossimo acquisto sia stato un disco da 3 TB. La configurazione ottimale è utilizzabile da 3,5 TB, come descritto nel diagramma seguente. Questo è ora 5 coppie vdev. Ciò può essere ottenuto mediante il partizionamento appropriato e successivamente il fallimento e il ripartizionamento delle unità.

+--------------------------------------------------------------+-------------+
| 3 TB (sdf1)       : (sdf2)      : (sdf3)      : (sdf4)       | 500GB (sde) |
+--------------------------------------------------------------+-------------+-+
| 2TB (sda1)        | 400GB (sdb) | 400GB (sdc) | 750GB (sdd1) : (sdd2)      :X| 
+------------------------------------------------------------------------------+

Il mantenimento di questa associazione di unità con mirroring potrebbe essere eseguito anche con LVM o MD RAID, con l'idea di assicurarsi che ogni unità abbia sempre un'unità o una partizione mirror. Poiché tutto è speculare, siamo liberi di danneggiare le unità e riorganizzare le partizioni quando le unità vengono aggiunte o rimosse. Utilizzando LVM o MD sarebbe possibile rimuovere le unità e ridurre l'array, se lo si desidera, a spese di strumenti di recupero meno sofisticati in ZFS rispetto a BTRFS.

Qualche commento su questa procedura? Un buon script potrebbe gestire l'allocazione e il riarrangiamento senza perdita di unità. Qualche commento su LVM vs. MD vs. ZFS? Qualche commento sulle prestazioni della risultante matrice partizionata in modo strano? La disposizione dei dati tra più partizioni sulla stessa unità causerà una ricerca eccessiva della testa e guasti precoci?

Dev di BTRFS: tutti lo vogliono e LVM o MD non sono tecnicamente necessari (e secondo me non ottimali). Rendere facile mantenere un array eterogeneo ridondante sarebbe una caratteristica killer per btrfs. È un hack su LVM / MD / ZFS così com'è. Ridurre al minimo il resliver / resync è estremamente desiderabile.

Sì, questo è ovviamente un Drobo da povero. Non si dovrebbe aver bisogno di hardware dedicato per questo ...

Ho provato questo con ZFS e le prestazioni di scrittura sono circa la metà di quelle che dovrebbero essere, perché ZFS distribuisce letture e scritture su tutti i vdev (quindi dividendo l'I / O in più posizioni sullo stesso disco). Pertanto, la velocità è limitata dalla velocità del disco con il maggior numero di partizioni. La velocità di lettura sembra essere uguale alla larghezza di banda del disco. Si noti che una coppia di partizioni ZFS su due dischi ha circa il doppio della velocità di lettura di entrambi i dischi singoli, perché può leggere dai dischi in parallelo.

L'uso di array MD LINEAR o LVM per creare le due metà comporta prestazioni di scrittura doppie rispetto alla precedente proposta ZFS, ma presenta lo svantaggio che LVM e MD non hanno idea di dove siano archiviati i dati. In caso di guasto o aggiornamento del disco, un lato dell'array deve essere completamente distrutto e risincronizzato / rispedito, seguito dall'altro lato. (ad es. resync / resliver deve copiare 2 * (dimensione dell'array))

Pertanto, sembra quindi che la soluzione ottimale sia quella di creare un singolo vdev mirror ZFS su due dispositivi LVM o MD LINEAR che combinano i dischi in "metà" di uguali dimensioni. Questo ha circa il doppio della larghezza di banda di lettura di un singolo disco e la larghezza di banda di scrittura è uguale alla larghezza di banda del singolo disco.

L'uso di BTRFS raid1 invece di ZFS funziona anche, ma ha metà della larghezza di banda di lettura perché ZFS distribuisce le sue letture per raddoppiare la larghezza di banda, mentre sembra che BTRFS non lo faccia (secondo i miei test). BTRFS ha il vantaggio che le partizioni possono essere ridotte, mentre non possono farlo con ZFS (quindi se dopo un errore hai un sacco di spazio vuoto, con BTRFS è possibile ricostruire un array ridondante più piccolo restringendo il filesystem, quindi riorganizzando i dischi).

Questo è noioso da fare a mano ma facile con alcuni buoni script.