Différences entre disques SAS et disques SATA

J'ai découvert dans les commentaires d'un article de Linuxfr "Et si la meilleure des cartes RAID était libre ?" une explication intéressante que je vous partage :

Si le but est d'avoir un sync rapide, et de la mémoire cache en écriture pléthorique, cela ne doit pas être difficile de mettre 1 Go de ram de cache d'écriture sur un disque dure au lieu de 32 Mo et d'avoir une super capacité pour finir un fsync en cas de coupure d'alimentation.

C'est pas tout à fait aussi simple que ça. Le disque dur doit en plus posséder une intelligence au niveau bloc (au minimum). Si tu fais du sync brut de fonderie tu vas à la catastrophe, si tu fais du sync en mode pur synchrone tu tues les perfs.

Par exemple tu copies un gros fichier comme copie d'un autre, puis tu modifies le nouveau fichier en changeant un caractère et tu modifies l'ancien fichier en changeant un autre caractère.

Si tu n'as pas d'intelligence au niveau bloc il va se produire un des deux scénarios suivant :

1) Mode synchrone pur
- demande de copie du fichier => "Ouhlà gros fichier,on va syncer plus tard"
- modification du nouveau fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
- modification de l'ancien fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"

Conséquence : gros impact sur les I/Os notamment en cas d'accès concurrents. L'OS peut faire des pirouettes pour permettre la modification de l'ancien fichier alors que le nouveau n'est pas encore copié, mais au niveau disque c'est clairement pas top. (Et pourtant c'est ce qui se passe 90% du temps en SATA….)

2) Mode "brut de décoffrage"
- demande de copie du fichier => "Ouhlà gros fichier, on va syncer plus tard"
- modification du nouveau fichier => "Bon ben on va syncer maintenant, merci de patienter le temps de la copie, pas touche au fichier en attendant"
- modification de l'ancien fichier => "Un seul caractère ? Pas de problème gars - on fait ça tout de suite"

Conséquence : impact modéré sur les I/O, mais gros risque de corruption de données si la source du fichier en cours de copie est modifié.

En SAS (et en scsi en général) il va se passer ça (en ultra simplifié hein…) :

    demande de copie du fichier => "Les blocks Xxxx,Xxxy,….Xzzz sont faux, à la place utiliser les blocks Yxxx,Yxxy,….Yzzz en lecture"+" Planifier copie des blocs Yxxx,Yxxy,….Yzzz vers Xxxx,Xxxy,….Xzzz"
    Modification du nouveau fichier => "Le bloc Xzxy est faux à la place utiliser cache Xaab" + "Anuler copie du bloc Yzxy vers bloc Xzxy"+"Planifier copie du bloc cache Xaab vers bloc Xzxy"
    Modification de l'ancien fichier => "mettre en cache dans Xaad le bloc Yzyy" + "Le bloc Yzyy est faux à la place utiliser bloc cache Xaac" + "Le bloc Xzyy est faux à la place utiliser bloc cache Xaad"+"Planifier copie du bloc cache Xaac vers le bloc Yzyy"+"Annuler copie bloc Yzyy vers Xzyy"+"Planifier copie du bloc cache Xaad vers Xzyy"

Au niveau I/O, temps de réponses, opérations à effectuer pour un sync etc. on comprend assez vite que le SAS va booster grave.

Bien entendu il y a en plus des algos qui font que les écritures proches sont faites par lot, la gestion du cache est beaucoup plus puissante que ce qu'exposé dans cet exemple simpliste etc.

En SATA, la nature même du fonctionnement fait que le cache s'essouffle très vite. Il y a eu à une époque des disque SATA avec 256Mo, mais leurs perfs étaient à peine meilleure que les disques avec 32Mo. Honnêtement sauf à ballader à longueur de journée des fichiers qui font la moitié de la taille du cache disque, il n'y a aucun intérêt à aller au delà de 64Mo en SATA, et déjà c'est overkill…

Source : LinuxFR Posté par Kaane le 10/02/14

Ouais sauf qu'à un moment il faut bien écrire sur disque ce que tu as caché en RAM.

Et là le SCSI/SAS fait toute la différence avec le SATA. L'auteur du post ne précise pas non plus que le SCSI/SAS décharge le CPU de toutes les opérations de gestion des ordres aux disques, au contraire du SATA qui est "piloté" par le CPU.

J'ai (encore) du SCSI à la maison avec des disques de 36Go et 72Go en 10000 et 15000rpm, la différence est impressionnante. Sur des machines anciennes c'est encore plus visible.

Par contre, la différence de prix est un peu rédhibitoire !

Ben en fait le SAS est une techno tres utilisée sur les seveurs pro, le SATA c'est plutot destiné aux PC grand publique.

J'ai pas dit de les disques SATA était moins performent, maintenant si tu regarde ce qui ce qui est utilisé sur tous les servers IBM, Dell: HP et autres c'est des disques SAS.
Pourquoi je sais pas.

NetApp et EMC2 vendent aussi des tiroirs en disques SATA 7200rpm, c'est bien moins cher et largement suffisant pour beaucoup de besoins.

Beaucoup de serveurs d'entrée de gamme sont en SATA d'origine, ça n'a rien de choquant, une fois l'OS bouté OSEF du disque. Et pour les BDD ou les gros hyperviseurs, on utilise le SAN donc les disques locaux...

A noter qu'un controleur SAS reconnait un disque SATA (le connecteur est identique) mais pas l'inverse.

C'est parce que HP c'est à peine du mid-end en SAN -> Netapp/EMC utilisent des disques natifs FC