[LINUX]: Ecriture de données en continue sur SSD - Page 2

PpHd (./29) :
Tu as des exemples ?

Tu n'as pas la possibilité de porter un bout de ton code sous Windows pour voir si les écritures sont gérées de la même façon à débit identique ? Ou de voir avec un logiciel qui fonctionne en direct2disk si les problèmes sont les mêmes ?

Hm, j'ai cherché rapidement pour voir si des audiophiles linuxiens (qui sont rares mais pas inexistants) rencontraient des problèmes de direct to disk avec des ssd, mais je n'ai rien trouvé de probant en plus, l'utilisation des SSD comme cache intermédiaire avant un disque mécanique pourrit les résultats des recherches :/

Nil (./31) :
Tu n'as pas la possibilité de porter un bout de ton code sous Windows pour voir si les écritures sont gérées de la même façon à débit identique ? Ou de voir avec un logiciel qui fonctionne en direct2disk si les problèmes sont les mêmes ?

Pas simple, et pas de licence Windows

Sinon, j'ai fait un test rapide d'une nouvelle solution.
Le thread d'acquisition (à haute fréquence) produit les fichiers en RAM de manière continue (et ne fait strictement aucun appel disque, même pas ramfs), et un autre thread (à plus faible fréquence) le vide sur le disque en une seule commande write en mode sync, en continue
Ca à l'air de fonctionner et de ne pas faire de frame drop (et je monte à 200Mo/s !)

Une idée de format archive le plus simple possible (genre juste une concaténation de fichier) ?
(Si je peux éviter un fichier au format custom, je suis preneur).

https://en.wikipedia.org/wiki/Tar_%28computing%29 tout simplement ?

J'y avais déjà pensé, mais je me demandais s'il y en avait un autre ?

Il y a aussi le bon vieux ar (.a), utilisé pour les bibliothèques statiques, mais aussi à la base de dpkg. Ou aussi le cpio que RPM a utilisé jusqu'à récemment (mais ils ont abandonné la compatibilité cpio pour pouvoir gérer les fichiers de plus de 4 GiB, ce que le projet cpio n'a pas voulu rajouter parce qu'ils ne maintiennent le logiciel plus que pour la compatibilité avec les vieilles archives, RPM était le seul grand utilisateur restant). Ces formats sont plus simples que le tar, mais je ne sais pas s'ils ont les propriétés que tu cherches.

Finalement, je vais partir sur le format TAR.
Mais pas en utilisant libarchive. Je vais écrire le code d'écriture des TAR from scratch. Ca va faire moins de 200 lignes de code. libarchive est sur-compliquée !

tu peux expliquer ce choix de réécriture stp ? Qu'est-ce que ça peut te faire que ce soit compliqué, tant que ça fait le boulot ? T'as peur pour les perfs ?

Il faut que je sois sûr qu'il n'y ait aucun accès disque.

(Sinon la solution décrite en ./32 marche très bien !)

C'est de toute façon bien plus sain de séparer le producteur et le consommateur

(au contraire, on m'a toujours dit que c'était plus sain de cultiver soi-même des tomates dans son jardin )

( — ça dépend où tu habites, des fois la terre est contaminée )