Ho sovrascritto accidentalmente entrambi gli ZIL sull'ultima versione di OpenSolaris, causando la perdita irrevocabile dell'intero pool. (Davvero un brutto errore da parte mia! Non capivo che perdere lo ZIL avrebbe significato perdere il pool. Fortunatamente recuperato dal backup con tempi di inattività.)
Tuttavia, dalla versione 151a (non so con certezza cosa significhi la versione di ZPool), questo problema è stato risolto. E posso testimoniare che funziona.
Oltre a ciò, ho perso i dati ZERO su un server da 20 TB, anche a causa di numerosi altri casi di errore dell'utente, più interruzioni di corrente, cattiva gestione del disco, configurazioni errate, numerosi dischi guasti, ecc. Anche se la gestione e le interfacce di configurazione su Solaris cambiano frequentemente e in modo esasperante da una versione all'altra e presentano un obiettivo di competenze in costante mutamento, è ancora l'opzione migliore per ZFS.
Non solo non ho perso i dati su ZFS (dopo il mio terribile errore), ma mi protegge costantemente. Non subisco più la corruzione dei dati, che mi ha tormentato negli ultimi 20 anni su qualsiasi numero di server e workstation, con quello che faccio. Il danneggiamento dei dati silenzioso (o semplicemente "abbastanza silenzioso") mi ha ucciso numerose volte, quando i dati rotolano fuori dalla rotazione del backup, ma in realtà è diventato corrotto su disco. O altri scenari in cui i backup hanno eseguito il backup delle versioni corrotte. Questo è stato un problema molto più grande della semplice perdita di dati in una sola volta, il che è quasi sempre eseguito il backup. Per questo motivo, adoro ZFS e non riesco a capire perché il checksum e la guarigione automatica non siano state funzionalità standard nei file system per un decennio. (Concesso, i sistemi veramente vita o morte di solito hanno altri modi per assicurare l'integrità,
In parole povere, se non vuoi scendere all'inferno ACL, non usare il server CIFS integrato in ZFS. Usa Samba. (Hai detto che usi NFS però.)
Non sono d'accordo con l'argomento SAS vs. SATA, almeno il suggerimento che SAS sia sempre preferito su SATA, per ZFS. Non so se quel commento si riferisse alla velocità di rotazione del piatto, alla presunta affidabilità, alla velocità dell'interfaccia o ad altri attributi. (O forse solo "costano di più e non sono generalmente utilizzati dai consumatori, quindi sono superiori". Un sondaggio di settore recentemente pubblicato (ancora nelle notizie ne sono sicuro), ha rivelato che SATA sopravvive in media a SAS, almeno con le dimensioni significative del campione del sondaggio. (Mi ha scioccato, questo è certo.) Non ricordo se si trattasse di versioni "enterprise" di SATA, o consumer, o di quali velocità - ma nella mia considerevole esperienza, i modelli enterprise e consumer falliscono tassi statisticamente significativi. (Tuttavia, c'è il problema delle unità consumer che impiegano troppo tempo per il timeout in caso di errore, il che è sicuramente importante nell'azienda - ma questo non mi ha morso, e penso che sia più rilevante per i controller hardware che potrebbero richiedere l'intero volume off-line in questi casi, ma questo non è un problema SAS vs SATA, e ZFS non mi ha mai deluso. Come risultato di quell'esperienza, ora uso un mix di unità SATA 1/3 enterprise e 2/3 consumer .) Inoltre, non ho riscontrato alcun impatto significativo sulle prestazioni con questo mix di SATA, se configurato correttamente (ad esempio una serie di mirror a tre vie), ma poi ho una bassa richiesta di IOPS, quindi a seconda di quanto è grande il tuo negozio e casi d'uso tipici, YMMV. Ho sicuramente notato che la dimensione della cache integrata per disco è più importante per i problemi di latenza rispetto alla velocità di rotazione del piatto, nei miei casi d'uso.
In altre parole, è una busta con più parametri: costo, throughput, IOPS, tipo di dati, numero di utenti, larghezza di banda amministrativa e casi d'uso comuni. Dire che SAS è sempre la soluzione giusta è ignorare un vasto universo di permutazioni di quei fattori.
Ma in entrambi i casi, ZFS è assolutamente incredibile.