Pour vous tous ... ZFS sur n'importe quel raid est une DOULEUR totale et n'est effectué que par des personnes MAD! ... comme utiliser ZFS avec une mémoire non ECC.
Avec des échantillons, vous comprendrez mieux:
- ZFS sur Raid1, un disque a un peu changé lorsqu'il n'était pas éteint ... faites levier, vous savez, ZFS verra des dommages ou ne dépendra pas du disque lu (le contrôleur Raid n'a pas vu ce bit changé et pense que les deux disques sont OK ) ... si l'échec est dans la partie VDEV ... tout le ZPOOL perd toutes ses données pour toujours.
- ZFS sur Raid0, un disque a un peu changé quand il n'était pas éteint ... faites levier tout ce que vous savez, (le contrôleur Raid n'a pas vu ce bit changé et pense que les deux disques sont OK) ... ZFS verra ces dommages mais si le l'échec est dans la partie VDEV ... l'ensemble du ZPOOL perd toutes ses données pour toujours.
Là où ZFS est bon, c'est en détectant les bits qui ont changé lorsque le disque était sans alimentation (les contrôleurs RAID ne peuvent pas le faire), également quand quelque chose change sans qu'on le lui demande, etc.
C'est le même problème que lorsqu'un bit dans un module RAM change spontanément sans qu'on lui demande ... si la mémoire est ECC, la mémoire se corrige d'elle-même; sinon, ces données ont changé, de sorte que les données seront envoyées aux disques modifiés; indiquez que le changement n'est pas sur la partie UDEV, si l'échec est dans la partie VDEV ... tout le ZPOOL perd toutes ses données pour toujours.
C'est une faiblesse sur ZFS ... VDEV échoue implique que toutes les données sont perdues à jamais.
Hardware Raid et Software Raid ne peuvent pas détecter les changements de bits spontanés, ils n'ont pas de somme de contrôle, pire sur les niveaux Raid1 (mirros), ils ne lisent pas toutes les parties et les comparent, ils supposent que toutes les parties auront toujours les mêmes données, TOUJOURS (je dis il bruyamment) Raid suppose que les données n'ont pas changé par autre chose / manière ... mais les disques (comme la mémoire) sont sujets à des changements de bits spontanés.
N'utilisez jamais un ZFS sur une RAM non ECC et n'utilisez jamais ZFS sur des disques attaqués, laissez ZFS voir tous les disques, n'ajoutez pas de couche qui peut ruiner votre VDEV et votre POOL.
Comment simuler un tel échec ... éteindre le PC, sortir un disque de ce Raid1 et modifier un seul bit ... reconecter et voir comment le contrôleur Raid ne peut pas savoir que cela a changé ... ZFS peut car toutes les lectures sont testées contre la somme de contrôle et s'il ne correspond pas, lisez une autre partie ... Raid ne relit plus jamais car un échec (sauf matériel impossible, la lecture échoue) ... si Raid peut lire, il pense que les données sont OK (mais ce n'est pas dans de tels cas ) ... Raid essaie seulement de lire à partir d'un autre disque si où il lit dit "hé, je ne peux pas lire à partir de là, le matériel tombe en panne" ... ZFS lit à partir d'un autre disque si la somme de contrôle ne correspond pas aussi comme si où il lit dit "hé, je ne peux pas lire à partir de là, le matériel tombe en panne".
J'espère que je le dis très clairement ... ZFS sur n'importe quel niveau de Raid est une douleur totale et un risque total pour vos données! ainsi que ZFS sur les mémoires non ECC.
Mais ce que personne ne dit (sauf moi) est:
- N'utilisez pas de disques avec cache interne (non seulement ceux SHDD, également certains qui ont 8 Mo à 32 Mo de cache, etc.) ... certains d'entre eux utilisent de la mémoire non ECC pour ce cache
- N'utilisez pas SATA NCQ (un moyen de mettre en file d'attente les écritures) car cela peut ruiner ZFS en cas de coupure de courant
Alors quels disques utiliser?
- Tout disque avec batterie interne qui garantit que toute la file d'attente sera écrit sur le disque en cas de panne de courant et utilise la mémoire ECC à l'intérieur (désolé, il y en a très peu avec tout cela et coûte cher).
Mais bon, la plupart des gens ne savent pas tout cela et n'ont jamais eu de problème ... je leur dis: wow, quelle chance vous avez, achetez des billets de loterie, avant que la chance ne s'en aille.
Les risques sont là ... de telles défaillances peuvent se produire ... alors la meilleure réponse est:
- Essayez de ne mettre aucune couche entre ZFS et où les données sont réellement stockées (RAM, Raid, NCQ, cache disque interne, etc.) ... autant que vous pouvez vous le permettre.
Que fais-je personnellement?
- Mettez quelques couches de plus ... j'utilise chaque disque SATA III 2.500 7200 tr / min sur un boîtier USB 3.1 Gen2 type C, je connecte certains boîtiers à un concentrateur USB 3.1 Gen 2 Type A que je connecte au PC; d'autres à un autre concentrateur que je me connecte à un autre port racine sur le PC, etc.
- Pour le système, j'utilise des connecteurs SATA internes sur un ZFS (niveau Raid0) parce que j'utilise un système Linux inmutable (comme un LiveCD), chaque démarrage démarre un contenu identique sur des disques internes ... et j'ai une image Clone du système que je peux restaurer (système inférieur à 1 Go) ... j'utilise aussi l'astuce pour avoir le système contenu dans un fichier et utiliser un lecteur mappé RAM où je le clone au démarrage, donc après le démarrage, tout le système fonctionne en RAM ... mettre ce fichier sur un DVD je peux aussi démarrer de la même manière, donc en cas de défaillance des disques internes, je démarre simplement avec le DVD et le système est à nouveau en ligne ... astuce similaire à SystemRescueCD mais un fichier ISO beacuse un peu plus complexe peut être sur le ZFS interne ou tout simplement être le vrai DVD et je ne veux pas deux versions différentes.
J'espère que je pourrais donner un peu de lumière sur ZFS contre Raid, c'est vraiment une douleur quand les choses tournent mal!