Tu t'amuses comme tu veux, mais moi je ne vois pas l'intérêt par rapport à un RAID.

Si, demandes à Mattmatt le débit d'un flux 1080p en RAW, de mémoire on s'approche du Go/s. Certains traitent ça en brut sur leurs workstations (avec des solutions type blackmagic)

1080*1920 progressif 50 images/s, environ 3Gb/s

on enregistre sur ça par exemple : http://pro.sony.com/bbsc/ssr/cat-srmemory/cat-memory/product-SR1TS55/

au alentour de 8000$ la cartouche, c'est des raids de SSD

Suffit de faire du 2160p en 10 bit par exemple, ensuite si tu veux pousser le vice, tu fais du 60fps, et tu les tapes.

Suffit de faire du 2160p en 10 bit par exemple, ensuite si tu veux pousser le vice, tu fais du 60fps, et tu les tapes.

mais non monsieur, UHD en 10 bit HDR et 120 fps comme le conseillent BBC et EBU , c'est un peut moins de 24Gb/s

https://kws.smpte.org/kws/public/projects/project/details?project_id=180
http://www.c-dis.net/embrionix.html

Par contre, dans mon message je pensais plus à ça: https://www.grosbill.com/4-seagate_desktop_sshd_1_to_8_go_ssd_-600147-informatique-_disque_dur
Avec seulement 8Go, difficile de faire du wear leveling correct (étalement de nombre d’écriture par secteur), surtout si la flash sert en tampon pour l'écriture. Donc à mon avis la flash ne sert pas en écriture ou très peu.

Je ne sais pas comment est utilisé la flash sur ce type de disque par rapport à un SSD en ZIL. C'est pas tellement la capacité qui me gêne mais plus la manière de s'en servir. Le SSD que j'utilise en ZIL fait 64Go mais seulement 8Go sont utilisés. Ca suffit pour accélérer toutes les opérations disques des VM en NFS (lecture/écriture aléatoire) par contre, dès qu'on copie des gros fichiers, ça devient un bottleneck : le débit séquentiel des disques est supérieur au débit en écriture du SSD. Note: le ZIL apporte une sécurité sur les écritures en cas de crash puisque ça fait office de journal.

Comme j'ai 16Go de RAM sur le NAS, je n'ai pas mis de cache en lecture (L2ARC) sur le SSD, l'efficacité par rapport au volume de données accédé aurait été faible (le cache en RAM suffit). Donc là, même punition.

C'est mis en place avec le reboot de 6h53 :
$ dmesg | grep EXT4
[    3.260881] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[    3.945954] EXT4-fs (sda2): re-mounted. Opts: commit=300,errors=remount-ro
[    4.032655] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: commit=300

L'option commit=300 secondes (valeur par défaut = 30 secondes) ne diminue que peu les écritures sur le SSD, toutefois son action ne semple pas nul

La mise en place de l'option est réalisée le 24 au matin, là où il y a un pic important en lecture, lié au fait que le cache de lecture en ram a été vidé :


Au total, si on regarde avant la mise de SmokePing dans un Ram disque persistant, j'ai presque divisé par deux les écritures sur le SSD :