ZFS: la distruzione di zvol o set di dati deduplicati blocca il server. Come recuperare?

Sto utilizzando Nexentastor su un server di archiviazione secondario in esecuzione su un HP ProLiant DL180 G6 con 12 unità SAS Midline (7200 RPM). Il sistema ha una CPU E5620 e 8 GB di RAM. Non esiste un dispositivo ZIL o L2ARC.

La scorsa settimana, ho creato uno zvol sparso da 750 GB con dedup e compressione abilitati a condividere tramite iSCSI su un host ESX VMWare. Ho quindi creato un'immagine del file server Windows 2008 e copiato ~ 300 GB di dati utente nella VM. Una volta soddisfatto del sistema, ho spostato la macchina virtuale in un archivio NFS nello stesso pool.

Una volta installato e funzionante con le mie VM sul datastore NFS, ho deciso di rimuovere lo zvol originale da 750 GB. In questo modo si è bloccato il sistema. Accesso all'interfaccia web di Nexenta e NMC interrotto. Alla fine sono stato in grado di arrivare a un guscio grezzo. La maggior parte delle operazioni del sistema operativo andava bene, ma il sistema era sospeso sul zfs destroy -r vol1/filesystemcomando. Brutto. Ho trovato le seguenti due voci di bugzilla di OpenSolaris e ora capisco che la macchina verrà murata per un periodo di tempo sconosciuto. Sono passate 14 ore, quindi ho bisogno di un piano per poter riottenere l'accesso al server.

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6924390

e

http://bugs.opensolaris.org/bugdatabase/view_bug.do;jsessionid=593704962bcbe0743d82aa339988?bug_id=6924824

In futuro, probabilmente prenderò il consiglio dato in una delle soluzioni alternative:

Workaround
    Do not use dedupe, and do not attempt to destroy zvols that had dedupe enabled.

Aggiornamento: ho dovuto forzare lo spegnimento del sistema. Al riavvio, il sistema si blocca su Importing zfs filesystems. È così da 2 ore.

Questo è stato risolto. La chiave è che i volumi deduplicati devono avere il flag di dedup disattivato prima dell'eliminazione. Questo dovrebbe essere fatto sia a livello di pool sia a livello di zvol o filesystem. Altrimenti, la cancellazione viene essenzialmente deduplicata. Il processo richiede tempo perché viene fatto riferimento alla tabella di deduplicazione ZFS. In questo caso, la RAM aiuta. Ho temporaneamente aggiunto 16 Gigabyte di RAM aggiuntivi al sistema e ho riportato il server online. Lo zpool è stato importato completamente entro 4 ore.

La morale è probabilmente che dedupe non è super lucido e che la RAM è essenziale per le sue prestazioni. Sto suggerendo 24 GB o più, a seconda dell'ambiente. In caso contrario, lasciare la deduplicazione ZFS disattivata. Non è assolutamente ragionevole per utenti domestici o sistemi più piccoli.

Come utente di lunga data delle appliance Sun / Oracle ZFS serie 7000, posso dirvi senza dubbio che dedupe non è lucido. Non confondere mai le vendite con la consegna! I commessi ti diranno "Oh, è stato corretto". Nella vita reale - la mia vita reale - posso dirti che 24 GB non sono sufficienti per gestire i "tavoli DDT". Cioè, l'indice back-end che memorizza la tabella dedupe. Tale tabella deve risiedere nella memoria di sistema in modo tale che ogni I / O venga intercettato in volo per capire se deve essere scritto o meno sul disco. Maggiore è il pool di archiviazione, maggiore è il numero di modifiche apportate ai dati, maggiore è questa tabella e maggiore sarà la richiesta di memoria di sistema. Quella memoria viene a scapito di ARC (cache) e, a volte, del sistema operativo stesso - motivo per cui si verificano blocchi, in quanto alcuni comandi avvengono in primo piano, alcuni in background. Sembra che l'eliminazione del pool avvenga in primo piano, a meno che non sia diversamente indicato nella CLI. I maghi della GUI non lo faranno.

Anche una cancellazione di massa dei dati NFS all'interno di una condivisione definita su un volume deduplicato ridurrà la metà del sistema se non si dispone di memoria sufficiente per elaborare le "scritture" su ZFS che gli dicono di eliminare i dati.

Complessivamente, a meno che non si massimizzi la memoria e anche in questo caso, trovare un modo per riservare memoria per il sistema operativo limitando ARC e DDT (e non credo che si possa limitare il DDT per natura di esso, è solo un indice legato esattamente al tuo I / O) - allora sei sotto pressione durante grandi cancellazioni o zvol / pool destoria.