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 scenarios 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 à longuer de journée des fichiers qui font la moitié de la taille du cache disque, il n'y a aucun intéret à aller au delà de 64Mo en SATA, et déjà c'est overkill...
[^] # Re: Utilisation en production ?
Posté par Kaane . En réponse à la dépêche Et si la meilleure des cartes RAID était libre ?. Évalué à 7.
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 scenarios 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...):
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 à longuer de journée des fichiers qui font la moitié de la taille du cache disque, il n'y a aucun intéret à aller au delà de 64Mo en SATA, et déjà c'est overkill...